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 -- ubuntu-desktop mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
