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.