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!