This is also a problem with floating and corner panels.

This is actually a duplicate but I can't find the earlier report ATM
so marking this one up.

Well, there is at least a workaround-- thanks to a recent fix from
padraig, you can now press Ctrl+F10 when any panel object has focus to
pop up the parent panel's menu.

Three possible fixes I can think of to get around this problem:

1) disable/remove the "Show Hide buttons" checkbox from the floating
panel preferences dialog-- so floating panels would always have the
buttons, but the user could still choose whether or not to have arrows
on them.  Without arrows the buttons are very slim anyway, so this
might be a reasonable thing to do.

2) Show the slim (no-pixmap) version of the hide buttons even if the
user deselected "Show Hide buttons" for a floating panel.  If the user
clicked the buttons in this mode, they wouldn't actually show/hide the
panel, they would function only as an area for dragging the panel
or popping up the right-click menu.  But that would be inconsistent
with other panels' behaviour, so we'd probably have to make all of
them behave like that.

3) Pop up a warning dialog if the user unchecked the "Show Hide
buttons" checkbox for a floating panel, to explain that the only way
they could then get at the panel menu would be to press Ctrl+F10. 
Yuck.

calum: discussed with Mark on irc, he was of the opinion that extra
padding to the right of the panel would fine for the moment.

Created attachment 8809 [details] [review]
Patch for adding extra padding to the panel

Hmm, it looks a bit odd. I thought it might be nice to have some
padding at either end of the panel, but it doesn't look right.

Calum: re your ideas ...

1) people don't always want hide buttons on these panels. I know when
I ever use them, I hate hidebuttons.

2) isn't too bad, but as you say inconsistent

3) Yuck :-)

1) I know people don't use them, but would people really be upset
about seeing the slim version of them there (which is what, 6 pixels
at each end) anyway?  I'd bet most people wouldn't even notice,
although there would doubtless be a vocal minority who complained :)

2) yes, in the longer term, this is probably the better solution, but
it would probably have to work like this on all panels, not just
floating ones.  Which is too big a change to make without some sort of
general agreement on whether it's a good idea or not... I'll try and
kick off a discussion about this on the lists, although I know people
have more important things to worry about right now.

Is there a reason to not add a panel-properties menu item to the
right-click menu of the launchers?

nesting multiple layers of submenus makes menus hard to use. 

Also context menu should act on the selected object (ooui design) so
panel menu's in the context menus of launchers and other panel objects
doesn't make sense really. 

also putting drag handles on all panel would be really bad if we
decided to ditch the menu panel in favor of an edge panel with a
menubar since we would most definately end up breaking fitts law
(throwing the mouse into the corner for pull down menus). I'm not
quite sure if this was actually suggested above (I'm a little unclear
on some of calum's comments) but it seems like it may have.

No, you're right, the Fitt's law thing would be one point against my
2nd suggestion above if we did it for all panels.  Although I'm not
sure how big a point-- when it comes to menus, I suspect people still
generally move the pointer more towards the middle of the menu title
(in the horizontal axis) rather than the left or right edge, so in
that regard it would still work for most people most of the time. 
That's just uneducated guesswork though :)

From a purely pragmatic stand point, I think drag handles on the edge
panel would just look bad (by default) and that we'd probably get lots
of complaints.

Also if we end up switching to using the menubar on an edge panel
instead of the menu panel i really  really really think we should try
to adhere to fitts law as much as possible. It's a well known
usability principle and makes alot of sense.

Basically i don't think we should break the current behavior of other
panels because sliding panels are broken. (especially since the edge
panel is probably the most used panel after the menu panel). In the
end i'd rather see the sliding panel special case rather than break
other panels.

Hmm, sounds like option 2 is kind of the preference then, provided we
don't do it for edge/menu panels.  I see another problem with that
though-- you wouldn't be able to tell the difference (visually)
between "hide buttons off" and "hide buttons on, but no arrows".

So that, I think, leaves us with a couple of options (other than the
status quo):

a) just don't let the users switch off the hide buttons for this type
of panel

b) if they switch the hide buttons off, leave a gripper bar at one end
of the panel (like the one on the tasklist applet) 

Do either of those appeal?

*** Bug 85402 has been marked as a duplicate of this bug. ***

I sort of like b) i guess. But my opinion on this is purely based on
wanting to maintain the current behavior of the edge panel as I am not
a big user of the other panels. Maybe someone who uses sliding panels
more often can comment on which behavior they prefer. 

*** Bug 79437 has been marked as a duplicate of this bug. ***

*** Bug 87405 has been marked as a duplicate of this bug. ***

We had another couple of (slightly wackier) ideas on IRC.  So the
complete list of vaguely feasible options is currently:

1) have a grab bar* at the top or left edge of any panel on which the
user turned off the hide-buttons. This would have to include edge
panels, but hey, Windoze does this on its taskbar too :)

2) as option 1, but add a context menu item to the grab bar to let you
turn that off too  Only way to get the hide buttons back then would be
to open the panel's Properties dialog, which you'd have to do via
Ctrl+F10 if there was no free space on the panel.

3) as option 1, but have a gconf key that specifies whether you get a
grab bar or nothing at all when you turn off panel's hide buttons
(default would be to show the grab bar)

4) just add a new "grab bar" option to the panel properties dialog,
that's mutually exclusive with "hide buttons".  (This seems kind of
pointless to me, you might as well just leave the hide buttons
switched on).

5) do nothing, as if you turn off the hide buttons you get what you
deserve :o)

* Note: the "grab bar" we're talking about here may actually just have
to look like a hide button without a pixmap... more investigation
required there.

Mark, Dave, Seth, anyone(!)... comments please?  Arvind, Glynn, Nils
and I just keep going round in circles whenever we talk about this! 
From a pure usability perspective I personally favour 1 or 2 in
roughly that order (but appreciate that people may consider 1 to be
visually unappealing, even though I don't think it is), or 3 at a bit
of a push...

I think (1) isn't too bad for user created panels... But... For say a
menu panel or something this would be pretty bleah. Since we're
wanting to remove a special menu panel, this would pose a problem.

The wackiness here, IMO, is that we're relying on a right click menu
for these settings. There should be a way of accessing this stuff
without a right click menu. It fixes this problem, and its better for
both accesibility and usability.

he problem is that there's not a fixed number of panels :-/ Otherwise
we could put it in the panel item in desktop preferences. (Panel
designer anyone? *grin*) Calum, can you think of a good place to put
this stuff as an alternative to the right click menu? T

This is my number one pet peeve.  I love sliding panels.  The hide
buttons are ugly and that's why I always turn them off.  The grips
without hide buttons are ugly as well.  I have been forced to leave
those ugly arrows there after I realized that I had no way of moving
the panel after I remove the buttons.

So here are a few suggestions on what could be done.  All of them
focus on leaving the panel without hide buttons and grips.

a) what looks the easiest option to me is to use the new menu merge
feature.  Every applet in my panel I right-click on offers the options
"Remove from panel" and "Move".  I would add to those "Panel settings"
and "Panel move".  Both would do the obvious thing.  Calum argued that
he doesn't like rightclicking to move a panel (compare to windows),
but my arguments is that I don't often need to move a panel.
If other functionality is needed (maybe Add to Panel is necessary as
well ?) it should be added.  If this is a problem, maybe make a nested
menu; provide "Panel >" and have it slide out to all of the necessary
options.

b) failing this, I might be persuaded to rest my case if somehow there
was enough extra space to click on which would be the panel.  This
would involve making the applets "transparent" for mouse clicks. 
Like, an app launcher with an icon ought to be non-clickable in the
transparent bits around it, so that you actually focus the panel.  I
don't think that's really easy to do.

c) One more solution I would like is just dead simple : instead of the
arrows and grips, just add one mandatory "icon" which brings up that
panel's menu.

d) and finally, why not try to find a keybinding that works with a
click ? I'm not too good on keybindings, but ctrl-alt-mouseclick on a
panel is fine by me.

Let me know if I'm being stupid here, I'd personally prefer a as it's
nice and unobtrusive.

*** Bug 85487 has been marked as a duplicate of this bug. ***

Suggestion: Per Calum's Wacky Number 1, have a "grab bar," but only
visible when the panel or a panel object is selected/focused. -- per
the behaviour of e.g. Windows Active Desktop objects, which have a
title bar and borders only when focused...

Doesn't help edge panel (or menu panel) much, though, depending on
where the grab bar appears. Would work with other 3 kinds pretty well... 

Some comments on thomas's options:

a) (menu merge) yes, this would be easy, but you end up with two
"Move" items and two "Properties" items (or one "Properties" and one
"Preferences", which is worse)-- one for the panel, and one for the
object.  They would presumably have the same/similar icons too.  We
thought this would be rather ugly and confusing (even if they were
labelled "Move Launcher" and "Move Panel" or whatever), which is why
we've avoided doing this up to now.  Also it kind of breaks the model
of a context menu only having items relevant to the item you're
clicking on.

b) (pass clicks on transparent areas to panel) don't know how
easy/hard this one is to implement, but its usefulness would of course
depend on what you happened to have on your panel.  As such, I don't
think it's a really good solution.

c) (have a dedicated clickable thing on each panel) I've thought about
this one before, but couldn't design anything that was both
unobtrusive enough to satisfy everyone but big enough to be useful :) 
In practice I don't think it's really any different from the "grab
bar" idea, really.

d) (modifier+click/drag) This would work *if* you knew about it-- it
wouldn't be very "discoverable" (or especially accessible, although it
would just about do).

I like Bruce's thought about only making the grab handle (or whatever
you want to call it) visible when the panel or something on it has
focus, but I see two problems with it:

1) things would have to jump around the panel to make room for the
grab bar when you focused the panel-- otherwise you might as well just
leave the space there all the time.  You might just about get away
with this for non-edge panels, but I think it would probably be
annoying at best.

2) if your panel consists only of launchers, how would you give it
focus without launching something anyway?  :)

FWIW, I think the best solution I have heard is the one presented by 
seth. A "panel designer" would solve this problem for this one special 
case while not obtrusively affecting the ui of other panels.

A panel designer wouldn't help the "where do I click to move this
thing" problem, though.

Today's crazy idea... what if ctrl+right-click anywhere on a panel
popped up the panel menu (just like Ctrl+F10 does from the keyboard),
and there was a "Move Panel" item on that menu that put you into a
'move mode' a bit like the one for panel objects?

The move mode would probably need to work from the keyboard too,
though (although right now you can adjust the position from the
keyboard in the panel props dialog, so it wouldn't have to be the top
priority), so could be a bit of work to get right.

Okay from reading all this, I think the most sensible solution is ...

1) For expandable panels (i.e. floating, corner and sliding panels)
you have the option of either having the the hide buttons, a grab
handle or nothing.

2) These panels would then be draggable using button 1 and 2 on the
grab handle and you get the normal panel context menu with button 3.

Is that a reasonable plan for me to go ahead with ?

Removing the GNOME2.0.1 keyword because this will be a new feature and
will have to wait until 2.2

*** Bug 89269 has been marked as a duplicate of this bug. ***

Mark: would it be possible to make the regular hide buttons draggable
with button 1, in addition to be clickable as they are now?

I ask because if the drag handle you suggest is going to be made
optional anyway, I don't really see what advantage it offers to the
user over just keeping the slim (arrow-less) hide buttons turned on,
other than a minute saving of space at one end of the panel.  So
adding this 'draggable' functionality to the hide-buttons instead
maybe makes more sense and means we don't have to add any more options
to the panel's properties dialog.

Calum: wouldn't making a button draggable with button 1 be really
confusing ? Remember this isn't drag and drop ... I.e. click button1
on the button, drag, release button1 and you'd expect it to activate
the button.

Also, its a button, buttons aren't for dragging, grab handles are
though. So does it not make more sense to have a grab handle ?

Yeah, you do have a point  :)  But hide buttons are already so
different from regular buttons (e.g. you can remove their labels, you
can turn them on or off, and you can drag them with the middle button)
that I don't know if adding the ability to drag them with button 1 as
well would really break the user's expectations about 'regular'
buttons any more than we already do.

Anyway, don't really want to drag this one out any more (ho-ho), so I
guess if you disagree you can go ahead with the drag bar idea... it's
probably still an improvement on what we have.  (Although neither of
these ideas solve the problem of how to get at a panel's properties
when the buttons/bar are turned off altogether, which is what the
original bug report was about!)

I think the most disturbing feature here is this:

If I disable the hide buttons, I can't reverse the operation without
knowing about Ctrl-F10. So I'm locked into a bad state. That is what
happened to me. It took me a while of googling to figure out what to do...

The thing is that this problem remains even if you add a grab handle
option. As soon as you turn that handle off, you're lost. And any
curious user might do that, so it's a serious usability issue...

I remember one usability expert saying "Don't mode me in"...

What we really need is to *always* be able to access the panel
preferences (and move the panel). Always, and in the same manner. I
can only say that having a "Panel > " sub-menu in the context menu was
one of the usability improvements I really remember (it really made
life easier).

Please consider the implications.

/Mikael

I agree with your point about the grab handle; IMHO if we have one of
those then you shouldn't be able to switch it off, otherwise it's kind
of pointless.  But equally you might as well not have a grab handle
and just not let the user switch off the hide buttons, which do much
the same job... but that takes us back to square one :)

I guess I'm getting kind of resigned to putting panel-related stuff
back on every panel object's right click menu, even though I really
dislike the idea.  It breaks the whole model that context menus are
for the selected object(s) only, if we put it at the top level we end
up with similar/duplicated menu items on the same menu, and if we put
it in a submenu, it breaks the HIG guidelines (context menus shouldn't
have submenus)  :/

*** Bug 93857 has been marked as a duplicate of this bug. ***

A suggestion: Adding one or more of the words "right", "click",
"properties", or "menu" to this bug report might cut down on the
number of duplicates.  I filed #93857 (a duplicate) after searching
for those 4 words.

In general, bug report summaries are more searchable if they describe
the bug itself rather than a proposed solution.

*** Bug 94446 has been marked as a duplicate of this bug. ***

*** Bug 94697 has been marked as a duplicate of this bug. ***

The current help item on each launcher's sub-menu is for the panel,
not the launcher. This conflicts with what calum said about what a 
context menu should be. This should be removed IMHO

As for sub-menus in context menus - there are sub-menus on the panel
menu - i dont see the problem with adding the panel menu as a submenu
to the launcher and context menu.

something like this:

Properties
Remove From Panel
Move
-----------------
Panel          ->

panel context menu is bad, see calum's above comment on the confusion
this may cause.

Also the fact that the current panel menu has submenus as well is not
an excuse to add another, as I'm sure most other ui people would agree
it would be much better to move away from the right click add to panel
-> ... to a right click "edit panel" menu entry that brought up some
sort of direct manipulation ui (ie drag and drop) for adding stuff to
the panel. 

*** Bug 96384 has been marked as a duplicate of this bug. ***

*** Bug 68469 has been marked as a duplicate of this bug. ***

*** Bug 97076 has been marked as a duplicate of this bug. ***

*** Bug 98532 has been marked as a duplicate of this bug. ***

<sigh> targetting this at 2.3.

*** Bug 103299 has been marked as a duplicate of this bug. ***

So, I think I've come to the conclusion that floating panels without
buttons should have a grab handle on each end. I've tried it out and
it doesn't look too bad at all. Thoughts anybody ?

Mark, can you post a screenshot?

Sure ... I've only done this in a new toplevel widget I'm working on,
so this won't appear in the panel until I'm finished that widget.

Created attachment 13638 [details]
screenshot of a floating panel with grab handles

Sounds (and looks) reasonable to me... doesn't really help the "where
can I right-click" situation for buttonless edge panels though :/

Please keep in mind that this really looks ugly on transparent panels
for the buttons will not go transparent. 

Seems to be buggy even for color background without transparency - the
buttons will still show the background image I had set as background
of the panel some time ago. Another bug? Yikes. 

this sollution is worse than the problem.  If I wanted that, I
wouldn't have turned the button off to begin with.

Best sollution already offered IMO: if a panel has no handles and no
empty space, *force* a few pixels of padding on each size (or just at
left/top).

*** Bug 105443 has been marked as a duplicate of this bug. ***

Having read most of the comments on this bug, I'd like to add my 2p's
worth...

1) I disagree with having a visible "grab bar" because that sounds
just as ugly as having hide buttons!

2) Forcing some padding to side(s)/top/bottom of the bar sounds like a
quick fix to me. It may not be obvious to the user, particually for
transparent panels, that they have to click right at the edge of the
panel.

I would very much prefer to see a "Panel" submenu on the context menu
for each applet/launcher, regardless of breaking HIG guidelines.

By now, the panel IS unusable if one removes the hiding buttons. What
about popping up a warning to the user telling about CTRL+F10?

This don't solve the problem but makes the panel usable.

Another thing is that right clicking on the empty space that surrounds
a color-keyed (transparent) icon should open the panel context menu
and not the "nearest icon" one. This is not intuitive for me (nor for
the average user, I suppose).

However, thanks for working so hard on gnome usability.

There is now a handle in cvs HEAD. So I guess we can close the bug.

*** Bug 118611 has been marked as a duplicate of this bug. ***

*** Bug 117298 has been marked as a duplicate of this bug. ***

*** Bug 113862 has been marked as a duplicate of this bug. ***

*** Bug 120662 has been marked as a duplicate of this bug. ***

*** Bug 106638 has been marked as a duplicate of this bug. ***

*** Bug 124378 has been marked as a duplicate of this bug. ***

*** Bug 129438 has been marked as a duplicate of this bug. ***

*** Bug 152962 has been marked as a duplicate of this bug. ***

(In reply to comment #3)
> Three possible fixes I can think of to get around this problem:

Except there's a fourth possible fix, that's implied by the original report:
Have the launchers' own right click menu inherit the panel right click menu, or at least the essentials of it.