2.0 Desktop/Panel User Object Model
Currently no personas have been defined supporting ongoing GNOME development. It is safe to assume that the current tensions over design and features in GNOME is due to the fact that different people have different assumptions on who the target end user is. This initial document will attempt to be agnostic of the target user. HOWEVER, further development of this document will have to assume a one or more classes of end users.
This proposal assumes that the GNOME desktop interfaces can be model as a set of user level objects. These objects will have relationships to other sets of objects. These objects will have properties or attributes, and support actions or tasks which enable the user to change the object's properties or attributes.
If one examines the base set of objects (like windows, applications, files, workspaces, etc.) that are currently presented to the user in GNOME and other desktops it seems the basic model presented to users is that on objects containing other objects, i.e.:
Workspaces contain windows which contain applications which contain files...
This type of model does not preclude task or browser type models, they are just a different way of presenting the same data.
I started looking at the whole desktop last year, but because of the type of work that was going on for G2.0 it didn't seem much point in pushing the ideas. Since Mark is now looking at the panel again, I thought I'd try again.
The following diagram attempts to show the current set of objects and relationships which the user has to know about in order to effectively interact with the basic GNOME desktop.
If you don't understand the picture, that's OK, but the model presented is what GNOME 2.2 users have to understand in order to configure the basic GNOME desktop.
This isn't intended for the 2.4 time frame, just as a discussion point. If something like the following was agreed as a reasonable future direction then we could move to it in stages (and IIRC Mark is planning on fixing some of the current problems with the panel in the 2.4 time frame).
This picture gets more interesting if one starts thinking of sticky objects, i.e. those which can existing in one or more workspaces.
This picture also implies that if you drag a folder into the panel it becomes a menu and vice versa (we may not want to do this). Calum also proposed an alternative.
Anyway this is the easy bit. Things get interesting when you start thinking about what the thing/icon actually represents, and the relationships of different things/icons.
Assuming we agree to something along the lines of the above. The next, more interesting, phase would be to extend the model to support a set of the most common desktop tasks. For example, document creation, information browsing, desktop configuration and communication.
This is basically one of the things Seth was getting at in his 'on crack' talk at last years Guadec. Are these objects a real instantiation of that object, or are they just links to some executable?. I think a lot of people are familiar with M$ Windows behavior of removing shortcuts to programs on their desktop and expecting the complete application to be removed from their system. On my win2k box there is even a nice dialog now that tells you this won't happen.
Hmm, so if I delete netscape shortcut nothing much happens, but if I other icons then there is data removal. How does the user know which is which?
The more i think about this I think we should just ditch the file system and stick everything in a big nice OO database :).