Re: Panel Menu

[Seth Nickell <snickell stanford edu>]

> Looking at the new menu bar applet, it seems all the 
> necessary ingredients to replace the panel menu now exist. 

Yes... Initially there were a number of usability issues with the
applet, but Chris and I have fixed it up so its quite usable.
 
> The panel menu can be replaced with an edge panel with a
> menu bar applet on the left (for applications and actions)
> and a clock applet and another menu bar applet on the right
> (for windows).

Nils & I have talked about dropping the window menu on the right, and
putting a workspace switcher there instead. For example...

http://www242.pair.com/nilsp/nils/G2-desktop/default-panel-layout3.html

>   - The application menu bar has a different right click
>     behaviour than the application menu on the menu panel.
>     Ideally the former should support this right-click.
>     behavior.

Yes.

>   - Unlike the clock on the menu panel, the clock applet
>     does not link to a gnome calendar.  

This needs to be fixed anyway. I'd really like the clock applet to be
the same widget as the menu panel clock anyway (in general I prefer the
menu panel clock to the regular clock).
  
>   - The windows menu bar only shows windows in the current
>     workspace.

Easy enough to change, though I think menu bar window menu has more
desirable behavior (i.e. displaying current workspace windows only is
better, imo). It should probably follow window bar settings in this
respect (though of course there's funny issues with that like having
multiple window bars, etc).

> From a documentation point of view, the menu panel and its
> initial contents present a problem - none of the latter even
> have a proper name by which they can be described.  Their
> behaviors are always an exception to the general behaviors
> of panels and applets.  If they are difficult to document,
> they must equally be a usability issue.

Well... not necessarily. People don't have a terrible time dealing with
certain sorts of exceptional objects as long as they have a pattern they
fit into (in this case having key elements of the screen be static is
actually a usability advantage). 

So perhaps not so good for documentation... one of the usability things
I would prefer to have done before we switched to the menu bar is to
provide a mechanism for locking it down, that is removing the ability to
move or remove the applet. A "menu panel" would still be a special thing
in the menus, though technically it would just be a regular panel with a
menu bar locked into the upper left corner (the clock and workspace
switcher don't really need to be locked down, though they could be too).

A nice thing to do would be to provide a general "locking" mechanism for
panel applets, since I suspect sysadmins will have things they would
like to have some launchers or applets they'd like to lock on. That
might help the documentation problem here too, since it wouldn't be
exceptional behavior.

Just to clarify, I'm not talking about locking in a way the user can't
change. What it means is that to change the applet you have to unlock it
before you affect the change. The reason for this is that its *way* too
easy to mis-stroke, mis-click or otherwise messup and remove something
that's critically important to using the computer (for a particular
user). *I* know that I can right click and add a new menu bar, but that
is not a visible mechanism so we can't rely on it. Thus I want removing
the menu bar to be a slightly more intentional process than just a right
click - click combo.

> Yes, its late in the day, but beta is still a week away.
> I believe that replacing the default panel menu with an
> edge panel is not difficult.  The question is whether this
> a good idea, and in particular whether the functionality
> and quality of the menu bar applet are sufficient stable.

Stability is still an issue, I think, but primarily because of the file
monitoring changes that were (fairly recently) made. I haven't seen any
crashes other than those caused by file monitoring, which I'm tracking
down. In a worst case scenario we could just remove the monitoring and
rely on polling *shrug*.

Another thing that MUST happen before we can switch the menu bar is fix
the stupid panel highlighting issue. If you place the menu bar on a
"normal" panel and click on a menu, all its categories prelight. Its
egregious with the menu bar. With other applets its bad too (because the
whole panel flashes), but not nearly as bad.

The menu bar applet is temporarily screwed up pending a fix to the
panel's handling of applets, but if we replace the menu panel with the
menu bar I'd rather have the menu bar built as a in process library
anyway.

> [BTW: can we change the name of the menu bar applet to just
> menu applet please]

Why?

(I think the name applet is deprecated, btw, at least it appears nowhere
in the interface, unless I've missed a location)

-Seth