Update

So I finished coding the CoreObject class and its working wonderfully. Finally some code I realy like which is simple and small. It took me a few hours to write which shows that designing code is the hard part, not writing the code. I am coding 'Saturn' which is a Shell explorer (without a programmer API and without virtual object support) that will show a few of my ideas like the Icon bar. By not releasing an API, it takes off the pressure of having legacy applications when I want to code 'Safire' (which is the full Screens experience). Saturn will allow you to view databases and records as files and folders, so you can see memos as actual files in a folder which should allow a more interesting ability to handle records of different types. It would allow you to able to view your records without your application. So bitmaps are viewable, text is opened with a notepad like application and forms can be created using an IDE and so on (dont know about the last idea...). This will show of the layering system which allows for movable windows with no flickering and the module based behaviour. Stay tuned (yes... this is another lets try again post...)

Update

Oh well, NDS wont allow me to post screenshots at the moment... I guess I'll have to wait a while to show you what I have been working on. If any of you were at the IBC 2005 at Amsterdam, tell me if you saw the mobile application working on the iMate or Dell Axim. I have been doing alot of code design and writing lately, messing around with the object store. Hopefully I can get the object store finally working in code. Its design is smaller and simpler than ever but also faster. I learnt alot being around NDS Employees including alot of C++ code experience. Writing the layer design into the NDS MobileEPG was very good for Screens, since it allowed me to prove to myself that I am able to do this Screens Environment project. I also learnt the problems with my design, so I wont have those issues in Screens Environment. I guess my blog is kind of an island at the moment, however, maybe in the close future, users will flock to my blog and read this post ;) I am currently coding the Item class which is the Object class without the method capabilities. I hope to finish the Item class by the end of this week. The hardest part of Screens Environment is to agree on things. Any time I have multiple paths to choose, I start scratching my head of where to go. I used to talk alot via MSN Messanger however once users lost interest, that sort of lost its use. Oh well... Alone again...

Single Object Store

I have just been watching for over 2 hours the PDC 05 Event from the Microsoft Web Site... cool stuff this Avalon... um... Windows Presentation Foundation. Those 3D effects are realy smooth ;) But then they start with Data... This LINQ stuff might sound good but its just adding another headache for developers, not removing it. Developers have to deal with so many API's and although they are trying to add yet another single API, they are just adding another beast to the collection. There are so many data sources we deal with... from tables to file systems to the registry to file internal data and so on. What is needed is not a WinFS single store but rather an API to merge all these sources into a single design API. I dont care about that registry folders are called Keys and that registry files are called Values. Just give me Folders and Files instead of including new concepts. Here is the rant: If I write an application to use the registry but then I am told to use an INI file (so that the settings can be shared on a server). Think of the amount of not only API but logic that needs to be changed to make this work. Although they both are using the key and value design (just INI files have only one key depth), I still need to use a different API. Dont think this rant is just at windows, PalmOS does the same thing! Instead of having a single database API, I have three API's to handle! The data manager, The resource manager and the VFS manager. If I want my application to read documents on the card instead of from the internal drive, I need to recode all my calls to the data manager when they have exactly the same ideas. This is one of the reasons I have been working so hard on the Object Storage. Its not about adding meta-data but about abstracting the meta-data we already have. I want a single API with minimal changes works for both the memory manager, VFS Card, Databases, Files, Serial port, Bluetooth and the list goes on and on. Instead of calling a function like: SetDeviceID, I want to browse the IDs and select the one I want using a hierechy design. Give me Folders and Files everywhere! I want a device to be a folder, I want a document to be a folder holding the documents elements. I want a serial port to be a folder which any data I put in is sent over through the port. I want to create 5 files with data and send them all off together easily without fiddling with data buffers. This frustration is what is driving me forward with the Object Storage. I want a single abstract design which will spare me the details and allow me to do things in a 'virtual' way.

Screens is still alive (or at least its concept is)

Hi Everyone, or anyone who checks this blog for life signals, My boss is at the IBC at the moment, so I am stuck at NDS a bit bored untill he comes back and gives me lots of work to do. Untill then, I have some spare time to actually code Screens at home. I just upgraded my RAM to 512 MB which should realy help when coding in PODS because before hand I only had 256 MB and PODS was so slow. I used to use Falch.net but they want down under. So finally it will be a joy writing lines of code without my CPU having to catch up (PODS uses Java which is why it has a hefty RAM requirement). I have been doing alot of research as usual and I still (I dont know if anyone has) haven't solved the problem of the store island which is how to import/export additional meta-data that cannot be stored with the original file. Untill I solve this, I wont be able to make the object storage. So instead, I'll spend time on trying to build a design without the object storage. This means that you wont able to attach contacts to mp3 files. I realy wanted this feature... oh well... I might find a work-around or maybe with a bit of luck solve it. I have noticed quite a lack of products in the area... iSpin seems to lack updates and WinLauncher is looking a bit old as well... is there anyone working on some secret release or is just no one interested in these kind of products anymore. PalmOS seems a bit dull lately apart from selling companies back and forth and new devices here and there. About the only interesting thing I receive from the PalmOS world is Jeff Kirvin ;) If there isn't an object storage which has been the number 1 reason for the lack of Screens release, is there anything you would want instead? Please post here or email me a list of your wannabe features. I am going to start coding next week again after a break of a few months (of coding that is). There isn't any point explaining why its so hard to create an object storage (just read WinFS's problems and I share them as well) but maybe an OS without an object storage is not that bad after all.