White Paper
I. Executive Summary
II. Introduction: Live objects, a look back
III. DesktopX design
IV. DesktopX in use
V. Where we are now…
VI. Conclusions
Executive Summary
DesktopX is a object frame work that provides Windows users with the ability to have “living” objects on their desktop. A living object is an element on your desktop that can receive as well as send messages to other objects, other programs, and other components of the operating system.
Its goal is to make it possible for users to create very customized desktop user interfaces. DesktopX is part of Object Desktop whose overall goal is make the OS flexible enough to be tailored to the user’s particular needs. Windows, by default, is a fairly one-size fits all proposition. In reality, to maximize productivity the desktop shell should be designed to meet the rather specific needs of a given company or individual.
The net result is that companies and individuals will be able to create desktop “themes” that transform the Windows desktop to their exact needs. These themes are made up of DesktopX objects which can range from being simple pictures to being light weight applications in their own right. These objects can easily be traded back and forth (the same with themes) with other users with minimal effort.
For instance, an individual’s DesktopX theme might be something similar to a Litestep theme in which their favorite programs and commonly used tasks are placed in a sci-fi or fantasy setting. Each object could animate itself when the mouse is over it, it could play sound depending on the event, etc. But because it’s broken into parts, a DesktopX theme, unlike Litestep, is resolution independent. Which means that there is no such thing as a “this theme is a 800x600 theme”.
A corporation might use DesktopX to monitor factory resources and keep a department team in easy communication as well as lower training costs by having their desktop display only the items necessary for their efforts. One DesktopX object might be displaying the temperature on a blast furnace and if the reading becomes abnormal, it my vocalize “Blast furnace temperature alert!” An object containing the list of team members and their status might be up in the top right. By clicking on a member name, it might interact with ICQ or some other instant messaging program to let the user send them a message. Meanwhile, the network drive object might have a small pie chart on it displaying how much drive space is currently available on it.
In both examples, all of the things are possible by writing programs. But the point of DesktopX is that these tasks are infinitely simpler to do as DesktopX objects. Instead a day or two writing up a nice looking drive space monitoring program, it could be done in a manner of minutes as a DesktopX object.
Creating a DesktopX object need not involve any programming at all. On the other hand, using XML or Windows Scripting Host, objects can be created, sent messages, to, and interacted with by seasoned developers.
Thus in both examples, the user has been able to create their own desktop. No longer do they have to work around having a “My computer object” on the top left and a Start bar on the bottom or elsewhere no the screen to get their work done.
Live objects: a look back…
The idea of moving the desktop from being a set of static icons to one of living objects is not a new idea. A long time ago (1992-1996) Apple and IBM teamed up on a project called Pink and on a technology called OpenDoc.
The goal of OpenDoc was to break monolithic applications into their component “parts”. These OpenDoc parts could then be put together by the user in whatever form was needed which in turn saved memory in cost since the user only had the pieces they actually needed loaded. It also was meant to create a new type of software industry – lots of smaller developers creating and selling OpenDoc parts to corporations and end users alike. Other companies might license these parts and put together their own solutions with tbem.
Company A might put together a spread sheet part. Company B a spread sheet part. Company C a graphics editing part and so on.
A user running say OpenDoc word processor (which was a collection of OpenDoc parts itself such as a WYSWYG editor, equation editing part, etc.) embedded a picture, they could right-click on the picture and perform a number of actions on it that would be determined by what parts were installed on the system. Thus one user might be able to fax that picture using an installed Fax part or be able to edit it by loading up a graphics program. The key is that only the part needed was loaded.
This didn’t sit well with the world’s leading provider of PC monolithic software at the time, Microsoft. They wanted to go the opposite way – instead of people buying pieces of an application, Microsoft envisioned a world that bought suites of applications. Namely, their suites of applications. The last thing they wanted to see were hundreds of nimble competitors each specializing on what they did best and thus potentially creating a Word Processor or a Spreadsheet that was far superior than to what Microsoft alone could create. In response, Microsoft put out a number of announcements of their own initiative. OLE 2.0 and “Cairo” to counter OpenDoc and Taligent/Workplace OS.
OLE sounded very similar to OpenDoc on the surface. A user in MS Word with picture embedded via OLE 2.0 might then double click on the picture and suddenly the Photoshop menu and toolbar would pop up as if integrated as part of Word. It makes a pretty terrific demo. Unfortunately, what actually occurs is that all of Photoshop is loaded (printing definitions, pre-press features, etc.) instead of just the parts needed because Photoshop is, like Word, a monolithic application. But it was good enough because Microsoft has the advantage in quantity of applications and with enough RAM and CPU, OLE could do the job. Whereas IBM was stuck having to demonstrate OpenDoc parts on its own with very little available to show it off.
But the OpenDoc team was pretty sharp and had a great idea. While they couldn’t do it in time for OS/2 Warp 4 (1996), the follow-on, OS/2 Warp 5 could be made up entirely of OpenDoc parts. This would serve as the basis for creating a revolution in software development. An entire desktop of living objects that would demonstrate to anyone that living objects on the desktop as opposed to icons representing objects (OS/2’s WPS is object oriented already but uses icons to represent those objects).
In an early demonstration, the power of an OpenDoc based desktop was shown. First off, the sizes of each object was arbitrary. No more 32x32 or 40x40 icon requirements. The user could set the size of each object if they wanted (they could all be the same size if the user wanted but they didn’t have to be). A network printer object might be down in the bottom right hand corner showing its status in real time. The drives objects could show how much disk was free just by looking at them. A developer could easily create new objects that inherited these objects and add new methods to them that displayed their data in other ways or use them as part of their application. It was going to be incredible.
Unfortunately, IBM as a whole decided that OS/2 was no longer meant to be a desktop client and the project was scrapped. Later on, IBM even discontinued development and support of SOM, the technology underneath OpenDoc.
Microsoft, having successfully wiped out the competition, quietly murmured that its various pronouncements on Cairo and OFS (Object File System) were misunderstood and were merely code-words for things like NT 4 (later NT 5, etc.) or that they were actually going to be delivered as a set of technologies (the story tended to change depending on the journalist they were speaking to was). But Microsoft had won out and for the next 4 years the desktop metaphor most people used (Windows) was remarkably similar to what was available on the Macintosh in 1984.
I’m not purposely trying to be critical of Microsoft here, but it is hard to find any justification in what they did as it set back the evolution in user interface design by years. Most consumers have no idea how much harm they’ve suffered as a result of unreported battles like OpenDoc vs. OLE, Cairo vs. Taligent.
Now fast forward to 1998. Stardock had been working on Object Desktop for Windows for some time already. Object Desktop being a product that is ultimately a set of components designed to give users greater flexibility on their PCs. “Make Windows work the way you want it to” was the tagline.
And nearly each week, a Linux or Windows user would write in and say “Hey Stardock, can you port the Workplace shell to Windows/Linux?” Users really liked IBM OS/2’s Workplace shell. But out view was, how could we port that after having seen what an OpenDoc layer on the shell would have done?
Unfortunately, we had our hands full at the time. Stardock lives and dies on having extremely good developers. And all of them were occupied on various Object Desktop components already. It wasn’t until 1999 that we found a project leader for this endeavor who had the experience, skill and vision to make DesktopX happen in a reasonable amount of time. The person we found to lead the project is named Alberto Riccio whose previous worked included the popular Verona Desktop Enhancer (VDE).
Meanwhile, we watched as people created alternative shells for Windows that were quite impressive – Litestep, Graphite, Reveal, Evolution and what was happening there was very impressive. But we felt that replacing the shell of Windows was too much to ask users for and not necessarily very productive for mainstream users (contrary to the believe of some, Explorer isn’t that bloated).
So we set out to create DesktopX which would carry some of the principles of OpenDoc but limit it specifically to the desktop (if Apple and IBM combined couldn’t get people to use OpenDoc, what chance do we have?). Unlike OpenDoc, we would make DesktopX appeal to non-programmers. A non programmer could use it, modify it and make their own shells. We would focus on trying to work with the “skinning” community that had helped make WindowBlinds and Object Desktop as a whole so successful. Most of them weren’t programmers and thus we didn’t want to see them having to modify some text configuration file or play with some script just to make a theme. It’s all point and click in DesktopX.
We also wanted it to work at any resolution, not just at specific resolutions. I run my desktop at 1600x1200. Therefore I can’t realistically use the themes from these other alternative shells (even if I was willing to overlook the fact that they’re static bitmaps with hotspots primarily). I wanted to be able to create a cool theme in minutes if I needed to.
And lastly, we wanted to be able to make a theme be able to be used by someone else without a lot of tweaking. When you see a screenshot of a some replacement shell theme, you typically have to monkey with it to get the things it “links” to work. The screenshot before I download one of those themes might show MS Word or Winamp but whenver I actually go to use it, I have to reconnect all my links and find them on my system. That can be a pain. With DesktopX, most of the common programs will automatically find their link instantly. If I click on my Winamp object in DesktopX, it’s going to find it even if I upload that Winamp object to my machine at work in which Winamp is installed in a totally different location.
And so here we are, with DesktopX. Much of what is discussed here will not be implemented until much later on (though the basics mentioned above are in now). This document represents our overall vision for DesktopX and how we hope to make it work by release.
DesktopX: The Design
DesktopX implements its objects as subclass of child window. Of course, this is an extreme over simplification but by doing so, DesktopX can easily send and receive messages to each other and to and from the OS itself. Stardock has taken the approach that it is not likely to get third parties to readily jump onto a proprietary messaging model so instead opts for what is already available in Windows itself. This means that any other program running on a user’s system could send a message to a DesktopX object by sending the DesktopX process a message with a certain set of pre-defined parameters.
Figure 1Basic DesktopX structure
One of the strengths of DesktopX is its design simplicity. Each object has its own unique ID which can also be set by the user so that they always know that that object will have that ID.
Figure 2 A DesktopX object is meant to feel as much like as part of the user's native shell as possible.
Moreover, a DesktopX object can either inherit from an existing shell class (such as WP_MyComputer) or have a custom class in which it can point to a VBS script to run when it is launched or run at a given time or attach a process to the object that sends messages back and forth between the OS and the object.
For example, let’s say you are a stock trader and you want to set up your desktop specifically to reflect the status of your various stocks that you have. You could create an object for each stock or one larger object that displays them all. When the object is initiated, it can be configured to launch a program or script that checks those stocks and reports sends messages back to DesktopX. Now, the question might be, why not just write a program that does this and bypass DesktopX entirely? The reason is that creating a program that just queries data is one thing. Creating one that queries and has to display that data in a logical way is quite a bit more effort. The point here is that with DesktopX, you can break these tasks into their component parts. DesktopX makes it very easy to display things in a logical visual way as well as provide sounds, animation, and interact with other programs. This saves the developer a lot of effort.
To give you an idea of what this can do for users. Let’s say your favorite MP3 player is WinAmp. It’s got a terrific engine and is very flexible. But let’s say you wanted to have your own custom skin for it that WinAmp doesn’t allow (like something totally off the wall). You could create what we call a compound object with DesktopX. You would simply create your own interface to MP3 and have the object send messages to Winamp which is loaded in the background. The only extra memory used is the memory for displaying the graphics (which would be used by a Winamp skin anyway). Ultimately, with some effort nearly any program with limited input could have a custom “skin” that is merely a compound DesktopX object. And there is no “skin format” with DesktopX, it’s purely a matter of putting together the DesktopX objects the way you want, selecting them and grouping them together (just like you would treat objects in Corel Draw).
Figure 3 Thomas Schwemlein's excellent KJFOL skin but imagine using it with Winamp or whatever other media player you want? I.e. program independent skins.
This is, of course, merely meant as an example of what one could do. This isn’t what DesktopX was designed for specifically. But these are the kinds of things that can be done simply by providing an object framework to the Windows interface. The amount of memory and disk space saved by having these user interface tasks broken into objects under the same umbrella can be enormous.
There are limitations. Don’t come away from this document thinking that someone could use DesktopX to create a word processor or a drawing package. There is no user input currently in the design of DesktopX. That is, you can’t type into a DesktopX object. That isn’t what DesktopX is about. Its design is to transform your desktop user interface to suit your particular needs.
Whatever common tasks and data and programs you regularly use can be integrated into your own theme. That is what DesktopX can accomplish for you.
DesktopX in action.
So how exactly does one use DesktopX? Let’s create a really simple theme together. Bear in mind that at this early stage, much needs to be done and some things mentioned here will not be available in the first public betas. Much of it will be but much will not.
Let’s say you want to do something really simple like create a nice big MS Word object.
Figure 4 Step 1: Create a generic object
Figure 5 Step 2: Go to the properties of the generic object by right clicking on it.
Figure 6 Choose Program shortcut. Then hit Configure. Type in .DOC since you know MS Word is associated with .DOC. That way on any system it will launch MS Word or whatever is associated with that.
Figure 7 On relationship you can set up how you want it to be on the desktop. One suggestion is to have it be sensitive to resolution and have it rescale under adjust position.
Figure 8 Under messages let's use just a single image. We could choose to have it be animated all the time.
Figure 9 I browsed and found the word bitmap I whipped up earlier.
Figure 10 Because users can trade individual objects, we have put in some effort to make sure each and every object not only can have a unique ID but that credit to the author is actually part of the object.
Figure 11 Voila we're done. But don't get too excited, this example just basically had us create a glorified icon
The bitmap I loaded in uses 255,0,255 RGB value as the color (a pinkish color which is standard in skinning) to designate transparent areas. If it was animated, it would simply be several images together horizontally.
At the end of our example, we’ve made what basically amounts to an arbitrarily sized icon. Of course, it has some advantages over an icon in that you can trade it with someone and it’ll launch MS Word regardless of its position. And in fact, DesktopX can use icons (.ico files) for its images. Why bother? Because even if you just used DesktopX to replace your regular explorer desktop with an identical DesktopX desktop your “icons” would at least scale correctly and you could easily distribute your desktop around without worrying whether you have Photoshop installed to your C:\program files directory or your d:\applications directory on your other machine.
And you can also mix and match DesktopX and Explorer together. That is, have some of your desktop elements be icons and others be DesktopX objects depending on your particular need. It just depends on the user’s particular ambitions on how much they want to do to modify their desktop. Some people might only have one DesktopX object sitting on top of Explorer that acts as a super agent for all their system resources and such. Another user might completely do away with explorer, use Litestep and use DesktopX as its theming engine to create radically different user environments for people.
Example 2: A bit more complex…
There are built in classes for everything from the recycle bin to the start button but what if you want to create your own class and not inherit from one of the built in ones?
In that case, instead of choosing something like a program-short cut, you choose the “custom” class. Now you’re creating your own. To do this, you will have to know some programming since now you’re moving beyond what DesktopX has built in (we’ll keep adding new classes as people request them of course). Of course, most people will usually just download their objects that others have created just as most people use skins made by others. But if you’re a skin/object maker, here’s what you do next…
Now, when you hit the configure button, you will have to point it to a DLL, EXE, .VBS, .JS or some other type and tell it how often to run (either every so often or when the object is first constructed). When you hit OK, the object may bring a pop up asking you to enter in some parameters for it. Example, you are making an object that displays how much disk space is remaining and you’ve cranked out a little EXE that monitors drive space on a specified drive. The EXE has no config file so it knows it has no parameters so it asks you to enter in the drive letter.
Now when you go to the messages tab you will have to define a number of messages that this object gets that aren’t normally available. Since you must have written the EXE in this example (or VB script or whatever) you must know what the messages being sent are so you define those messages here. For instance, if you send the message “msg_diskspace_low” (i.e. in pseudo code: sendmsg(hwnd_desktopX, WM_SENDDXMESSAGE,ulObjectID, “msg_diskspace_low”); ) then you need to define what it will do when it receives that message. That could mean an animation, sound a warning you’ve recorded, send a message elsewhere, display a graphic, display some text, play an animation, etc.
When you’re all done, you will have a cool object that you can right click and export. DesktopX will include all the messages you’ve set up, the linked EXE,JS, or VBS or whatever, and graphics, sounds, and any other responses. When someone else uses it, it will simply ask them what drive letter to monitor and that will be that.
Now if you really wanted to get fancy, you could really go all out and create a custom class that handles its own drawing but does it on the particular DesktopX object. In that way, DesktopX merely controls the object’s position on the screen and the program handles everything else. At some point, of course, it almost makes more sense to write a stand alone program but using this mechanism, the user can keep their functionality as part of a theme that others can use and trade instead of having to run around downloading dozens of little programs.
How powerful a DesktopX object is dependent on the person creating it.
Some casual user examples:
The Clean Desktop example:
I would say that most casual users who try out DesktopX are probably going to want something modest at first. For instance, they may want their desktop to look pretty much what Explorer makes it look like by default but without all the clutter from programs throwing junk on the desktop.
How can DesktopX help this? First, have DesktopX hide your desktop icons, then replace the ones you want with DesktopX class objects (for My Computer, Recycle bin, IE, Network Neighborhood, etc.). Then add an additional object called “Desktop” of the desktop class. Then when you configure it, tell it to display the contents as a menu and have it set to activate on a single click. Now when you click on this object, it will display as a pop up menu all the junk that would normally be on your desktop. A clean desktop with minimal effort.
The NeXTStep example:
In combination with Winstep’s excellent NeXTStart program and WindowBlinds (another Object Desktop component), DesktopX can come quite close to bringing back some of the power of NeXTStep.
The Trekie example:
Almost every UI customization program of any kind ends up with a Trek style “theme” or “skin”.
Figure 12 A Trek-style theme.
Take a close look at this particular theme. What makes this particularly interesting is that the integrity of the theme is kept even at strange resolutions. For instance, even at 1600x1200 the theme works (i.e. it is not smushed into the top left corner of the screen). The system tray has been moved up slightly from where one would expect and the task list moved to the top of the screen. The user has created a custom container object in the middle that displays his favorite photos (the photo object on the left side is a “pop up container” class object which launched the container).
Figure 13 Since I want my left side to be consistent, I simply clone my Website label object and then they’re identical.
Now, to create that container, first I created the container object then the objects in the container and then grouped them together as shown in this screenshot during the making of the Trek theme:
Figure 14 Once I was ready to create my group, I selected the items I wanted in the group and then called it my website group.
From there is was just a matter of telling the websites object on the left to be of container launching class and tell it to launch the group “websites”.
Creating the Trek theme took a good solid week of effort. On the other hand, you could imagine someone making an entire program that simply does just this type of interface. How many months would that have taken to program and how flexible would it be? For instance, if lots of people begin using this Trek theme, we could create additional containers, group them up and create an object package of them to exchange on skinz.org or some other website (like desktopx.net). This is probably one of DesktopX’s biggest advantages over monolithic theme systems and it gets back to the OpenDoc root of inspiration – a Theme can be a collaborative effort through users creating individual objects (parts) of it and putting it together.
Other Examples: Coming soon…
Where we are now…
We’re about 2 weeks away from having DesktopX available on The Object Desktop Network (www.objectdesktop.net). A public beta program will be available either in late summer or early Fall of 2000. We don’t expect to finish DesktopX until next year.
So what isn’t implemented yet? Lots. Right now we’re focusing on things that one might quickly consider. For instance, we don’t want to see situations where users download a “theme” and then have to spend an hour tweaking it for their system. So Alberto’s team is putting time into having a theme migrate as quickly and painlessly as possible. The resolution independent nature of objects is working quite well.
The first Object Desktop alpha (0.1) won’t have custom classes or custom message handling in yet but those will be implemented before the public version. With so many different versions of Windows to handle, compatibility testing will be taking up quite a bit of our time. For instance, the WP_RecycleBin class does not function on Windows NT or Windows 95 (we don’t plan to support Windows 95).
A lot of time has been put into the Z-order of objects (what is on top of what). When you’re putting these objects together, Z-order is important and a lot of time has been spent to make this easy for users.
Obviously a lot of time is being spent on creating themes. With the rapid development pace, a theme created today is almost outdated by tomorrow. But we have actually used DesktopX in a somewhat formal environment. Once a month Stardock has a “Game Day” in which we get together and play games (usually Half-life Counterstrike and Total Annihilation) on a weekend. Here is a DesktopX theme for Counterstrike:
Figure 15 Counterstrike DesktopX theme Look closely. The shutdown object is actually slightly on top of the Control Center. Regular explorer short cuts and other items can be mixed and matched as well (see the white paper short cut).
Over the coming weeks we’ll talk to more and more skin authors and theme authors from alternative shells to see what sorts of things they’d like to see put in. The feature set of DesktopX isn’t set in stone. Plug-ins for Control Center and WindowBlinds are likely to become compatible with DesktopX in order for us to provide a generic Object Desktop plug-in class.
Conclusions
If you’ve managed to stick through this document, hopefully you have a better understanding of what DesktopX can do for you. Whether your need for customization of the desktop is for a corporate kiosk, an IS department, or personal enjoyment, DesktopX is designed to fulfill that role.
Over the coming months, it will be exciting to see what sorts of things users are able to create. What types of incredible objects users make. DesktopX merely provides the building blocks, it will be up to DesktopX users to really show what a next generation desktop will be like.
Contacts:
Product Manager:
Brad Wardell
Project Leader:
Alberto Riccio
Websites:
Stardock Corporation
Stardock.net
Object Desktop
DesktopX (which is a component of Object Desktop)
http://www.stardock.com/products/desktopx
To get DesktopX you’ll want to get Object Desktop. There are order links on the Object Desktop home page.