Update - Harder than I expected

I am having to do alot of code cleanup and modifications to get the interfaces to work. I am using attributes more than usual and have implemented a CoreObjectFindByAttribute function which will be used to find a function in an interface. Because each interface is an object, it saves me the need for providing functions for browsing the interfaces which is one of the advantages when using a central store. I only have to focus on the specific behaviour and not on micro management. Its many times overwhelming and I feel like this project is too big on me, then I get inspired from something and continue on my sadistic journey. Oh well... Its a great learning experience.

Update - Interfaces

Hi, This has been a hard week... Last week I was able to get the display component to work but it did not use methods. In fact, this is the first time I am using the methods capability as an interface. I have done some re-designing and nearly finished implementing the changes. Untill now, each method was a seperate entity which linked into its module. Now it will work differently. The problem with this is that if a module was updated, it would have to search all objects for instances of the methods and update them each. An invalid function pointer means a crash or worse loss of information. The new implementation is that each module holds its interface of methods it supports with each entry holding the method name (i.e. UIShapeDraw) and its relative function address. The advantage is that there is central location for methods where interfaces can be updated easily by just replacing the lookup table. This will also make it easier to define an interface and all a method needs to do is hold the moduleId and the function name and index. The index is used for caching purposes (so we dont have to lookup the function each time by name). The kernel works mostly this way but did not have the function name lookup. The size of the function name is up to 32 bytes. Remember that the function name is the function name you would call in your code, so it should not be longer than 32 bytes anyway. This limit can be changed in future versions if needed. This design is easier to maintain and understand. I will also extend this to the kernel so that it will be very easy to look at the system and see all methods in the system. Because the interface entry index is passed in the message passing instead of the function address, it makes it more secure so that bad addresses cannot be passed without residing in an interface object. It also makes installations easier since a module can register itself through a method directly. This should avoid the problems of having to register every module in the system. I am very happy with the way things are turning out.

Update - See it to believe it

Great news! Finally, the display component now allows me to draw pixels on-screen which is the basics for any drawing operation. It also supports alpha blending which works very nicely. I have uploaded the changes. I still have not finished the design of the elements components but I am very close and it looks great so far. The broadcasting feature is becoming very useful for drawing and input and is a big part of the elements design. This is a great step for Safire since now I can start writing objects that draw things on-screen.

Update

I decided to upload the source anyway so that a sudden computer melt-down or the more common 'my dog ate my files' wont stop the development of Screens. I finished coding the display component. I need to code the layer and elements components. I have not finished designing them but I expect to finish the design shortly. Things are finally getting somewhere and this makes me very happy. Very exciting...

Safire begins

Finally, I have started coding the Safire module. I will be currently be writing it for the win32 platform and then port it to PalmOS since it allows me to debug and write the code quicker (VC++ is much faster than Eclipse). Most of the code is platform independent so this should not be a problem especially when windows is more complex. The framework is already coded and an empty window is displayed. I am now working on the display component which deals with the back buffer for the window that layers are drawn on and then copied to the window. Progress should be quick in the next few weeks when I finally get some drawing elements inside the system. Once I can demo the layering capabilities, I will upload the source to SourceForge and the demo executable. Once the layering is done (I have written layering components before so this should not be a hard job) I can start working on the child windows and input device components. The future is bright as safire :D

Update - Slow week

OK, while getting the Safire design together, I have been doing cleanup and bug fixes in the kernel which has been going very well. I am constantly trying to make actions faster currently I can run an action with an empty method in under 30 milliseconds on my computer. This is sort of the speed I like for Screens. I am working hard on Safire to get it done quickly and efficiently. I dont want to specify a date because I have not been very good at prediciting them. It took me 4 years to get here, no point giving up now.