Getting a usability patch into gnome-panel package?

[Greg K Nicholson]

On Fri, 2008-02-08 at 12:36 -0400, William Lachance wrote:
> > http://live.gnome.org/DesktopInterface#head-e6057484973caefd20f5965074e57c4505ecaf12
> 
> Interesting, this does seem like an improvement upon what I was
> originally advocating for, though I wonder if it might be confusing for
> a global option ("Lock Panel") to appear in the context menu for an
> individual applet? Any thoughts on this?

It may be illogical, but I don't think it'd be too confusing: unlocking
the panel does eventually affect the applet itself.

I think, however, that I have a better idea :) :

If we're going to have two modes (editable and locked), I suggest tying
the editable mode to the Add to Panel dialogue. I'd do the following:


1. From the panel's context menu, relabel “Add to Panel” to “Edit
Panels”. Optionally also remove “Delete This Panel”, “New Panel”
and “Properties”.

2. From applets' context menus, remove “Move” and “Lock To Panel”.
Optionally also remove “Remove From Panel”. Add “Edit Panels” as the
final item, probably below a separator.

3. Rename the Add to Panel dialogue to “Edit Panels”. Add four buttons
to it (all of which are explained properly below):

3.1. A “Remove” button to delete the focused applet.

3.2. A “Delete This Panel” button to delete the focused panel.

3.3. A “Panel Properties” button to open the properties dialogue of
the focused panel.

3.4. An “Add New Panel” button to add a new panel.

3.5. “Remove” should sit next to the existing Add button. Delete This
Panel and Panel Properties should sit together (perhaps at the top of
the dialogue). Add New Panel should be somewhere near Delete This Panel
(though not necessarily adjacent).

4. While the Edit Panels dialogue is open, the panels (all of them) are
in (what I'll refer to for brevity as) “edit mode”; at all other times,
they're in “use mode”.

5. In use mode:

5.1. Applets cannot be dragged around (even using the middle mouse
button).

5.2. Panels cannot be dragged around.

5.3. If the optional things have been removed from the context menus,
they can't be created or destroyed either, or at all edited.

6. In edit mode:

6.1. Applets on panels can be focused (typically by clicking, but also
(somehow) using the keyboard). This means that in edit mode, panel
applets can't actually be used – much like toolbar buttons in Firefox
and Evince while the toolbar customisation palette is open. (Obviously,
there'd be a clear focus ring of some sort.)

6.2. Panels can also be focused (by clicking them or using the
keyboard).

6.3. When a panel is focused:

6.3.1. The Delete This Panel button becomes active (it's disabled
otherwise). It deletes the entire panel (probably after a confirmation
dialogue).

6.3.2. The Panel Properties button becomes active; it opens the existing
Panel Properties dialogue for the focused panel (previously accessed
from the panel's context menu).

6.4. When an applet on a panel is focused:

6.4.1. The panel on which it sits is implicitly also focused (though
doesn't receive its own focus ring). This solves the problem where a
full panel can't be interacted with.

6.4.2. The Remove button becomes active; it and the Delete key remove
the focused applet from the panel.

6.5. The Add button is only enabled when an applet in the dialogue is
focused. (These should get the same visual treatment for focus as
applets on the panel.)

6.6. Applets on panels can be dragged around (using the left mouse
button, not (just) the middle mouse button), including to and from other
panels and the dialogue. (Shift + Arrow keys might also move an applet.)

6.7. Panels can be dragged to different screen edges by grabbing an
empty area. Note that if there's no empty space, they can still be moved
using their Properties dialogue.

6.8. Clicking on a panel should raise the Edit Panels dialogue to the
foreground, if it isn't there already.

7. For bonus points, “About Panels” can be removed from the panel's
context menu and made into a button in the Edit Panels dialogue, next to
Help.


The rationale behind this devious scheme is that, while there are still
(versus the global panel lock proposal) two modes, it's much more
obvious which mode you're in – either the panels work as normal, or they
don't work at all and a great big Edit Panels dialogue shows up when you
click them.

In the hardcore version of this – with all the optional-to-remove
things removed – the panel setup can *only* be changed while the Edit
Panels dialogue is open. This makes for cleaner separation between the
two modes (and I prefer this option).

Options that are superfluous to everyday use of the panels are removed
from their context menus and given their own mode, geared towards
editing the panels.

I think users are likely to want to do several of these panel-editing
actions in a row. Removing these actions from the context menus and
giving them buttons in the dialogue may end up *reducing* the total
number of clicks it takes to customise the panels, as the user won't
have to repeatedly open context menus.

One caveat for this design: keyboard access hasn't been thought through
at all.

> > copy xfce
...
> I like how this sounds in principle. I'd have to try playing around with
> XFCE to see how well it works in practise. 

OK. By the way, my design above would work for both position-based
placement and order-based placement.

> Even if it does turn out to
> be the "right way" to do things, what do you think about the above
> design as an interim solution? 

Just locking the panel globally *would* be better than having to unlock each item individually.

> In terms of difficulty of implementation,
> we're talking about the difference between hours and weeks.

Of course.
-- 
Greg K Nicholson