Bummer

I come home last night to code and my hard-disk died on me... thank god that I uploaded the sources online, my email is online, my msn is online... so I didn't lose much... I plan to buy a new hard drive today so hopefully I can get up and running tommorow. Here is a document I wrote a while ago which sums up alot of the features that I wanted Screens to have: http://www.geocities.com/zhamilton1/ScreensEnvironmentKernel.doc Hopefully this will be a change in the forever looping of Screens Environment...

I am not going to make it

Hi Guys, To tell you the truth, I don't see myself being able to code the alpha by the end of febuary. I am still getting stuck on the object storage. For other OS's the bootstrap might be what kills the project... for Screens... it feels like its going to be the object storage. I have all these ideas in my mind, and I just can't seem to close in on this object storage. I also don't see to have much time lately because of my job advancement. I tried coding on my handheld but my fingers ache. The life-drive might help in that department since it has a larger display space but I doubt it. I have all the designs in place but its the little things that are driving me insane. I realy dont know what to do and unless I get some real help in management, I dont see Screens going through. Yep... that's what I need... A manager for Screens. Over the years I have tried to find a partner for Screens... or someone who could deal with the marketing and 'deal' with me in the sense of planning and those little decisions. And I still haven't found one. I am a bit isolated in the sense that no one around me are geeks. I think I am about the only real geek in my entire area. I need someone to join the team... and no... there is no money involved... Screens is public domain so there is no money made here... It's just one of those "I wish for A and no one will make A, so let me try". Anyone interested for giving my some guidlines and education? anyone? Bill gates has Steve Balmer... I need a Steve Balmer on my 'team'. Anyone interested?

Update - Code on the go

OK, last week I didn't get anything done... so I have decided to start coding on my handheld via OnBoardC.. I travel every day nearly 3 hours so I think that it would be great to use that time for coding Screens. I am buying a life-drive at the beggining of febuary so that should help a bit with coding on the go. I however did get to talk to my MSN user group and thanks to thier comments, the alpha looks like it will still be on schedule. My multi-tasking design allows me to focus on the alpha and push the multi-threading to a later stage until its realy needed. There is no point having threads if I don't do anything that needs them. Threads just for the sake of it is not the point. Every module has the overhead of the item store which it can read and write to. I am now coding the item store database implementation so that it will use a resource database instead of dynamic memory. This will give it more persistance. The alpha user interface is not going to be defined in the alpha code but rather it is released in the item store database. This means that the alpha will have to prc databases: one for the alpha code and one for the item store. The advantage is that code is kept small while the item storage can then be modified at any time. I will actually be writing the user interface in XML and converting it to items. The advantage is that I can make changes without recompiling. I will make a small utility which will take a Palm DOC database in XML and create an item store from it. It will also allow to export the item database into an XML based DOC database. The advantage means that I can make tweaks to the user interface and only have to ship the item store database and not code changes. And you get the advantage that you can tweak it yourself ;)

Update - Real tough week

I knew this would happen and it did... This is going to be one of the most toughest weeks before the alpha. Let me explain why: One of the most important things in any OS is how one peice of code talks to another. At first I thought I could do this through shared memory. But that just turned out to be an absolute no go. Each module is going to have to know how to read and write to the object storage. The advantage is modularity and flexability... the downside is that any major design change that I make to the object storage will break all existing modules. This requires to recompile all modules if I change the object storage. This is ok in the alphas and betas since I am the only one writing modules but after 1.0 I am locked into this specific implementation for many years to come. I'm going to take that chance. I am going to do some cleanup in the code this week removing the complex bits in the code and making them simpler. I am also going to make the memory components now use the ObjStore.prc resource database. I am also going to start a new project in the workspace called 'Shell' which is what you users are finally going to click on in the PalmOS launcher. OK... so what are the multi-threading biggest limitations: One running instance per module - This means that two instances of the same module will not run at the same time. One instance must finish before another instance of the module can be active. Think of it as each module has an instance queue and the first instance in the queue is the 'active' one. This does mean that other modules can do calls to modules without worrying but it means that if you have a module A in a loop and module B tries to call module A, module B will have to wait untill the first instance of module A ends before it can call the second instance of module A. Cooperative multi-tasking - This means that if an application does a loop without calling any external API function, the system is stuck untill the loop ends. This is like Windows 3.1 but since any API function can yield, it will only be noticable for situations when calculation loops are long or stuck. The lucky thing is that even if the code gets stuck and you need to soft-reset, all the user interface and data stays intact. The project is realy getting into shape... but its going to be a hard job untill I finish Screens Environment's basic structure... Wish me luck! Edit: OK... I think I missed something... 1. Screens Environment runs cooperative - While this is true in Garnet, there is little stopping Screens from running pre-emptive in the future like for PalmOS Linux. For developers who will write Screens native applications, they wont have to worry. There is a limitation if Screens did run pre-emptively which is that a single module would never run two instances in a pre-emptive environment. This doesn't mean that two instances cannot switch, it means that code of a module wont able to run using interrupt based multi-threading but rather only via cooperative multi-threading. This means that if a module does an endless 'while' loop... on Garnet, Screens will halt untill you soft-reset while on PalmOS Linux, Screens might continue to run but any code that is dependent on that module will halt. I know it sounds terrible, but its not realy that bad especially since the user interface is seperate from code so even if an application 'halts' the system, your changes are not lost.

Update - Research week

Ok... this week was more about learning than coding (last week was more about coding than learning). Not only did I get to go to a Effective C course this week but I read two books about Windows (one about 3.1 and one about CE) which were filled with kernel details. I also must thank my father for getting some sense into me about 'pre-mature optimization is the root of all evil'. I have put more design onto the multi-tasking model so that I can code it next week. It won't be fast but it will work. Optimizations can come afterwards. Code clarity is more important. The way it works is that each module calls another module via the kernel. The only way for modules to exchange information is through the object storage. Each call is done using SysAppLaunch but saves the stack of the module before hand. The kernel holds the schedular which chooses which task to launch. A task is either a sub kernel call or any other module. A module can only call the kernel. The kernel can queue a task which is executed at another time. This does mean that even though a module thinks it's doing a sub call to another module, it realy isn't. Instead its queuing up a call to the schedular. The kernel always returns after every thread switch which means that for systems that require response at all times can use Screens Environment since the shell is the application that says 'OK kernel, call your next thread call'. The shell also is responsible for sleeping or stoping the kernel from running. It is also responsible for passing key and pen events by calling the appropriate functions. The shell is the PalmOS application you see when you goto your launcher. You dont run the kernel directly, you run the shell which runs the kernel. Think of the shell as win.com used to be ;) Reading and Writing to objects is done using shared memory which is allocated as system memory blocks. When you read or write to an object, the memory block is purged so you cannot use it again. Think of it as a one way channel to send or recieve information. Each kernel call can pass one memory block and recieve another. Its up to the kernel to purge the passed memory block and up to the module to purge the recieved memory block. Note that the framework will do all this for you. All you do is call the API functions. Everything else is handled for you. That's enough specifics for now... For those who don't understand... don't worry about it.

Update - Things are getting done

Finally, things are getting done... I have nearly finished the surface component (to create offscreen buffers) and hopefully today I can get some rectangle and line drawing. Then I start working on the layering code elements. Once that is done, I'll be very happy. I am trying to make things very simple for the alpha and cutting out any imediate use features such as multi-display support. While users wont notice the difference, it does mean I might have a harder time in the future introducing such a feature. I'll keep you updated when I finish the elements code with maybe some screenshots ;)

Update - Finally a written object storage

Updated the source ;) I dont believe I got to this position... here is a list of components coded so far: SaturnMemory, SaturnChunk, SaturnItem, SaturnData, SaturnFolder, SaturnFile, SaturnProperty and finally SaturnType. The code compiles but has not been tested... I plan to do bug testing when I have something usefull to test with which is after the window management is written. If you look at the code, it's got loads of comments, so if any of you want to go through the code and point out bugs to me... that would be helpful. So what's now... as I said in the previous article, I will now be working on the drawing model. OK... so I want to let you know of some of the user interface policies/issues/ideas that Screens I plan to do for the 1.0 release: 1. No Tap Count - Screens is not going for the least number of taps. Yes... if you think you will be able to do simple tasks in the least amount of taps... use PalmOS. Screens is all about balance of all features in a usable design. The least number of taps does not mean the easiest to use or the fastest way to get to something. You dont have some kind of time-limit on your taps... so sometimes two quick taps is better than one long one. You will notice this alot when you deal with objects since nearly everything pops up a context menu when you tap on it. Yes folks... 2. No Secret Pen Tricks - No tap and hold... I have thought of this feature time and time again and just dont see to find any justice for it. I know you many of you are used to left-click defaults and right-click context menus but for Screens... the left click IS the context menu. I know its going to take time to get used to this... Screens is not trying to please anyone by copying some other OS (you know who) by these windowing shell features. I want to try out new things and what better way then with a new project. No double taps either or any other combination of secret drags and drops. Everything is visually visible in Screens and I plan to keep it that way. When you drag & drop an object, you will know exactly what its going to do. You wont have to guess what the action will be (move, copy or maybe poof like in MacOS), you select the action. While this does mean an extra click for the default... I think it makes the feature more worth while for a extended use than guessing the default behaviour of things. Many wish the UI would just know what I want... I dont... I want to tell it what I want because sometimes even I dont want to do what I think or prefer. 3. Extensive use of the 'Go' slider - Yes... The sliding icon bar is going to be used as a very central part of Screens. The slider is a flim strip like bar which sits above the widget bar and when you tap on the sphere in the widget bar, it will popup the slider. The slider is your gateway to launch applications, switch between applications, goto settings, the applications menu and so on. I realy hope you will like this idea and I am sure it will get refined as time goes by. No one has gone this way before. You can find an old editorial I made on the idea here: http://screensenvironment.blogspot.com/2004/08/icon-based-menus.html 4. The Widget bar - The widget bar sits at the bottom of the display with the go icon in the center (the icon raises a bit higher out of the bar). You can tap any unused area in the widget bar to show the Widgets window which you can add new widgets to the bar. Tap any widget to show a window representing the widget, so tapping the Time shows the 'Diary' window where you can see a today like screen. The default has mostly an empty bar with the time on the right. It allows to put any of the features you use the most on the bar as your personal preference goes. Dragging widgets off the bar - remove the widgets but not with a poof but rather undock them where you can either close them, put them back on the widget bar or have them hovering above all other windows like post-its. While widgets will be code based at the beggining, I see a future of script style widgets as well. 5. Hybrid Browsing - Yep... Screens is going to be more spatial than any other spatial system known to date. Everything has its color, position etc. But it doesn't mean that if you want to dig down some folders that you have to be spatial about thier location. Screens extends the browsing to not just a navigational OR spatial browsing but rather a spatial AND navigational browsing. You can position all folders and document windows in your locations (wont have much use on such a small screen but when we get to terminal futures...you will get the picture) but you can also dig down in a navigational window to any folder you want like a link refers to another object, a navigational window can refer to a spatial window showing it in another size and position and even a different view. Think of it as a temporary clone... That is... Everytime you dig into a folder in a navigational window, it makes a copy of the spatial window and applies the navigational window settings to that spatial window copy (like the view, size, position) and so on. Your original spatial window is not affected. Only when you make changes to the spatial window are the changes kept. I find this a difference between temporary browsing (navigational) and common browsing (spatial). 6. Sessions - Ever wanted to stop your current task, just to do another quick task and return to your other task but forgot what the original task was when you finished the first one? Well... Screens understands your problem. Screens allows you to work on windows that are to do with a specific task or session and if you want to suddenly work on a new task, you can just create a new session and it puts a half transparent layer on top of your existing work and allows all new windows opened to do with another task. Want to return to your previous task, you can either switch to its session or close the new session. The advantage here is that any change you make on one session such as moving windows does not affect the layout of another session. I believe that looking up a contact or creating a quick appointment or jotting down a note wont distrubt your workflow. Sessions can be created automaticly like when you get an email notification, if you tap on the notification, it creates a new session for you to read, reply and manage the email message. Once you are finished... return to what you were doing before hand. This is just a tip of the iceberg of innovation I have in my head just waiting to be implemented for Screens... Enjoy the teaser of words ;)

Update - Things are moving at great speeds

Hi Guys, I have a few functions left and I start coding the drawing components. After talking with my MSN user group, we decided to push any pixel effects such as alpha-blending to the beta cycle and leave the alpha for the basic stuff such as the interfaces and general structure. The first alpha is right on track for febuary and hopefully you will like my GUI ideas up my sleeve. Note that this is NOT trying to be a launcher like ZLauncher. I am trying to create something NEW, NOT be as close to PalmOS as possible. I got the feeling that some users thought I should go the 'be like somebody else' idea. Screens Environment deserves to be unique. If it's not going to change the face of the earth, what's the point of Screens in the first place. There are enough launchers out there. Anyway... I should hopefully figure out the function names (my hardest work... seriously) by the end of the week for the drawing component. Once I finish the drawing component and do a few animations, I will start working on the layer element functions which allow you to treat the display like a canvas and just draw layers and layers of drawings one on top of each other with clipping and transparency. The advantage is that as long as you dont do pixel effects (only supported in the beta stage) you dont have to worry about transparency colors. Once you do pixel effects, you must specify a layer which is like a mask but with the ability to allow gradients and shape based alpha blending. Remember that the animations are important and they are frame based which means that on slower devices you dont get a slower experience. Rather the animations are displayed with less frames. The advantage to this is while there is enough processing power, animations get displayed with full frames. If you are doing background proccessing, the animations frames get shortened. This allows you to enable all animations without worrying about it slowing down your device or experience.

The year of Screens Environment

Hi Everyone, Happy new year! This is going to be the year of Screens. I have the alpha coming out in febuary (probably at the end of febuary) and I have great plans for this year. First of all, know that I have been coding more than ever. I decided to rewrite the entire object storage to not only make it much more simpler but to go by the KISS rule (thanks to the MSN users). But dont worry, its been mostly coded already and uploaded. You can find nearly all of it here at: http://www.geocities.com/zhamilton1/Saturn.zip So what do I have left for the object storage? Two more components that I should finish tonight: SaturnProperty and SaturnTypes. It basicly allows to specify properties to objects. I am very happy with the current implementation. While the object storage will be updated before the 1.0 release, it wont be touched untill the first alpha. So, I have about two months left... So I will be now concentrating on getting the UI stuff going. I have had alot of experience building my layering engine for NDS and now its time to put that magic to Screens Environment. So I will be focusing my this month on the UI stuff like windows and controls. Note that I am not going to be implementing the Sony API's yet but hopefully will do so for the 1.0 release. Also I will only be supporting 320x320 resolution for the alphas. The 1.0 release will have multi-resolution support such as 160x160 or 320x480 with rotation. The first alpha as I said before will include the basic desktop with the widget bar and a few widgets. If I have time, I might add some more features, but this is the basic stuff if time is short. While everything is currently coded directly into the kernel, I will support 3rd party modules in the beta cycle. This is the year you have been waiting for... 2006