Re: extra menus on panel

[Dion Detterer <diond healey com au>]

Tom Vogt wrote:
> >
> > MISC | TASK1 | TASK2 | ... | TASKn | ... (clock)
> >
> > for example, makes the first decision easier as to "how do I start my
> > given task?" than does
> >
> > MISC | APPS | GAMES | TASK1 | TASK2 | ... | TASKn | ... (clock)
> >
> > Sure, it makes it easier to do general tasks, but at the expense of
> > slowing common tasks.  It's far easier for the user to build upon the
> > foundations of the default than it is to modify the default first.
> 
> you have a point there. I'm not yet agreeing in full, but definitly a point.
> 
> so how about the compromise solution of creating one "system" and one "user"
> folder as default? it would kind of split things according to task as well
> because system administration is for the most parts a different task than
> user applications.

I agree here, for sure, as long as the lines between sysadmin and user
apps are well defined.  Help should probably belong in the sys folder,
for example, since it is help on the topic of the system.  What about
gmc?

However, I think we should take a step back first, and look at GNOME as
a whole.  Do you agree that the first step to building a good GUI is to
flesh out an object heirachy so that we can create a system where
objects behave in a consistent manner?

One thing I've been thinking of (and I know how whacked-out this will
sound) is that containers hold container-space, and container-space
holds objects.  When you right-click the icon of a folder and select
'delete', you operate on the folder, whereas when you right-click inside
a folder which is open infront of you and select 'delete' (which should
be greyed), nothing should happen.  You are operating on the empty space
*inside* the folder, and not the folder itself, and no-one expects to be
able to delete thin-air, nor do they expect it to delete the folder
itself.

Where I'm going with this is that both the panel and the desktop are
subclasses of "container-space" without respective containers (unless
you count the hidden folder in which the desktop resides).

BTW, when I talk about an "object heirachy" I mean a "class heirachy"
from which to create instances of objects.  I'm not referring to the
actual structure of the system, just the structure of the concepts.

-Dion.