Update

Uploaded another collection of fixes to SVN that make the stream support actually usable (it was written but not tested before hand).

I have decided to postpone the persistence loading and saving of objects to a later date and I am focusing on the more visual elements of Screens. I am currently working on bitmap loading and I am very close to displaying 24bit bitmaps on-screen. What's nice is that because the disk file system that is mounted is abstract, I can make the bitmap loading code totally platform independent.

To handle the alignment issues, I developed a few macros to handle the formatting of a stream of bytes to structures and it works very nicely.

One of my problems with the persistence model is the byte endian issue and I am still thinking of a solution of how to handle this effectively.

Once I can display bitmaps on-screen, I will start working on the UIText & UIFont components to display text on-screen. I will be using a bitmap font at first,  but since its object oriented, it can be easily replaced with a different font engine in the future.

So far coding is going well...

Update

Moving along... I have decided to merge the persistent storage functionality from being a separate component into the CoreObject component itself. This allows any object to be persistent and be saved and loaded from a file by just calling the CoreObjectSetAsPersistent on an object. If an object is persistent, it automatically makes its folder and its classes persistent as well. Because the default is that objects are not persistent, it should make the object storage less filled with temporary object. The actual saving and loading of objects into a file has not been written yet, but will be in the next few days.

I have also added stream support into objects, so you can read and write to objects as a file and if the object has not overloaded its stream methods (or if it is not under a storage device) then it uses allocated memory for the stream.

I have also returned to using SVN in my source forge project which you can find at: http://sourceforge.net/projects/screensos

I have uploaded all the latest sources to there.

Note that the demo there is outdated and not the current pre-alpha.

Update

This week has had less of Screens action since I had to put some more effort in my full time job.

I have made progress however. For example: CoreObjectBrowse now can mount objects automatically so you can pass a path like this: \C\Users\home\Documents\Downloads and it will mount each folder until it finds the Downloads folder. I also moved the rest of the mounting functionality to the CoreObject component leaving the devices to only the mounting itself. This makes mounting more transparent to objects.

I still have much work to do. First I have to write the 'unnamed' component (my biggest problem is giving meaningful names to components) which is like a file storage in a file. This will hold all the resources like fonts, strings, bitmaps and settings that Screens will need to run. The great thing is that I will be able to easily manipulate it by copying files from my real windows drive to the virtual drive. So I will be able to copy bitmaps as they are from windows to my storage which will make things much easier to handle. I still have some unfinished design issues in this component so I am sure it will take some time, hopefully not too much time.

Update

Finally, I have finished and tested the windows disk device component handling for folders. I still need to handle files but I doubt that will take long.

What this means is that I can now browse the file system and mount directories like this:

   1: FSDevice * Storage;

   2: FSFolder * Users;

   3: FSFolder * Home;

   4: /* Get a handle to the disk storage device */

   5: Storage = FSDiskDevice();

   6: /* Mount the storage */

   7: FSDeviceMount(Storage);

   8: /* Get the users folder in the c drive */

   9: Users = CoreObjectBrowse("/system/device/disk/c/users/");

  10: /* Mount the users folder */

  11: FSFolderMount(Users);

  12: /* Get the home folder under the mounted users folder */

  13: Home = CoreObjectFindByName(Users, "home");

  14: /* Mount the home folder */

  15: FSFolderMount(Home);

Notice that the only thing that specifies the usage of the disk file system is the FSDiskDevice function. All the rest of the code is abstract (apart from the path of course). I only need the device for mounting it which could easily be browsed for and then mounted so I can mount a device even if I don't know its type.

To avoid too much memory usage (I learned the hard way), you can mount and un-mount each folder separately. I am sure that the GUI will do this for you, but from a developer perspective this makes sense to have control over it. Note that any object can be mounted if it responds to the FSFolderMount method. So a zip folder could be mounted (if I wrote a zip FS device of course) so you could browse its contents after it was mounted.

Update

I have finished the abstract FSDevice, FSFolder and FSFile components and will start on the windows dependent implementation so that I can access the windows file system via my abstract components. When I port to PalmOS, it will be really easy since I just write a PalmOS implementation without having to change the rest of the code.

Update

Still going strong... After talking with some of my chat friends, I am starting to work on the File Storage components. FSDevice, FSFolder and FSFile are the abstract components that I am writing which are placeholder components for the platform dependent file API's.

What's nice is that I will be able to give the same interface to PalmOS RAM (where pdb/prc are folders and the records are files) and the VFS (which has the folder/file design anyway) systems. This will extend to FTP or any other design that supports the folder hierarchy and file stream design. You as a user/programmer wont have to care what the storage the folder/file is from, since it has a unified API.

Each file platform only needs to derive a new component from FSDevice, not from FSFolder and FSFile. This is because I use message bubbling (I must find a better name) to find the device of a folder/file by using the object hierarchy. This means that you can do nesting where a file can exist in a zip compressed file where they both have the same interface. And because it really is a little amount of code, it makes it practical to apply to many ideas.

Hope to finish soon ;)

Update

Things are going really well. I have form moving and button tapping and I am thinking what widget should be next.

I am going for simplicity at first, and in later builds once I have a comfortable model add some 'graphics' to the mix. So when you get the alpha build, please judge it by its functionality and not by its graphics. I can always 'paste' bitmaps on widgets, so let's go for the functionality first, visual style second.

I don't know when the next alpha will be, but I do want it to do 'something' other than movable windows, maybe the slider control and get feedback on that. Any ideas?

I still have a long way ahead of me but I have really enjoyed the last two weeks. Writing a new component is actually fun now that its very streamlined. Most of the components look the same and in the code feel the same which helps.

Update

Things are moving very quickly and smoothly lately. I already have forms moving correctly, faster than previous alpha versions. I will now work on some controls such as buttons, check boxes, radio buttons and so on.  Note that I still don't have a text engine so still I cannot see any text on-screen.

Note that the first platform Screens works on is windows since its easier to debug and write in Visual Studio than Eclipse. Once I have a good version working on Windows, I will port the platform dependent files to PalmOS and move to Eclipse. Note that most of the code is platform independent and is designed to be platform independent.

I see that soon I will have to think about choosing what text engine design will be implemented in Screens.

Update

The pen component has been mostly written. It was an easy task thanks to the object storage. I still have yet to face the 'road block' of the object storage that I have faced very often with every other object storage I have written.

I need to now work on the passing of pen events to the elements so that a window/control can respond to a pen event. Once I have coded this I can start implementing handling the pen events for the different UI components starting with the form component.

I hope the speed will be faster than previous versions.

Update

Trying to keep you all updated,

Still finalizing the form component which I can finally see its title, although no text (I still have to figure out which text model I am going for). I will be working on the pen component next so that I can get the form windows moving around.

Note that skinning will not be an option for users in the first version. I think its more important I get something that works and is stable before I think about customization. But don't get me wrong, I do believe in skinning, just not in its priority.

What is nice however is that because Screens is object oriented, all controls and windows are derived from the UIElement class which allows me to send a UIElementDraw message to an object and the controls & windows override the UIElementDraw method to draw themselves their own way. GUI is just so much easier with object oriented storage.

I have also finished implementing shadows, so I can freely link objects wherever I want in the hierarchy. For example: even though the drawn objects are under the display device object, they are shadows so I can easily swap them out for other drawing objects... virtual workspaces in an easy programming switch. Just scratching the surface of what an object storage can do.

Update

Finally things are going well...

Thanks to some lovely users in my Windows Messenger Live Group, I have been given a direction to follow to get Screens out as quickly but cleanly as possible.

I know that PalmOS is going through a rough time and I don't want Screens to miss the boat flood.

I am very happy with the new design and I am already coding the form component to display windows. I already have most of my UI design done and my favorite is the new way to write a component like this:

   1: /* in header file */

   2: typedef UIWindow UIForm;

   3:  

   4: UIForm * UIFormNew();

   5:  

   6: /* in source file */

   7:  

   8: typedef struct {

   9:     byte Title[UI_TITLE_LENGTH];

  10:     color TitleBackgroundColor;

  11: } form_info;

  12:  

  13: obj_component(UIForm, UIWindow) {

  14:     obj_method("CoreObjectInit", FormInit);

  15:     obj_method("UIElementDraw", FormDraw);

  16:     obj_type(form_info);

  17: }

I found it very easy to write components, overloading methods at run-time with a single line and while it might not be the easiest to understand, it does the job quickly and efficiently.

I am working as hard as I can to get the alpha demo back up and running. This time I expect to be able to not only move windows around, but hopefully a bit of the slider and system bar as well, so I can get some feedback so finally some of you users can help if you want to.

Wish me luck!

Update

I am sorry, things are not going well... I am swamped at work and I still cannot get the drawing model of the ground. I need help because I have alot of questions and no answers. While research will give me the answers, it requires alot of time to find them out myself. I am still here... just stuck...

Update

Hi Everyone, As I said in the previous post, I did not get much work done on Screens because of pressure at work, however I did find some moments here and there and the code is moving nicely forward. The feature of pointer shortcuts that I talked about in the previous post is working nicely and makes the code much cleaner and more direct. I plan to finish the basic graphical model as quickly as possible like I had in the previous alpha and then I will send to some of you the alpha version (the ones I can find) via MSN so you can tell what you think. Thanks for reading, Zakai Hamilton

Update

Hi, I just wanted to update you all that this week and next week are going to have very little programming time because my full time job at NDS needs some time reinforcemant. But things are going great for Screens. As you know Screens evolves all the time and I get to rewrite it on a monthly basis to get it just that much easier. Well, it looks like its going to happen again after seeing the work that was required to do drawing on-screen which was a bit too complex. The new object design is so much closer to C but has a cool backdoor effect to allow any structure attached to an object, to be used as the object handle itself. I dont know of any system that does this and I am very happy to be able to work on it. Here is an example: object * Object = ObjectNew(); window_struct * Window = ObjectAdd(Object, window_struct); element_struct * Element = ObjectAdd(Object, element_struct); ObjectRename(Window, "My object name"); ObjectAttach(Element, ObjectRoot()); Window = ObjectCast(Object, window_struct); In this example: Object, Window & Element are all the same object. This design allows to use multiple pointers to represent the same object. Whats cool is that the casting allows to access data stored in each object natively. So that Element pointer allows to actually read/write members in the element structure with no need for function read/write overhead. It makes objects much closer to the C language. BTW: About the spaces feature in MacOSX idea, I expect these kind of features to be included in Screens in its future but I doubt in the 1st version. Thanks.

Update

Last week I spent alot of time coding because I was on vacation from work. This week however I am back at work which explains why the lack of coding. I have however tried to squeeze some time out of my day for some programming on Screens. I have finished the fill part of the rectangle class, so I can fill the screen with rectangle fills. Things are moving...

Update

Things are progressing very nice. I have already finished the Shape component which deals with caching drawing to the display. It allows the windows and controls to be detailed objects while not reducing the performance of drawing to the display. This model allows to have transparency with a single off-screen buffer without requiring a seperate off-screen buffer for each window. This makes windows much cheaper in memory requirements.

Practice makes perfect

Practice is realy the way to make something perfect. I have rewitten the object storage so many times improving over the previous when I hit a wall since it was easier to rewrite the entire code, then patch the previous design. I did not expect to write over 20 times the same object storage but I guess thats what I needed... Pratice. And yes, I have done it again... I have rewritten the code again but wait... here's why: 1. Objects only understood streams While it was nice on design, it did not work out in usage. I had to make alot of wrapper functions that would take a structure and break it down into values and it required alot of the same code to get to the data. It felt like alot of the code was just to talk between C and my object storage. 2. The alpha was recieved well, but it was hacked a bit together I sent an alpha to some of my Windows Live (MSN) users (zhamilton1@yahoo.co.uk if you want to join) and while it showed of windoing, it was very fixed and very quickly I found the problems when trying to do something simple as making a button class. The whole idea of the object storage was to make things easier not harder. Thanks to the users who tested the alpha. But dont worry, this post is already after I have written the new object storage and I am very near the alpha demo stage that I was on the previous version. I have already used the new design and its so much nicer. Let's say I have the windows structure MSG. And I want to send it to all listeners so they can act on the message. Before hand I would have to break the parameters into a string and then each listener had to repack the structure. Alot of work for nothing. The new code is like this (without error checking): object Core, Message; MSG * WinEvent; /* Retrieves the event core */ Core = EventCore(); /* Creates a message object */ Message = ObjectNew(Core, 0); /* Add the windows message structure to the object */ ObjectAdd(Message, MSG); /* Retrieve the windows message structure from the object */ WinEvent = ObjectCast(Message, MSG); /* Fill the win32 message */ if(!GetMessage( WinEvent, NULL, 0, 0 )) { return false; /* exit the application */ } /* Send the message to all event core listeners */ ObjectSend(Core, Method_EventDispatch, Message); When a listener recieves the message it just does this: MSG * WinEvent; WinEvent = ObjectCast(Message, MSG); You can see that the code is readable and clean. I will get back to the previous status of the moving windows and buttons and I will give some of you a version for feedback. Thanks

Update

I know of the disappointment... so... I spent all last night and this morning coding like crazy and finally I can actually display movable layers and draw fills and frames on them. The window class is nearly complete. I need to finish the drawing of the title and the window borders. Note that the font engine is not implemented, so I wont be seeing any text displayed any time soon but I will get the UI up and going in every other sense. All the code is done on windows, however there are a very few key files that need to be rewritten for the entire code to work on PalmOS. Most of the logic is platform independent so I know that the way it looks on my computer, it will look on my handheld. The drawing model is simple. I first send an 'update' message to all elements which they draw themselves onto thier layers and then I send a 'draw' message which layers respond to which they draw themselves on the display. I know its not much, but its the best I can do so far.

Update

Hi, Sorry for the lack of updates... I am still working on Screens but I just did not have anything to say. I dont think that 'still working' posts are needed. Screens Environment development is realy moving forward but painfully slow. I feel that the time I have something to release, no one will be interested in it. While the object storage is fine so far, I am now working on the graphical user interface stuff like drawing shapes to the screen. It has been nice to do all different drawing designs and test them very easily. I need to think of a concrete model before I can move forward to the window & control classes. You might say great you are nearly there, but that is so untrue. There is so much to do... ok... enough of that. To be more informational, I am working very hard on the drawing model to be fast and easy to use. I hope some spark will arrive and I will able to tell you that I am working on the window stuff, but so far... nothing. The performance is nice so far, it was worth the rewrite just to see that the object storage is not tied to a file but works rather by periodically syncronizing the objects to a file. This gives great performance increases and I will see it mostly when moving a window around the screen. About the forum, I dont think I should do that untill I have something to show you all which will last more than a week. Also I did not solve the problem with concrete objects, so you wont be seeing that feature anytime soon in the object storage. In fact, the multi-tasking side of Screens is not implemented yet. So, what is? Not much... basicly the object storage.

Change Computer - Change Luck

I bought my first computer a few weeks ago running Vista Premium on a HP Pavilion a6130 with a 2GB ram upgrade. Its a very beautiful computer which I am very happy with. It explains the lack of Screens online activity. I cannot even sync my lifedrive let alone I have not even installed Eclipse yet. This does not mean that Screens is dead. I am still spending time on it. Sometimes I just dont post anything, I dont have much to say apart from work in progress which I dont think interests you much. Its been 5 years since I started working on the project on 8/8/2002 and while the release has gone no-where, alot has changed. I have a great family with my son already a year old... I have a great job which I actually got from all the knowledge I gained from Screens and things are great. I always hope I can post more happy news for Screens but so far, I dont know when that will happen...

Update

Yes, the broken wheel is still rolling down the hill... Sorry for the lack of updates in the last month, I have been very active on Screens (proof is in my SVN updates) but the problem is that I still have to figure out some problems to be satisfied with Screens. One of the biggest issues I am dealing with at the moment is concrete objects which I believe is a very important feature for Screens. It allows each thread to have its own concrete view of the entire object storage. Updates are done to the object storage only if no conflicts exist (a conflict is detected if your thread was reading something that was out of date when the commit operation happened) and it then updates the concrete view of the thread to the current state of the object storage. This means that nothing happens outside of the threads activity untill an update. It makes multi-threading into a much easier experience since threads dont have to worry about external events reaching into the system. Because a commit operation either writes all changes or none, it keeps the object storage in a consistent state. I hope I can find the right solution for this problem. Once concrete objects are done I still have some other issues to deal with. Wish me luck!

Screens Vision

The Palm Foleo device although not released is something to talk about. Devices are constantly coming out in different form factors in different operating systems (Symbian, Windows Mobile, PalmOS, Linux) and different middleware. It can be very hard for developers coding for all these different platforms. Each developer either rewrites his applications from scratch for each platform, or tries to create a common ground to ease the porting of its applications. This costs money for developers for every platform they need to write for and can stop innovation since devices that dont have much market share might not be targeted by developers. Also all the resources that were spent on the common ground layer costs money and time which could of been spent on fine-tuning the application before release or new features. That's where Screens comes in. If Screens was already released, I would be able to quickly port the kernel & UI modules to the new Palm Foleo API and developers would just need to grab the new porting code & compile in the target device compiler and then they can focus on refining the user interface for the specific device. It allows for more programming for the user and less programming for the device. All the devices around us are becoming more and more the same in thier core parts. The Palm Foleo is basicly a small laptop with a small screen, so why should applications need to be rewritten for it just because its got a smaller resolution and screen. I understand that the Foleo is for documents and email but what if I need to view Cad Architecht diagrams, why should I have to use different applications from different companies with different features and layouts. People talk alot about software lock-in and thats where open formats help but with platform lock-in there currently is no solution (dont say Java). If you use your software on a specific platform configuration, its very rare that you can duplicate that experience on a different platform configuration. Windows has helped with making all PC's the same in thier infrastructure and vary on the real differences but there is no solution for cross platform needs. Why should the Windows Mobile Smartphone and Blackberry have entirely different user experiences when they more or less have the same hardware layout? I should be able to choose the device with the features I like and not have to learn a new user experience especially when I get the same functionality. Yes, Choice is good but choice should be a recommendation and optional. While you can argue that games and other proccessor intensive applications need to use the native API for speed, email is not one of those applications and should not need to be rewritten for each platform natively. I guess untill I release Screens, users wont able to have the option to choose thier software but be forced to choose.

Update - Design Month

Some months have more code written, some have more design done. This was a design month... I dont want to bother you all with the technical details but Screens is still very active. As you can see Screens does not realy 'exist' yet but I do plan to support SD Cards by making them objects that you can manipulate like any other bit of information. There will still be some time before I can finish the PalmOS version which should happen after I finalize the UI platform dependent code. Untill then, Screens is officialy vaporware.

Update - Practice makes perfect

Screens has been a bit on the low in the last few weeks because my sister got married this week on Monday. I have since done some work on improving the object storage implementation to make it do less read/write operations to disk by using a spanned memory block cache which should improve speed when I finish it. The hierarchy memory model will also allow to manage memory blocks more easily since they are interconnected, so if I delete a memory block, it destroys all the children memory blocks. It also makes it easier to resize blocks without having to change the handle. Its like the object model but much simpler. I hope I can finish it by the end of next week so I can show you all a new demo which is faster. Once I can get to a stage where object operations are cheap, it makes it much easier to make everything method based.

Running the demo

I have recieved a few posts that users cannot run the demos... Please use the following Visual Studio 2005 Redistribution file if it fails to run the demo: http://www.microsoft.com/downloads/details.aspx?FamilyID=32bc1bee-a3f9-4c13-9c99-220b62a191ee&DisplayLang=en Enjoy!

Alpah Demo 6

Hi, The new alpha you can get here: http://www.geocities.com/zhamilton1/SafireAlphaTest6.zip The speed has been improved and I have now enabled dragging of windows. Enjoy

Work, Work, Work

Here is another demo: http://www.geocities.com/zhamilton1/SafireAlphaTest5.zip All modules are dll's apart from the Screens executable. This gives a great speed boost which will improve soon even more when I implement a better drawing model. The code needs to be cleaned a bit more since the move to dlls was a little rough, but I am sure that things will be fine. I need to improve the input model as well so that there is a real thing as an active window so that keyboard input can be sent to a specific window instead of to all windows. Also each window will have an active control. Note that these are handled directly by the classes so they can all be overriden by modifying the classes. Thats the beauty of Screens.

Alpha Demo 4

Hi, I have been busy since last night and I give you the 4th alpha demo here at the following link: http://www.geocities.com/zhamilton1/SafireAlphaTest4.zip The demo will show 4 windows which you can choose any window (by its title) and drag them around. I have disabled dragging animation on purpose because of the slow speed. When I make Safire a dll, I can re-enable the animation which will probably be in the next demo. You can tap on a window to bring it to the front. From a development point of view, I have updated the UIElement class to support pen input and the UIWindow class which is derived from UIElement deals with the dragging of the window. As you can see progress is much more visible now and I am thrilled with the progress in these last few days. The slow speed of the demo is because of constant module launching. While the speed did improve because the kernel is a dll, its now slower because I do much more Safire calls which means a constant module launch for each Safire call. Once I make Safire a dll, the speed will suddenly come back. I hope I can do this soon so that we can put the speed bumps behind us and focus on some good functionality. Remember that the reason that there is no text is because I still have not decided which text engine I want to use for Screens... Remember my first demo back in 2002, I feel like I done a full circle but with the addition of object oriented storage and color ;)

Wow

Three posts in one day... Ok, the reason I am posting is to tell you all that I have just uploaded to SVN changes where the kernel (Xec) is now to be compiled as a dynamic dll when compiling for windows. This makes things much faster and I can see all but the 'loader' becoming dll's because of the speed. How faster? I guess around 3-4x faster then before. There is about a 25 millisecond hit when launching executables and nearly no hit when using dll's. For PalmOS, this does not matter much and the setup for compiliation is still exactly the same. I am glad that the speed did not require a major change but rather a small change to become a dll. I was scared at first since this is my first write of a dll but it worked the first time I tried it. Remember that Screens is not about speed but I do expect Screens to be fast enough to enjoy productivety without feeling slugish. Just remember that windows was not exactly fast neither was the world wide web and we can see what happended with those projects. They got faster as time went by. Performance realy is not that important as people make it.

Project Status

Hi, The project status is actually doing quite well. There is alot of work ahead but if you compare the amount of work done in the last few months, the code is maturing nicely. Now that windows have objects, even if they are simple objects (no skinning), its a step forward to the windowing working. I will be working now on the input queue where windows will receive events such as tap and key events. I have not finished designing this but I am sure I will find a solution soon enough. I know the speed is currently terrible on the windows version because of sub launching. This will be improved after I finish the input code. I will be also porting Safire when I finish the input code so that you can start running the demos on both windows and PalmOS. I am considering writing a linux port so those running on linux can also have a turn and see the flexability of the Screens platform. The advantage is that I only have to maintain platform dependent code rarely since most of the code is platform independent. So please dont judge the speed of Screens untill we see it running on PalmOS since most the speed bump is coming from the launching of processes on windows which is a platform dependent thing. On PalmOS this is much faster because everything is in RAM.

Update - Third Alpha

Hi Everyone, Sorry for the lack of posts, I was on a buisness trip in london all last week so I had no time to work on Screens at all. However I am working harder this week to fill in the gap. Here is the third alpha: http://www.geocities.com/zhamilton1/SafireAlphaTest3.zip I have also uploaded to SVN the UIWindow class and did some maintence on the kernel code to get the whole thing to work together. The demo now actually uses an object for each window. Every time you start the demo, you can control the position of a single window. Then exit and start the demo again to control a new window. It shows the persistance and might give you a glipse into the direction I am going. I know its not much and that the speed is terrible, but things are moving forward nicely.

Update - PalmOS Xec Code Updated

Hi, I just finished writing the updated kernel platform dependent code for PalmOS. Although I have not tested it and will not test it untill I finish porting the Safire platform dependent code, the kernel code does compile. Just remember if you are using PODS to add the Interface folder in the includes header list and the KERNEL_MODULE define if you are compiling the kernel. I have worked on Safire as well and now the layers can be saved and restored as you can see from the demo below: http://www.geocities.com/zhamilton1/SafireAlphaTest2.zip The same instructions as before, run Safire.exe with Xec.exe in the same folder. When you drag the mouse, one of the windows will move around. Close the application and restart it and the window will be in the exact location as before. Its not remembering just the window location but also how its drawn. It allows me to make starting/closing Screens to be very fast since no 'saving' of state is needed. Thats what the object persistance is for. The Safire API now works nicely. I know the speed is not something but I do have some ideas how to improve it in the future for the windows platform but currently platform dependent optimizations are not at the head of my list. Let it work first slow and then optimize it.

An Alpha Demo

OK, Its not fair for all of you... even if it is taking forever to finish, you are entitled to an all or nothing where either I shut up and release it in one big swoosh or I update you regulary with the development. I have decided to regulary display the results of my work and you can decide if its lame and will take me forever or appreciate the improvements as time goes by. You can find the files at: http://www.geocities.com/zhamilton1/SafireAlphaTest1.zip To run the demo, extract both files to the same folder and run Safire.exe Drag the mouse around in the window, to see the alpha blending effects. The demo is painfully slow because its using the display API. I will see how much I can improve the speed but remember that Screens is not about speed but rather about functionality and ease of use but there is always a way to improve speed so I dont see it high priority at the moment. It uses the windows 3.1 look just to feel a bit nostalgic. There are two layers here where the window layer is moved. Both layers are drawn once and then copied to the display each time you drag the mouse. The three windows are all in one back layer for simplistic reasons but I am sure I will start experimenting with multiple movable windows in the future. Currently the shared memory data source is not implemented but the shared memory component is implemented. I know this project is very technical which is true for most operating systems in thier early days. It can only get more interesting as time goes by... Enjoy!

Update - Shared Memory IPC

OK, The windows porting layer of Screens now has the Shared Memory IPC (Inter Process Communication). It makes things a bit faster but the best change was to allow CoreObjectOpen and CoreObjectUpdate to write directly to the store and skipping the IPC. This makes it much faster however it will be much faster when I add the shared memory data source. I am going to have to wait a while before I can create a demo or set of nice screenshots... But Jacob I do like your idea. I wont able to do text because Screens does not have a text engine yet (I still have not decided which text engine I should do/support). So most of the demos or screenshots wont have any text in them. I am now going to work on the rest of the data source functionality which is mostly the API function CoreObjectSource. The idea of the data source is that if an object has a different data source then in the store itself like a shared memory allocation, when you read/write using CoreObjectRead/CoreObjectWrite, it will read from the data source (like shared memory) instead of from the store. This will allow layers to exist in shared memory without changing any of the 'user' code. I have not decided yet if I will allow to change the data source via user code but to make an object use shared memory, you will just call CoreObjectSetAsTemporary on an object and everything else is transparent. If you call CoreObjectNew with no parent (NULL), the object is created as default temporary and therefore the object is going to use shared memory. Once I finish implementing the shared memory data source, I will need to add an initialize function which will go through the entire object storage on startup and destroy all temporary objects (since thier handles dont exist anymore). The destructor method is not called on such objects but this case should only happen if Screens did not shut down correctly. When you shut down Screens correctly, it will find all temporary objects and call the destructor on them. This functionality should make layer drawing not just faster but easy to manage.

Update - Shared Memory

OK, I am writing alot of code to handle shared memory so that temporary objects dont flush data to the disk all the time. It was paintful to drag a rectangle on-screen and see the hard-drive spinning full speed. The tasks are as follows: 1. Replace the IPC (Inter Proccess Communication) file with a shared memory implementation of a fixed 4K size 2. Add data source functionality with functions CoreObjectSource and CoreObjectOffset 3. Add Shared Memory data source The idea is that I will expose to modules the actual file position of objects data stream so that the read and write data does not need to pass through the IPC. The functions were available anyway to modules so there should be no problem there and it will increase the speed of Screens hopefully. Once I finish adding the shared memory data source, I will able to create layer objects and not have to worry about managing thier memory through methods since it will be supported directly inside the kernel. Once that is done, I will re-evaluate the speed so that I can decide the drawing model once and for all. About the screenshots... The truth is that I dont know what to show in the screenshot since there isn't realy anything visible. Its mostly the platform code and currently only runs on windows. Any ideas what to display?

Update

Hi, You can see by source forge that this project is moving along... but its moving very slowly. I just redefined the method declaration macros to be more component oriented which makes things more cleaner. I am still struggling with basic issues like uniqueIds and the work flow of code but I am on the right path and I am seeing improvements as time goes by. I have mostly finished the design of window management which uses the broadcast message feature in the object storage to send a message to all elements to draw themselves on thier layers. Alot of things have been thought about including skinning which I think developers will like the flexability to change the look & feel of basicly anything in the system because Screens seperates functionality from visual looks.

Update

Yes, alot of changes have happened in the last week. I have solved last weeks problem and I now having layers working very nicely. Drawing works nicely too including alpha blending effects. There is no point for a screenshot at the moment, but patience... very soon I think I can do something nice. I am now working on exporting the layer interface as API (so you can call the functions from other modules) and start working on the design of the windows & controls. I am working on the code as fast and efficient as possible...

The plan

First of all, sorry about the misunderstanding... I meant that I had uploaded the changes of version 0.80 to SVN, not a zip file. I plan to release a zip file hopefully next week. Screens status changes all the time for success to failure depending if you talk to me before or after I solve a problem. This project is very hard for all the possible reasons: 1. Trying to write a middleware system, not exactly what you call a picnic 2. Alone, the only designer and programmer 3. Writing an object oriented system in C which gives me language barrier problems (like duplication of code) 4. I have a fulltime job and a family to take care of which leaves Screens very little time I think these reasons alone can cause this project to stay in 'vaporware' for a long time. I guess luck is only what keeps the project evolving forward. I should be happy that the object storage is working but now that I finished the kernel, I have a new module to work on which is not going well at all. Its hard when you put so many years on the kernel and found out that you need to do it all again for the UI module. But I dont have another 5 years for the UI module. If I continue at this rate, Screens will be finished when flying cars are a standard. This does not mean I am giving up on Screens... that would lose all the fun of trying to do the impossible. I just want you to know that this project is impossible because of the combination of the problems above and that if you lose patience in the project, its perfectly understood. For those who do stay, Thanks! You might be the lifeline which keeps the project going. Its always nice to send a 'Hi :(' message when things are getting tough to a user and get a push of confidence that they believe in me. If I give a schedule, it would mean that I failed if I did not have Screens ready by then. I dont think that failure can be for Screens untill I give up since that officialy ends the project status. This is not the case at the moment. Yes, I am stuck on the basic drawing model for Screens and untill I solve it dont expect anything to show. However... if I did solve the basic drawing model, I could at least give you a screenshot of shapes. I am working as hard as I can...

Module Methods finally work

Hi, Module Methods finally work. I have simplified the design by removing actions and using types to add additional implementations of the same method. This makes it more simple to manage methods since you can find a method easily. To add a method: 1] Define a method name 2] Add a MODULE_INTERFACE_FUNCTION entry in Module.c of the module 3] Add a method wrapper calling CoreObjectSend 4] Call CoreObjectAddMethod to register the method The code is maturing very nicely and I am feeling more comfortable with it as time goes by. Its alot of hard work but so worth it!

Still moving forward

OK... version 0.80 of the kernel uploaded to http://sourceforge.net/projects/screensos What a week! Untill yesterday, I felt that Screens was at a dead end. I felt that the whole method design was spiraling out of control and just get more and more bloated and harder to understand. So I went back to basics and I use a simple C case switch and a single identifier per function. Its implemented, works and has been uploaded. I am very happy with the results because its easy to explain and is easy to use. I hope I can finally finish the method implementation on the module side (the kernel side works perfectly) so that I can work on the graphical stuff. I really feel that I am so close... so close...

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.

Screens System Requirements

Screens is designed to scale from low end to high end devices. It requires hardly any dynamic memory apart from a single off-screen buffer so I guess it requires a different amount depending on the screen size. It does require alot more storage memory although I dont know yet how much because it largly depends on how complex the UI will be. I will try and make Screens work on as many devices as possible and I do have some tweaks available where you can choose speed over size, so devices without much room can opt for size saving while devices with alot of space can opt for speed. When I finish the UI components in Safire, I will have a much better idea of the scalability of Screens and will able to update you on the storage requirements. Update: Yes, Screens will run on PalmOS 4.0 and maybe even PalmOS 3.5/3.0 if realy wanted

What does Screens bring for music?

Screens is going to do wonders for music lovers. First of all, you will finally able to make your own playlists in a hierarchy, so finally you dont have to use folders to seperate music that you want to hear. Another feature will be the ability to make playlists that are a combination of other playlists. So for example you will able to take your favourite pop playlist and your favourite rock playlist and have a pop & rock playlist. If you add a new music file to the pop playlist, it will apear in both the pop and the pop & rock playlist. I think users will find this a powerful feature. I am very open to features and I am sure I will see them pile on when I release Safire later this year. Even though the syncing feature wont exist in Screens v1 but it will be available in v2 which allows you to sync your favourite music over when connected. It goes even a step further, once you sync, it transfers your entire music collection information (meta data, not the music itself) so that you can decide when offline what music to sync when you go back online. For example: You could be listening to a George Michael song on your device and you can easily tell your device to sync another song from the same album or even its entire album. I see this feature very usefull to myself and I am sure others will too. I have not decided which music players I will integrate with but you will able to control your music directly from Screens without having to exit to run your music apps.

Update

I added some more functions to handle class types and some macros to ease the handling of identifiers. I am adding more functions to the kernel, to make it easier for Safire. I write a function for Safire and analyze if any of its functionality should be put in the kernel. Most of these functions added are object management related and therefore they should be in the kernel. I will upload Safire as well when it gets to a running solution. It will be in the same location in SourceForge. I have also added the CoreObjectFree action for virtual objects, but will not add it for object stream functions untill needed. Things are going well and I feel that the object storage is becoming easier to use and more effective. Safire is moving along and hopefully I can get something visual soon.

Update

OK, I have finished writing the method distribution and it works nicely. The idea is that you can associate a number of methods with an action and then you can work on an abstraction of actions. So instead of sending a message to a specific method, you send a message to an action and it forwards the message to each method in the action. This gives much more flexability since you can tap into existing message distributions at run-time. I know it sounds 'much ado about nothing' but when Safire is released, you will see what its all about. Its a great market for 3rd party developers. I now need to add the use of methods to the CoreObjectFree and stream interface as described in the previous post. I prefer updating you on my work update, then disappearing for a few months untill Safire goes somewhere. This way at least you know that Screens is still going and moving forward. Enjoy your weekend, Zakai Hamilton

Update

Things are going great... I have made alot of changes to the object storage to make it faster, simpler and more flexible. I will save you all the mumbo jumbo but from an API view links are now bi-directional, so when you link a source to a target, the target also knows about the source, so you can browse all the sources of a link which allows to delete links when thier targets are deleted instead of leaving dangling links. I still have to add actions which is a group of methods. So when you send a message to an action on an object, it distributes the message to multiple methods registered with the action. This is where the magic of Screens starts. Because multiple methods can register with an action, more than one set of code can be triggered on an event which makes things very flexible. Add type inheritance and you are dealing with a very powerful backbone. Once I finish adding actions, I need to use them for object removal (CoreObjectFree) and stream functionality (CoreObjectRead/Write/Size/Resize). This allows when removing an object, to free up any 'extra' resources attached to the object such as dynamic resources (like a screen buffer). I will also need to add an API to specify that an object is temporary (like properties that hold the handle to a dynamic resource). Very soon I will able to spend more time on writing Safire and less on improving the Kernel.

Update

First of all, Screens is not a direct competitor for Saguaro... while they seem to improve PalmOS capabilties they do so in two different approaches. Saguaro is more graphical & faster while Screens is more flexible but slower. Screens is very technical at the moment untill I get Safire up and running and then you will start to see the power of Screens shine. Untill then, technical points are going to be the highlight of the blog. I can't wait to get to the GUI but I dont want to rush it nor to do I want to take forever. You have no idea how many times I have to convince myself to not rewrite Screens but rather fix the existing code. I have rewritten Screens to many times and its about time that a version lasts more than a year. I am doing some fine-tuning in the kernel before writing Safire so I can better design the Safire component. I already have the basic design which is about how shapes become pixels on-screen. Things are going well... About the demoing... once I can give a demo to show on your devices, I will release the code in a compilable project including the final executable so you wont have to compile Screens.

Saguaro, what is it?

I have been seeing alot of interest in Saguaro lately.... First of all, its not mine. Its nice to see interest in it and I was able to convince the developer to allow me to upload this video to wet your lips with multi-tasking fever, Edit: Here is some more info: http://www.pdaperformance.com/products/saguaro.html Enjoy!

Kernel Released

Hi Everyone, This is it, the Kernel is released at http://sourceforge.net/projects/screensos Thank you all for getting me to this moment, I could of not got to this position without all your support. The version 0.46 works and can be compiled for Win32 or Garnet (palmOS) platforms. The readme in the zip file gives some basic instructions how to compile the kernel. Once the kernel is compiled, you can create a new project, add the files from interface folder with the platform specific files (either Core_Win32.c or Core_Garnet.c) to be compiled and use the test.c file to use the kernel. I compiled Win32 in Visual Studio Express 2005 and Garnet in Palm OS Developer Suite. If any of you do try this and things dont work dont hesitate to email me at zhamilton1@yahoo.co.uk I have already uploaded new code to SVN and will make versions as time goes by. The new code simplifies objects by using a node flag instead of relying on unnamed nodes. This makes lookup much faster which is very important. I will improve performance as I start using it with the Safire module. Thank you all and have a wonderful year, Zakai Hamilton