Update - Internals

OK... so alot has happened... I have fixed alot of my 'year and more old' problems and found solutions for them from how to do inheritence (fixed today), How I deal with UIDs and even my syntax for the API has been improved to be more object oriented. I have made it that objects can be created without specifying where they are stored, instead they can be attached later on. UIWindowInfo MyWindowProperties; MyWindowProperties.Name = UID_MyWindow; MyWindowProperties.Title = CoreStringNew("My Title"); MyWindowProperties.Region = CoreRectangleNew(0, 0, 100, 80); MyWindowProperties.Align = AlignCenter; UIWindow MyWindow = UIWindowNew(MyWindowProperties); I will continue to refine it as much as I can but its much better from my existing syntax design. Simple types can be defined with parameters (CoreStringNew) while complex types are defined by structures (UIButtonNew). UIDs are declared by the following: #define UID_Name UIDPack(Company, Application, Module, Name) Where the Company is a number registered at my future web-site, application is unique per company and module is unique per application, and name is unique per module. I solved how to store inheritence with a combination of static and dynamic lookup. Its quite a good solution which I might post about another time. I need more help to get this project of the ground... if any of you want this project to be out quicker... please post questions or comments via email, posts or MSN Messenger.

Update - So what's cooking?

Hi Everyone, I have fixed another huge issue I had with the object storage which is 'virtual objects'. I have made objects to be able to mount and unmount without loosing links and relationships between objects. This is a great change since it means I am one step further solving all the quirks with my object storage. The object storage is the 'core' of Screens, so it has to be flawless (not in functionality but in reliability) for Screens to be built. It is the biggest building block in Screens and is the base of any functionality I have in Screens. Screens is moving... yep it is still going... I have already decided what Screens 1.0 will include which is basicly launcher capabilties and db/file manager capabilities. Screens 1.0 is basicly a 'launcher' and will be marketed as such. It is designed to be a technology preview. As time goes on I will add extra apps such as calculator, contacts, diary, paint and so on and wrap them into one package for 2.0 That is the basic plan, since I want to release Screens as soon as possible in some 'stable' state... taking the launcher route allows it to be a stable launcher and still be released early... how early? No Idea... I'll give you a 'real' destination date once the core is coded, that is basicly whats holding this project back = The Object Storage

Update - Where is Screens?

Hi Everyone, I haven't posted for a month and this post is explain why. Fear... fear of getting smashed was my reason untill I realized that it's my blog, so anything that happens, I can post without any problem. My blog, my reactions. Alot has happened in this last month which has required me to reget a big picture of Screens. Screens is not about being a good-ol launcher replacment or some niche enviroment to show 'I can do it'. Its about a stratergy and vision which I have and applying it to PalmOS devices. This stratergy and vision is not about handhelds today but more about tommorows handhelds. Todays handhelds are very limited, not in the hardware (my opinion) but in the software. If the software was top notch for the hardware, I would say the hardware needs improvement but today the hardware is driving the software. The same happened with PCs and which is why we never see any radical stuff happening... Because hardware moves slowly and thats how you see the software move - SLOW! Screens is designed to get the most out of the software and let hardware follow instead of being the leader. So what's been cooking: 1. Palm is making a linux-based version... Great! What does that mean for Screens... a great oppertunity. First of all, there are loads of different devices out there... and new will come with different specs. This will be hard for developers to code for all the different types. Screens solves that by design with it's action-key mapper for example. 2. Multi-tasking I think I have found a way to do semi pre-emptive multitasking which in this itself is a good enough reason to restart coding. By starting from a pre-emptive perspective (or even cooperative) I can let go of many old designs such as using a modal dialog for copy operations... why not show the progress under the object label itself. It gives Screens more room to innovate which I think is a good enough reason to reevaluate the core. 3. SMPI Screens has already defined a new syntax design which so far... I'm loving it. Instead of doing API, I am doing a SMPI (Screens Module Programming Interface) where the syntax is based more on modules than on applications. So far... so good. That's quite a short summary... I will probably (hopefully) write a few editorials on the matter. just remember that if you want Screens out faster... to help me speed up the proccess, PLEASE chat with me on MSN Messanger at zhamilton1@yahoo.co.uk

Update - Object component on the way

What a busy last week... I rewrote the tree component twice. why? Because the new design is much better in many ways and smaller. But dont worry, it's already been coded so there is no schedule changes. I wont spill the internals, I do that too much but it looks good & simple. So... the schedule is good so far... I finished the first two components in two weeks. I now have 3 weeks to code the objects and links components. Well see how long it takes me... The object component takes the tree component and encapsulates it to hold objects with relationships between them. The links component deals with the relationships while the object component deals with the object itself and the stream of the object. I just bought myself a PDA keyboard (using IR) so things should speed up since I can write more of my design, ideas and comments on my handheld. I am glad things are finally 'happening' and I hope to show you all something as soon as I can.

The tree component - Coded

The list component was removed and the tree component was coded instead. It was a logical move and I am glad I finished programming the tree sub component. What's the difference? The tree component encapsulates the data component (so I only call tree functions from now on and not data functions). This is the step before the object component which lets go of the 'structure' sense and allows a free-form storage. It allows objects to have a structure internal which is much easier to view because of the tree aspect. I can browse for objects much easier and can store other information apart from objects as well without hurting the performance of the object querying. Every item can hold both sub items and a stream allocation. This allows a registry like design to implement objects with. Every item also has a nameUID and typeUID so it enhances the overall use of the tree component to hold anything core. All outside components (like the layers component) only use the object component API. Many of you ask me about my schedule? Well... so far I am right on schedule. It took me so far one week for the data component and this week for the tree component (ex list component). The next three week schedule is for the object and links component. They are very to do with each other so it was only naturual to include them in the same time frame. Unlike the tree and data components which have been totally designed before coding, I have many small/large peices for the object component which need to be 'merged' which is why I gave myself 3 weeks. I prefer not to disclose the after object schedule just in case I dont meet the 3 week deadline. Understand that I am working day & night and I am very dedicated to the project so what I need mostly is patience and feedback (via comments on the posts, email or MSN chat at zhamilton1@yahoo.co.uk). You will see much more posts since I want to keep you all much more involved in the proccess.

Mockups

I constantly get requests to create mockups. The problem with this is that I dont have the right tools to do them (I used MSPaint on ALL of the mockups and I dont like GIMP) but the more main reason is because the mockups would not reflect any 'real' part of Screens. So when will we see mockups? When the layers component is coded I can create mockups. Why? Because the layers component reflects the graphics capabilities so any mockup I create through the layer component is doable later on. So instead of creating effects I dont know I can support, using the layers component becomes a semi-screenshot. Also the vectoring allows me to produce multiple resolutions of the same mockup. How long is left? I have a schedule but just as all my schedules it is built on a 'everything works' schedule so I prefer not to disclose it at the moment but I am working very hard (every day) to get there as soon as possible. The layers component is just after the core component so the core basicly is the 'sign' that Screens Environment is doable. Patience... if you want to help chat with me via MSN when you can... I am pushing myself as hard as I can without breaking my back.

What a journey

I was just browsing through one of my old (huge... 39 pages) of posts at 1Src (used to be ClieSource). Here is the link but be carefull... it's long http://www.1src.com/forums/showthread.php?t=5646&page=1&pp=15 It's quite amusing how it has taken me... Alot has happened... Got married is one of them which has been a wonderful experience so far ;) The biggest lesson I have learnt... resist pressure of releasing a product you dont want to. I look at my today's design and it's not the functionality but the design. It's much more mature and more powerful and flexible and most important: Simple Many of the 1Src users will probably be laughing if they get to see a working demo of this environment because frankly I stopped believing sometimes that this project would ever see the light of day. It's been a great journey and I am proud of it. You might notice the sudden 'kill' at the end of the thread... I got a few hard private messages which made me go down under untill I got this blog going. So here is a set of old mockups that were made: (notice the differences) http://www.geocities.com/zhamilton1/Battery.bmp http://www.geocities.com/zhamilton1/Main.gif http://www.geocities.com/zhamilton1/SL-5-15a-3.gif http://www.geocities.com/zhamilton1/SL-6-1a.bmp http://www.geocities.com/zhamilton1/SL-6-22.bmp http://www.geocities.com/zhamilton1/SL-7-4.bmp Here you will find a huge collection of mockups I made throughout the years: http://www.geocities.com/zhamilton1/MyPictures.zip If tapping does not work on the geocities links do a save as (right click->Save as) because sometimes geocities does not allow direct linking. This should give a few of you (who have been with me for sometime) some nostalgic feeling. I got alot of good memories just flipping through the mockups. Enjoy!

Update - Coding the list component

So... last week was very busy... I finished the data component but then when I started coding the list component I found a missing data function (DataCopy) so I finished on thursday coding & testing the function. This is used alot in the list component when moving buffers around. I have already finished coding the ListNew function and should finish the entire component by the end of this week but it might not happen because of other things in my life which are overlapping but this is plain coding time not design time. The list component's design is fine. I should find time to write a few more editorials soon so keep a look out on parts of Screens vision. Bottom line is so far... so good

Update - Data component done

The data component has been coded, tested and it works! Things are moving fast and I am working extremely hard to finish this core as fast as possible. The source code has been in a comment line then function line design so it is very easy for me to reread the code (which I forget very fast). The next component is the list component. Hope to finish that soon so I can get to the meat of the core which is the object & links component. The list component has no problems in it's design so the coding should go very quickly (especially since its only using the data functions). I have a private schedule which so far I am way head of but still keeping it intact just in case I get stuck (probably in the object and links component). That's the programming barrier I have at the moment, so once I pass that it's all downhill for the core.

Update - Were on the way

Ready, Set, Go... we are on our way. Coding has started. I have already finished two functions of the data component and should finish the rest of them by next week. The perspectives are better than I thought and by making differences between the internal API, private API and public API it allows the internals to be completely covered (developers can only use public API's). The next component: List List takes a data allocation (from the data component) and allows to create an array of fixed structures. This is used to make the relationship lists, object lists and so on. This is a private component and therefore has no public API. You will start seeing 'effect demos' when I finish the core (since the component after that is the layers component). One of my favourite effects will be when a layer is updated/shown/hidden it will not just update the display but transparently appearing forward while the old layer state transparently fading to the background. This will be great for transistions between panels and showing/hiding windows. The effect will be disabled on devices that are not color (grayscale) or that it's too slow. Note that all animations get cut down by the speed of the device. This means that the effects will hardly ever slow down performance. The effect demos should show some things that Screens will able to do since the layers is the heart of the drawing design.

Update

So here we go... I have been spending alot of time this weekend researching and thinking about the code aspect like the use of the SysAppLaunch function used to pass control between function calls (using the ScrAppLaunchCode launch code). If anyone wants to know the speed of the SysAppLaunch try changing the time in the prefs app and quickly tap the find silk button and count the number of seconds it takes for the find dialog to show. This is going through every application's PilotMain even if it returns straight away on most apps. I have also made sure that this method is compatible with PalmOS Cobalt. The object component API has now numbered sub components and I am getting closer to the end of the perspective design and naming the functions. Once the function naming of the core (the object component) is done I can start coding the data sub component (hopefully). Screens is moving along and is showing more and more opportunity as time goes by. I have decided that by releasing the final release (demos will only be for PalmOS) on both PalmOS and PocketPC at once will allow Screens to get more users and because the changes are minimal, there is no 'cost' for the porting. The only problem is that code written for PalmOS wont work on PocketPC and visa versa. I might think about using java since it's platform-independent and all it needs to do anyway is call the Screens API. However drivers or any software which uses API's outside of Screens should be natively coded. If I could get the java idea to work it would allow the core to be natively coded and most of the other apps to be java compiled.

FAQ

Many users ask me the same questions so I hope this FAQ will help ;) Post question in the comments so that I will answer them here... 1. What is 'Screens Environment'? Screens Environment is a project to create a simple, stable and easy to use operating system. However unlike other operating systems, Screens has no 'legacy' baggage, works on top of existing mobile operating systems (at the beggining PalmOS and then PocketPC) and is built from the ground up to be very flexible and powerful and most of all expand easily without all the limits that haunt other mobile operating systems. 2. Why create a 'high-level' operating system? I believe that low-level operating systems (such as PalmOS) seem to be to much dealing with the internals than the user features. This is not bad, but it does require a high-level which takes advantage of the low-level features provided by the low-level operating system and create a high-level version of it merging many low-level features into single simple high-level features. Think of the low-level OS (PalmOS) as the behind-the-scenes while the high-level OS (ScreensOS) as the user and programmer interaction. 3. Is 'Screens' a launcher? Screens Environment has a launcher... but that's like saying that a plane has a bathroom. It's the whole package which makes it into an OS. It's not just an application but launches applications inside of it which are coded with the Screens API. It also can switch to the 'low-level' OS to launch the low-level apps. This provides 100% compatability to the device. It provides the high-level capabilities to apps coded with the high-level API but can still switch to low-level apps. 4. Why are PalmOS apps low-level? Have you seen the PalmOS API.... It's got internals written all over it. Not that it's a bad thing. It served it's purpose at the beggining for speed but devices are getting faster and requiring much more powerful apps which the PalmOS API just cannot give. This is why so many companies have 'common-code' base which just bloats the app size. Screens gives these needed features right from the Screens API making coding even high-featured apps a breeze. 5. Does Screens support HiRes and HiRes+ resolutions? Yes... but more than that... Screens has window management. Which means that you can move windows around, switch between them, maximize and minimize them and of course close them. Screens uses a icon-based-menu (a horizontal icon list which slides when dragged) to allow easy switching between windows. Because Screens is vector-based, it can use the high-resolutions to show more detail or more workspace depending on your choice. 6. How many Screens 'High-Level' apps can you launch at once? There is no limit. This is because even though an app is launched, it's not actually using CPU or even dynamic stack untill it's actually using the CPU. Screens takes advantage of the execute in place feature of PalmOS. For PocketPC which does not have the execute in place feature it swaps applications in memory by thier usage. So even on a PocketPC with 100 windows shown only the applications actually running (sending messages to the message loop) are in memory. 7. How does Screens handle data on the different platforms? Is it different per platform? No... Screens comes with a object oriented storage. This is the same over all platforms. The OBS (Object Based Storage) supports classes, extensions, relationships, meta-data handling, overriding and more. OBS is a hybrid of C++ object oriented design and object oriented storage databases. It is the core of the entire OS. Everything from the message loop, windows, input, network to appointments, files, multi-media is based on objects. 8. What does OBS give for the programmer/user? For developers, it provides an easy and common way to describe the data of thier application, store resources and build libaries and components easier. For users it provides a common interface to search, organize and create information. Want to attach people from your address book to an appointment - no problem. Want your PC to download a big presentation to your device for a specific appointment and remove it when the appointment finishes - no problem. Want to find all the documents in your device which were changed or created in the time of your buisness meeting - no problem. The possabilities are endless and even I dont know all the ways you will able to take advantage of the storage. 9. You said libaries... What about DLL-HELL? DLL-HELL is what users hated alot in windows (and other OS's) because when an old application needed a specific libary and a newer app using a different version of the same libary existed on the same computer, there was conflicts which caused the need for libaries to be as backwards compatible as possible. Screens solves this by not even going near versioning. It solves the problem from the core. Instead of libaries being fixed code blocks holding old and new code, libaries build apon existing code without having to have the old code in the libary. When a libary wants to fix, replace or extend a function, it does not edit the original code. Instead it creates an update just with the fix. This is using the power of replacing/extending method objects. Sounds complex but when you get used to doing it the Screens way, you will find that updating old libaries is better than creating a new one from scratch. In a way you are creating a new libary from scratch but you can use all the existing methods that work fine from the existing version. When a user installs the libary it installs the original and all the changes over time. I'll able to have more information when I code the actual design. 10. Does Screens support multi-tasking? Cooperative multi-tasking just like DOS, PalmOS, MacOS (9.x and previous) and Win 3.11 This means that if an application freezes the whole OS freezes which requires a soft-reset. Screens uses the capabilities of the low-level OS and does not add any extra low-level code. Since PalmOS does not have multi-tasking capabilities (up to Cobalt) neither does Screens. However in the future (Cobalt and above), Screens will probably support preemtive multi-tasking. 11. So a single application can ruin all my window layout and changes? No... Screens stores everything in the object storage which is persistent. There is no 'Save' button. All changes are immediate (but there is undo) so even if an app does freeze the system after soft-reset you will see everything (apart from the freezed app) just as it was before the freeze. No other system has this and you will appreciate it from the first freeze you get. However Screens will be checked all the time so that it is bug free on releases. 12. Does Screens support themes? Yes... but deeper than any other OS out there. A theme can affect the entire look but also the feel. For example: when I release Screens publicly, I will also work on some other OS look-alikes. The Windows theme will have a start menu and task bar which will work nearly exactly like the real windows start menu and task bar (however the tap bug of the 'Start' button is fixed). The gnome theme will have the top bar and bottom bar and the MacOS theme will have a global menu bar approach. Users can create additional themes. 13. But Gnome has the virtual workspace buttons below... How does Screens deal with that? Screens supports multiple users and multiple workspaces per user (with password protection per user). So the virtual workspace buttons are fully functional. You can also apply policies per users so for example: a kid user could be limited not to install new apps or run 'low-level apps' while a admin user could be able to switch to all users without a password but not visa-versa (allows quick access to your own user acount without having to use the password). This allows to have multiple depths of security levels. 14. This is all great but when will it be released? No idea... I am working hard day and night to get the core coded. Once the core is coded (basicly the object storage and basic window management) then I can release some alphas. Check up weekly on the blog to see how the progress is coming. I have been working on this project for more than 2 years and have my own funding so there is no normal reason this project would be 'halted'. I am not building a boot-loader so I am not stuck there ;) If you want answers to any other questions post in the comments section and I will update the FAQ ;)

Update

Hi Everyone, Last friday was a great day for Screens since I was able to solve the internals of the object component which is based on a 'snack-machine' design where you can see all the different objects (objects with different name UID's) in a list and each object has a sub list holding all the objects with the same name holding the source and target of each of the 'duplicate' members. This design is fast because it allows classes and extensions to be modified and the update is done dynamicaly. There is no need for run-time checking for the correct override behaviour which makes the system very fast. A few users have already liked the new design. The object browsing of members API has been defined and has a macro which makes browsing very simple. Take a look: ScrObjectList(HContainer, HMember) { if(ScrObjectName(HMember) == UID_WINDOW) //Add code here } This code very elegently will loop through every member of a specific object (HContainer is a handle) and set the current member to the HMember handle. So any code in the brackets will be acted on any member in the collection. This makes it very easy to search, manipulate multiple objects very easily. The ScrObjectList is actually a macro which deals with the loop for you. Compare that to any other meta-data system out there. It's ideas like these that can make an OS very easy to code for however require a great deal of time to think of. What is left for the object component now that the object manipulation and object member browsing function names are designed? The browsing/creating/removing of classes and extensions (extension API can come later though). The class behaviour is the most important. The general prefix is something like this: Here are a few examples: ScrObjectNew ScrObjectFree ScrWindowMove CodeDataWrite Scr prefix is used for all the public API wrapper version while the Code prefix is used for the non-wrapper version. is used for internal (not to be shared outside it's source file) functions. This design makes it very easy to keep track of the multitude of functions. A huge amount of time is spent on not only the user interface and internals asspect but also the programmers view since a programmer is also a user so why should it be hard for a programmer to code. If coding was easier we would see more qaulity applications which is what I plan to show with Screens Environment. Know that the data component is totally ready for coding just waiting for the object API to be finished and I code away the first component which encapsulates a PalmOS database for read/write of records. It's functions took also some time to design however there is no public API (wrapper version) for the data component. This is because I dont need programmers touching the internals of the data component. The only component which does this is the object component anyway. Work is going well... and even though I dont have a working version I am very happy with the design. This is not your average OS... find any other OS that is using it's INTERNALS object oriented with run-time class support. This is not Spotlight or WinFS... The whole Screens Environment is composed of objects in the object storage from the message loop (yes, you can extend the message loop like to support real multi-tasking the future) to the window management (want to add a drop down to the close button on a tap & hold just add a tap & hold method to the close button control in the title control class which belongs to the window class). The possabilities are endless and very flexible which makes life easier for me and any programmer (and users) who make applications for Screens Environment. If anyone has questions... post them here or send me an email at zhamilton1@yahoo.co.uk

Smart Playlists

Nearly all the latest handhelds have music capabilities. Many of us have huge collections of music files on our PC. But with very small SD/MMC/MS cards there is not much room to store the vast amount of music we have available. So we manually move files back and forth which results in alot of wasted time. Many of us are just to lazy or frustrated to do this so we leave songs on our handhelds for even a month or two swapping just a few songs. An object storage could ease this by allowing to select files from your PC and allow them to 'swap' daily/weekly or even monthly on your handheld's capacity. However who has time to do this while at home/work, so why not do so on the way... have your entire music collection meta-data downloaded to your handheld and do the playlists from there (the meta-data is for sure smaller than the music itself). You could while on the bus create playlists, attach them to appointments (for start/end of the online range in which the playlists music should be on the device) and when you hotsync after the start of the appointment it will include the music files on the 'sync' and after the end of the appointment it will remove the files from the device making room for another playlist or other data. You can make the appointments recursive so that they continue to download once a month, week and so on. The user interface could make this functionality very usable by doing all the appointment work for you. If we took this a step further, we could say that all music with a high-rating are not rotated which means that if you like a specific track, just mark it high-rating and it will stay on the device even after the playlist's appointment has ended. The idea is that once the basic framework is implemented you can take this to boldy go where no one has gone before. I have asked many users and they dream for this feature. This is one of the reasons why I am pushing so hard on the object storage. It is crucial for the object storage to take these dreams into reality. This idea could be extended to other file types like documents. Wouldn't you like to not have to remember to download that presentation for next months meeting without downloading it now? I know many times that files that I wanted on my handheld were only valid on a specific date range. By not limiting the object type, it would allow to extend the same idea to any set of objects. This brings us one step closer to a world where it is not limited to 'NOW' but can remember tasks for the future. Isn't that one of the main reasons we have handhelds... NOT to forget future tasks... why cant it try and do some of them for us so that we dont even need to remember.

Update

Well... you are probably (if any one even reads this blog) thinking that this project is dead... oh well... for those who still have faith... here I go again: I will now code the core code seperate from the API. This allows the core to be more coded for the internal design than user easy coding and allows the API to be totally it's own design instead of sharing the core code. Since most of the core code is not even available in the API (Storage, Memory...) there should be less of a problem of designing for the user and can be more system oriented. The API also uses messages to send/receive functions while the core is internal and direct function calls. Note that the core is only the BASE of Screens Environment. Everything else uses the API so it gets functionality like inheritence and expansion qualities. I will be coding test code (to find API/Code problems) on my handheld daily while using the PC for actual releases. This allows me to find bugs before I get home since I have more time on the road (my job) then at home. I cant wait to finish the core code... you might think why it's taking so long? well... it's because the core gives me an easier start for the rest of the entire system. It removes the need of data structuring, classes (using run-time classes instead of code classes which allows system level inheritence and expansion plug-ins), memory allocation (virtual memory design), VFS file access and other file systems using plug-ins, window allocation and control manipulating and much more. The core is the 'system' which the entire Screens Environment design is based on. There is not a single component which does not benifit from the core design which is why it is so crucial to build such a design correctly. No other OS has such a system from the core for handhelds. When the betas are released, you might think that you waited to long for nothing but in very little time I can add features because of the core. My first version 2 years ago had loads of code behind it with just one line of code to display a window. This design has been implemented in the today version where little simple code calls loads of code which makes code more readable and debuggable.

Update

Well... What a week... My handheld hard-reset and corrupted my diary document (damn Documents To Go by DataViz) which means a few months of work down the drain and I now have to remember it all (or most of it). I have downloaded a new application for my handheld called 'Meteor' which has been very usefull so far in allowing me to structure my OS on the road. The storage and memory components have been merged into a single component called Data. It's been made as simple as possible with no stream IDs, just plain functions like new, free, read, write, size, resize, count, getbyindex and so on. I am still looking for users to help me via Windows Messanger (zhamilton1@yahoo.co.uk). So anyone at all (you dont need to be technical/programmer) who wants to help, send me a message. If you also want to help, you can post comments on each blog post you want to (by tapping on the comments number at the bottom of each blog post). Being married has realy helped the project, I am doing more work now then I ever did. I have at least a few hours a day I can concentrate on the more in depth problems. I am not coding blindly but catching every problem which flies my way while designing the API (it seems to catch most design problems). Once I have the data API coded it will be much easier to continue. Once the object API is coded then the party starts. So if you want to wait untill that stage... no problem ;)

My Plan

Many of you are probably reading through this site and adding it to a pile of existing either non-working or not bringing much to the table operating systems. This is not one of them and hopefully you will understand why... 1. I built no 'low-level' kernal I did not make a bootloader or any low-level kernal and dont plan to either. I am using the existing PalmOS platform as a base for my enviroment/OS. This gives me already some kind of streaming (PalmOS Databases), Display read/writie and Input (via pen/keys). This already takes me out of the dead ends most kernals have problems with and know the code works (I have a PalmOS handheld you know) and is improved over time by the company PalmSource (cobalt anyone?). 2. No emulating/simulating I am not going to support PocketPC software, nor will it be a Mac emulator or even a Windows/Linux simulator. Screens Environment will do one thing and that is run Screens written software (using the Screens API) when the Screens Environment is running. To PalmOS, Screens Environment is just like an application about as hacking as the PalmOS calculator = NONE! So you say what about PalmOS applications... although Screens Environment uses the 'Sub Launch' launch code it still needs the applications to register themselves before they can run any single call to the Screens Environment API. And even after that, no globals since sub launch does not support globals. Even if you know how to load your own globals - DONT for a simple reason... performance... An application can get more than 5 launches in a very small time period (like a few seconds) and that's talking about EACH application when multiple apps are working multi-tasking... which get's to my next part: 3. Cooperative Multi-tasking Screens Environement does not 'add' preemtive multi-tasking to PalmOS which includes scheduling also. Screens Environment includes a simple list which it adds application messages at the end and runs them (and removes them) from the start. This is how the current PalmOS works and I have no intension of messing with the internals of PalmOS to implement such a design. My design goals for this project are not imaginary and have been researched months to be made more and more concrete as time goes by. So I dont have it out yet... so what... I have been shaping this OS for more than one year (just to think about my design goals was a problem) and most of the second year (and still going) has been spent on just the CORE! What does the core include: 1. Storage This component takes multiple streams (like multiple dynamic allocations or multiple records of a database) and merge them into single long streams. This is to remove the known 64K length problem of untill today PalmOS versions (cobalt should relax the 64K length issue). 2. Memory Long streams are useless... so this component splits them into a list of allocations however with a twist. Data is stored from begginging to end of a stream while the header is stored in the opposite direction from end to the beggining. Both data and headers are added and not removed/moved untill they meet (basicly when you try to add data that will overwrite the header space) and then they are aligned. Aligning removes all freed allocations by moving allocations to be aligned one after each other (from begging to end for data and from end to beggining for headers) overwriting any free space. This means that data is hardly ever moved and aligning is done when you turn off the device anyway (dont worry... if you turn on your device in the middle... it stops aligning and continues the power-on and it doesn't take very long for a normal amount of time between power states, about a few seconds at maximum). 3. Object Now this is what is taking most of my time up... why? This is the object oriented storage system. Much like the future WinFS but on a smaller scale, it allows to store streams and structures of information in a single database with path and searching interactions. Supporting multiple classes and extensions per object, information can be 'typed' and 'extended' very easily. Each class and extension is an object in itself which causes a rich tree of paths. Each object also is a container and can hold objects or links to objects (links dont continue the structure). 4. Messages This provides the dynamic part of the object component using objects of type 'method' and doing inheritence/extensions when calling a method through an object (method objects are just stored as child members of an object). It also uses a 'messages' object to add/remove message objects that are posted via the message API. The entire programmer API is basicly made of message object postings. 6. Layers This uses dynamic objects (using the message API) for holding draw permatives like lines, rectangles, circles and so on which can be drawn on-screen at other times. All windows/controls use layers as thier underneath model for drawing to the display. Layers also provide transparency/translucency by using off-screen buffers. These are the core components that once coded, the rest of the system is basicly UI based features like multi-user support, window management and so on. This is not easy either but it's more easier to see it working forward than the core components. Also unlike the other components, the core components can hardly change once coded because they are hard-written code of function calls while using the object storage allows dynamic class management and extensions. If I write the window component to use only x & y coordinates, I could always extend the window component object with a z coordinate handler. This allows to always extend components without having to think much forward at all. Since extension handling is only run when you change an object's structure, most of these extensions go with hardly any speed performance loss at all (no I have not checked this... but using two message of two different handlers go through the same mechanizm as two messages for a single handler).

Double Design Direction

I am starting to feel like all these kernal programmer hobyists who feel like they are coding in the dark. This is not the way it's meant to be... I dont want to end up like all these 'dead' projects so I have decided to attack the problem directly. I will be coding from bottom to top (core to visual) like I have done untill now but at the same time code from top to bottom (visual to core). How is this possible? By seperating the graphics component from the object design it can be faster, bare-bones and allow me to make a 'mini-ui' to test the components that untill now have not been tested because I had nothing to test them on (walking in the dark). The graphics component (ScrDraw) and the text component (ScrText) will allow to draw directly to the display without any need of off-screen displays and the like. This seperation does not in any way remove the UI functionality that I want... actually it improves it by only making 'static' UI controls (buttons, lists and windows) using the layers component (based on the object component) while dynamic controls like progress bars, game views and animations using the draw component (no dependency). This will also allow me to finally give you all some visual progress on what's happening. I will able to post the 'testing' UI to show you all I am actually coding and not wasting my breath. How long? I have the system draw functions coded. I still have the text and generic functions like the mini-UI API but I should finish this by the end of the week. Then I can test the code of the first component (storage) and continue working on the memory component. I will publish the screenshots of the test UI as time goes by so just wait a bit more. I will be mixing between a CLI (Command line interface) and some graphical capabilities for the test user interface. This has nothing to do with the final UI and is for testing the core components only. If any of you have some ideas for the temporary UI post in the comments... I am always open for suggestions of any kind.

Memory Component

Good News... the API's have been locked (not modifyable untill the demo is released) and the first component has been coded. I am now working on the code of the second component. The second component is the Memory component. The memory component takes the stream that the first component (Storage) supports and breaks it into blocks. Each block is a memory allocation which is created in the stream so it keeps throughout application launches and soft resets. The header of each memory allocation is stored at the end of the storage stream. Header = StoreSize - 1 - (Index * HeaderSize) The '-1' is to get the last 'address' of the stream which is always '-1' because the address is zero-based. The number of header entries is stored in the first 4 bytes of the stream. The data of each header is stored between after the 4 bytes and the last header entry. The memory component works in an 'add-only' design. This means that if you remove a memory allocation the header data pointer is NULLed to specify that the entry is empty. No moving of allocations is done and new allocations are always allocated after the last allocation (if the last allocation was NULLed then the new allocation is written after the last 'valid' data). This allows for no moving at all of allocations in normal use. When does the system realign itself and gain all free space? When data is written and it will overrite a header entry (the data has reached the header part of the stream). All headers are compacted first and then it checks if it fits. If not it realigns all allocations. This might look like a large proccess but a few things remove the problems of this: 1. Data is only ever moved once in the realign. This is because everything is aligned from start to end. 2. Most realigning is done at the end of the stream since many of the allocations dont change thier location. 3. The Screens Environment automaticly aligns what it can when the device is turned off (mantience mode). This happens very quickly and even if you turn on your device in the middle, it stops aligning. This might sound a CPU kill but if implemented correctly the user might never actually see a single align message if the user turns his device off many times a day and the stream is big enough. The system notifies the user if the stream needs to be made bigger. If any of you have questions... post in the comments and I'll 'edit' the post to answer your questions. Hopefully I should finish coding the component quick so I can work on the object component (the hardest component of all).

Reply to Icon Based Menus

First of all, thanks for all you users who posted comments on www.OSNews.com it was very helpful and allows me to get this project done faster. First of all I did not know it would catch on that quickly... Icon based menus I have not seen in any current or old designs. This is not a toolbar or the OSX Dock. It slides and is not static. About the icons, you are all right... just blobing some icons wont get the job done but has to be thought about carefully just like any toolbar icon. Many icons have done well and are recognized by most users very quickly. I am a user perfectionist when it comes to small details. I can go through entire applications pinpointing problems. I once gave a company multiple emails of about 83 changes/fixed/ideas to implement and they did implement most of them. Just like the OS X dock has not been such a huge hit because of it's usability problems (the icons move without users doing so and thier order is not preserved) and my idea does not suffer the OS X dock problems because it only moves when the user moves them. This is why it can be spatially browsed. The user makes the changes... just like we remember where the light switch is, even if we do leave the room it's because it only changes when we change it directly. The icon based menus are not displayed at all times but rather are a popup when you tap a button (or the 'Go' button in the future Screens Environment). And you would not be browsing all your applications from a single swipe but rather it would be categorized and you would browse categories. It just makes it easier when the mouse/pen dont have to move all over the screen (i.e. Start menu) just to get an application/document running. This is why it has to be navigational browsing and not spatial in the way of 'windows' because thier is no point for location memory here but only position memory. While using them for actual File/Edit/View menus will have to see in the beta testing, the launching of applications, recent documents, settings and so on will be in the icon bar for sure because of the speed it allows you to get to a certain object once you know what you want (i.e. Applications->Games->Cards->Solitare) and if you dont know where the object is... no matter... just tap the edit box (dont ask for mockups... I cant do them at the moment while the code is not done) below the icons and write letters to show the results in the icon bar. Then you can just sway left/right to find the object you want and it will tell you where it found it. This method is a bit like alt+esc with alt+tab mixed together with some extras. Although I did not know about alt+esc (thanks for the tip) it has similar capabilities but with a quicker way to activate windows. When activing windows in the icon bar, you dont have to actually tap the window you want but rather only the thumbnail in the center gets it's window brought to the front. However if it leaves the center, the window returns to it's original stack order. Only a window which is tapped on (therefore hiding the icon bar) gets it's window to continue to be on top. Also the icons would not be applications specific but more general. I dont know about what to do for the application menus but for windows it would be thumbnails and for applications thier icons and for documents also thumbnails with a miniture application icon on the bottom right. When I mean icon based menus, I am including text in the idea. Without text you would all be right to say the design sucks (i.e. MacOS Dock). Text would be used to identify the icons but afterwards you could identify the icons much quicker. How many times do you actually read the word 'Back' when you are browsing back/forward using the IE toolbar buttons? Very rarely. The idea might sound corny without any mockups but I did not intend for it to be a 'wide-scale' article just a thought of mind. When I finish the layers component code, I will able to show you real animations of the thing working since the icon bar is one of the first UI parts I need to code. BTW: I just got married last week which is why I dont have much time on my hands ;)

Icon Based Menus

We have all used menu bars in every operating system. This has been the same since the original MacOS and has been copied for every other operating system without much differences apart from its location. MacOS has a single menu bar while windows has a menu bar for each window and the menu items themselves. Apart from that, nothing has changed. Menu items are still displayed horizontally and drop down vertically. Its still hard to get to sub menu items with a quick dash of the mouse without it disapearing. This has been one of the most unchanged parts of the desktop metaphore. It's time for a change. How? We have been using icons also from the first decade of GUIs, so why not apply the same for menus? But icons are big and menu items are small. Thats just the problem... menu items are too small. When menu items are stacked in a vertical manner, this makes it hard to select a menu item without missing it sometimes. If its a list where a mistake is not a problem, menu items do actions and tapping Print instead of Save makes you having to rush to the task bar to cancel the print job is not exactly user friendly. And dont think of seperators... this would just look worse. One of the problems with icons is because they take alot of screen space, it's hard to scroll them. This is what can be solved to make it usable. Imagine a film strip... it has loads of pictures seperated from each other. Place it aligned horizontally to the bottom of your display and imagine every window on your desktop has a thumbnail in the film strip. Slide the film strip left/right (moving the film strip but keeping it aligned) and see how the thumbnails move off-screen while others come on-screen. To do this inside the user interface, you would just drag the mouse/pen left and right to scroll the film strip. Now imagine that the end and beggining of the film are connected which means that scrolling all the way left will return you to the original set of thumbnails on-screen. Tap on a thumbnail would be just like tapping on a menu item and because menu names could fit in under each icon you get a big target to tap, an icon to identify with and text to attach to the icon to learn the icons identity. Because only a specific set of icons are displayed on-screen at any time, it looks less complex then 15 items on-screen even though with a single drag you can get to them all (left/right). How to do sub items? Easily, tapping on a menu icon which is a sub menu (it has an arrow next to the name of the menu icon) navigates to show only the icons of the sub menu. How to get back up? Tap the back button below the film strip. Wait a second... this sounds alot like folder/file browsing? what's the difference? The difference is the way you scroll allows you to bring folder/file browsing as a menu experience. We use so many icons per day why not memorize some more. You could still allow users to use existing menu design but allowing them to experience this by default. I dont see any major OS's doing this untill someone else has, so I am going to do so with Screens Environment to see how well users like it. Just to give you a major reason why I will be using it? For window clutter. I believe that this could be the key to stop window clutter since I will use 'spotlight' on the center icon of the strip. What does this mean? This means that if an icon reaches the center inside the spotlight, it's window representation is brought to the front of the display. If it leaves the spotlight it returns to it's existing location. This would allow with a single stroke to switch between 3-8 windows depending on the number of icons on-screen at a single moment. You could find the window you want by it's true representation instead of a title (windows), icon (MacOS) or shrinked representation (MacOS - Expose). It would feel just like flipping through pages in a book. We have done that for centuries, why not apply that in window searching. Many guidelines say dont include more than 6 items per menu. In todays requests of features that's nearly impossible and ends up in either too many items per menu or too few features. This has never been the case in icons and therefore has no problem in icon based menus since the number of menu items the user sees are less than 6 but the number he can get to is more. What developers/user designers can do is put the 6 icons that a user sees when he first activates the menu is the most common and leave more advanceed menu functionality in a scrollable reach. What about menus which items can be tapped and have sub menus? That should not be the case. Make the 'default' sub menu item centered when the user taps on the parent menu item. Remember though that text is still under each icon. Learning icons is harder than reading text so text must be there (not via tooltip) for such a design to be successful. And keyboard shortcuts also still exist because of the text. Also note that the icons must be simple enough to understand which is a tricky part but could probably be done if spent alot of try and testing. And this is NOT a toolbar. It's a film-strip. What's the difference? Toolbars are not scrollable while film-strips are. You can drag & drop icons to move them to your own order (every user and thier preferences). This design is not perfect and is just an idea without any working models behind it. I will post a more updated version when I can finish coding the components required for it. Of course this theory will have to prove itself in the beta testing of Screens Environment... but it's a thought worth thinking about (in my opinion).

Object Storage (Editorial)

You hear about storage systems alot in the news, reviews or even blogs lately... everyone either reviewing an existing system or designing thier own thoughts of what a storage system should be like. However alot of them are very fixed and have specific uses. Some are more dynamic while others are more static but easier to use. An object storage is more than storing or even finding information. It's about creating a single design which can encapsulate any information in the world and relate between them in any way needed. This could be anything from inheritence, backup, sharing, attachments etc. Here is part of my design: (will update as needed) Screens Environment is based on a powerful, flexible object model which allows representing any information in a connected and global interface. An object is an atomic unit of information which can represent anything from small name identifiers to huge structures. Each object is indexed for quick searching and has a handle to quickly relocate an object with minimal performance lag. This is done by using the unique identifier of the object in conjunction with the objects index. Objects alone are not useful; you need to specify relationships between them. Objects use links to specify relationships between other objects. Both the source and target of a link holds a copy of the link so that both objects understand the direction of the link. An object can have multiple links targeting it or outsourcing it. Each object holds a name and type identifier to identify the content or linking structure of the object. Each link has a name identifier to identify the type of the link. Together objects and links create flexible resourceful object storage. Each object holds a content stream of any size and unless messages override the read/write capabilities of the object, the stream is stored in the object storage itself. There are multiple types of links: 1. Container – A container link is the most common link since its very basic and does not do much but define a relationship between a parent object and a child object. 2. Reference – A reference link allows jumping between structures. 3. Class – A class link inherits any objects of the target which are linked via container links even multiple depths of links. Local or extended objects (non inherited objects) override inherited objects. 4. Extended – An extended link allows extending an object structure with another structure however unlike a class link an extended link overrides local objects. If multiple extended links clash, the last extended link prevails. Because many objects need interfaces to handle them, use method objects. Method objects are normal objects with the link name 'method' and are handled by the system. Because they are objects they can be extended or inherited via links. The name and type identifier of the object is the method identifiers. The method object holds a reference link (type 'code') to the object which handles the actual code. Method objects hold in their structure the parameters that can be sent with the method. If you try and send with non extended parameters they are 'cut' and not sent with the method. This stops 'secret' parameters from creeping into the system. Each parameter holds a name and type and can hold default values if the message did not include them. All parameters should be optional on sending and should be rejected if more information is needed. You don’t send a message to a method object but rather to the source of the method link. The message code finds the correct method handler (either through inheritance, extended or via containers) and finds the code of the method (via the 'code' link) and calls the code directly (native code). Non native code like java code is done by inheritance. You base the method on the compiler object (like the java object) and all methods are redirected to the compiler object. You can of course override this behavior by basing the object on a different code object which is useful when objects want to switch dynamically between dynamic codes. An object can exist without methods however its content is static (not dynamic by a method) and is stored in the object storage itself. To override this, just link to a method object with the read/write identifiers. When Screens Environment will try to read/write to the content of the object it checks if any method links exist (either via inheritance, extended or containers) and if not uses system code. While container and reference links provide a tree structure (parent/child) , the class and extended links provide a way to merge multiple objects together without having to know of the merge (however can be found out if needed). Think of container and reference links as down/up links while class and extended links as left/right links which together allow the full flexibility that the object storage needs. Applications normally create class objects so that methods are not required for each object instance but rather derive it from the class object. The reason a class is an object is because it increases the flexibility of the storage.

Spatial vs Navigation User Interface (Editorial)

Many operating systems are choosing if they want their file organization as spatial or as navigational in design for users... Spatial design builds around the fact that it's easier for users to locate objects by their location, size, view, colors and so on that don't change without the users explicit actions. Navigational design builds around the fact that instead of browsing every object in it's own window, you browse from a single location using functionality like history, bookmarks and path jumping to easily go through deep levels of objects. The problem is that choosing either one has it's limitations. While spatial might be superior for small simple users who don't have much objects it's a pain for using on web-sites or with users who have a vast amount of information to organize. Their is always a maximum a mind can remember and asking the user to remember the location of 1,000 collections is not the way to go. Asking him to organize in to fewer collections just makes it harder to scroll to object 100 in the collection. While navigational browsing might not remember anything you tell it, it eases large browsing requirements. Not that spatial is not an excellent design, but it's more useful for objects you use frequently since their position & size can jump immediately to mind. Screens Environment will merge between the two. Every object can be browsed spatially, navigational or even both. Just like a file system where you can have shortcuts to files, Screens Environment has shadows of windows. A window shadow receives all the information from the original window but can override for the shadow properties like position, size and view. Changing the original window does affect the shadow (apart from overridden properties) but a change on the shadow does not affect the original. This allows to navigate through every spatial object with a single window view. The browser window (navigational) allows to shadow another object and override it's position, size and view to the properties of the browser window without hurting your existing spatial settings. Users have been using alias/shortcuts for years, why not apply this for the desktop. You can open any object in spatial or navigational view (if you open an object in navigational view from a spatial window, a browser window is displayed) without hurting the spatial design. Even web-sites which normally you use navigational methods you can set a specific web-site to be spatial (usefull for thumbnail web-sites) where every page has it's own window representation. You can of course remove spatial properties from objects if you wont be using the objects to much soon or you can even set an expire date like a year away since will you actually remember that an editorial was in the top left a year later... I have trouble remembering who I was chatting to yesterday. Of course actions are more than words... but this gives my general view on the matter.

Key to Action mapping

At the beggining it was simple... all PalmOS devices had the same button layout. Then came the jog-dial from Sony, the direction pad from PalmOS and then the Zodiac extra buttons. Keys are good things... they provide extra uses for the device from starting more applications with a single tap to playing games with more functionality, different key layout for different devices are going to change even more. Screens Environment solves this from the core. Instead of applications checking if 'hardbutton1' or 'hardbutton2' was pressed, they check if 'left' or 'right' event was recieved. So instead of applications checking for keys, they check for actions. You can even receive multiple actions at once like fire+left or jump+fire. While applications can still deal with buttons if they need to, it's not recommended. By having Screens Environment do this for you, it allows every application written for Screens Environment to able to be hardware-button independent. In the system, each action is attached to a key however you can specify a 'global' profile or even for each application (like games) in one single window without having to move between each application properties and modifying the key mapping. These will allow hardware designers to able to design the device for thier users and not for the operating system.

Welcome

This is my first blog posting... anywhere... wish me luck I am still having trouble with the object storage in it's design of link relationships. If anyone can help please join me on MSN Messenger at zhamilton1@yahoo.co.uk For first time users... while I cannot go through the entire feature set of this environment the key parts are as follows: 1. The environment is still in development... it does not exist yet... nor is thier a demo/screenshots 2. The release will cost 15$ but it will come with a demo version available 3. While the first releases wont support external applications, you will able to use the enviroment for it's launcher/organization features. 4. Screens environment has a window/layer components to allow users to have a desktop like enviroment right on thier PalmOS devices. 5. Screens environment works on any device from PalmOS 3.0 to PalmOS Cobalt/Garnet 6. If you want a free release or want to speed up development, chat with me as much as you can on MSN Messenger. Chat is what moves this project more than anything. Blog specific ideas can be posted in the comments section. Enjoy