Re: [Usability]Floating/sliding/other-crack-ridden panels problem

[BioChem333 <biochem333 nyc rr com>]

On Fri, 2002-07-12 at 09:57, Calum Benson wrote:
> The report contains a few possible solutions that we knocked around the
> block a few times, but we can't really settle on one.  So if you care
> about how your panels look and behave, please take a look and tell us
> what you think.

I'm only just now compiling GNOME 2 from source, so I have the benefit
of still seeing GNOME 1.4's behavior for a few more hours. I use an
aligned panel, which is identical to a sliding panel in all but it's
move behavior. As a former windows "power user" (i.e. I happened to
notice I have more than just one mouse button) I always check right
clicking things for additional options. Because of this, I've had no
problems with the panel, except for moving it (which I rarely do).

The GNOME 1.4 behavior provides a panel sub-menu, on the right click
menu of all panel items, which allows me to do everything but move the
panel. Were a panel move option available from there I could get rid of
the hide buttons altogether (currently no-pixmap). From what I could
tell by what people were saying in that thread, you completely removed
the panel sub-menus. This, IMO, is a very bad idea. "bordoley", in the
9th comment down says that a "context menu should act on the selected
object", but a panel object is a part of the panel. When I right click
on a panel object sometimes my mind says I'm right clicking on the panel
and other times it says I'm right clicking on the object. It depends on
what I think I should be able to do at the moment in that part of the
screen.

Changing the hide behavior to grip behavior might be a nice option, but
it doesn't get rid of the buttons. The ideas I liked the most came from
Thomas Vander Stichele (3rd to last comment). His 'a' option would be
great. His 'b' option makes sense (I've often tried to get to the panel
underneath through the transparent bits... it's not intuitive that it
doesn't work). His 'c' option is acceptable although not preferred, as
is his 'd' option.

Rich