Re: Getting a usability patch into gnome-panel package?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greg K Nicholson wrote on 21/02/08 15:43: > On Tue, 2008-02-19 at 17:52 +1300, Matthew Paul Thomas wrote: >... >> Greg K Nicholson wrote on 14/02/08 03:05: >... >>> In which case Alt-dragging wouldn't move the window as usual. >>> ... >> It already doesn't, and probably never has. In Epiphany the modifier >> is ignored, and in Firefox it (probably accidentally) closes the menu. > > Is that by design (and if so, what's the rationale behind it?) or is it > simply a bug that should be fixed? It's a small part of the general bug that keyboard commands entered while a menu is open don't propagate to the parent window. It's the same reason Ctrl+W and Alt+Tab don't work while a menu is open, for example. In this case the bug makes it easy to introduce new Alt+drag behavior for menu items, because no-one has been relying on any other behavior. Cheers - -- Matthew Paul Thomas http://mpt.net.nz/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHvVrb6PUxNfU6ecoRApk0AJwJJGbT6kcKAe0X7TOdT7P6bqUVcwCgmcMg GJO8ahQwrVGH5qn6XappQjc= =g9E2 -END PGP SIGNATURE- -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Getting a usability patch into gnome-panel package?
On Thu, 2008-02-21 at 02:43 +, Greg K Nicholson wrote: > On Tue, 2008-02-19 at 17:52 +1300, Matthew Paul Thomas wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Greg K Nicholson wrote on 14/02/08 03:05: > > > > > >> Epiphany and Firefox could adopt the same behavior in their Bookmarks > > >> menus. > > > > > > In which case Alt-dragging wouldn't move the window as usual. > > >... > > > > It already doesn't, and probably never has. In Epiphany the modifier is > > ignored, and in Firefox it (probably accidentally) closes the menu. > > Is that by design (and if so, what's the rationale behind it?) or is it > simply a bug that should be fixed? Actually, here (on Hardy, using Firefox 3 beta 3) Alt-dragging the window works as expected. -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Getting a usability patch into gnome-panel package?
On Tue, 2008-02-19 at 17:52 +1300, Matthew Paul Thomas wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Greg K Nicholson wrote on 14/02/08 03:05: > > > >> Epiphany and Firefox could adopt the same behavior in their Bookmarks > >> menus. > > > > In which case Alt-dragging wouldn't move the window as usual. > >... > > It already doesn't, and probably never has. In Epiphany the modifier is > ignored, and in Firefox it (probably accidentally) closes the menu. Is that by design (and if so, what's the rationale behind it?) or is it simply a bug that should be fixed? -- Greg -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Getting a usability patch into gnome-panel package?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greg K Nicholson wrote on 14/02/08 03:05: > >> Epiphany and Firefox could adopt the same behavior in their Bookmarks >> menus. > > In which case Alt-dragging wouldn't move the window as usual. >... It already doesn't, and probably never has. In Epiphany the modifier is ignored, and in Firefox it (probably accidentally) closes the menu. Cheers - -- Matthew Paul Thomas http://mpt.net.nz/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHumCA6PUxNfU6ecoRApXgAKChicbTGek7KeWZyek61nDMkfiDLACfVptz djbGGm25MPSDFqyWkRu2FIg= =huGf -END PGP SIGNATURE- -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Getting a usability patch into gnome-panel package?
> Epiphany and Firefox > could adopt the same behavior in their Bookmarks menus. In which case Alt-dragging wouldn't move the window as usual. -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Getting a usability patch into gnome-panel package?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 10, 2008, at 11:01 PM, Ivan Sagalaev wrote: > > Matthew Paul Thomas wrote: >> >> The panel could copy this behavior: Alt+dragging could move the panel, >> while normal dragging does nothing. That way people would be much less >> likely to move the panel by mistake. > > Matthew, do you have any suggestions on how discoverability of this can > be improved? I like Martin Ahnelöv's suggestion of adding a sentence of inline help to the "Panel Properties" window. After all, dragging the panel is functionally equivalent to changing the "Orientation" setting in this window. In the short term it would make sense to add the same sentence to the "Add to Panel" window too (though I think eventually that window shouldn't exist). > I don't think Alt+dragging is a well known concept to general public > or am I wrong? You're right, though I don't think it's particularly important for it to be well-known. Most people won't need to use it. Another way of making it better-known would be to use it consistently throughout Ubuntu, for anything that could be draggable but shouldn't normally be. For example, for any kind of GTK control where clicking on it does something, if you press the mouse button but drag away before releasing the button, that cancels the click. This works for (almost) every kind of control, including menus, *except* the menus in the "Main Menu" and "Menu Bar" panel applets. If you drag away from an item in those menus, they assume you're trying to create a launcher (or in the case of the "Places" menu, copy the files!). This inconsistency could be fixed by making the menus behave like normal menus with an unmodified drag, with Alt+drag invoking the create-launcher behavior. Epiphany and Firefox could adopt the same behavior in their Bookmarks menus. Cheers - -- Matthew Paul Thomas http://mpt.net.nz/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHsmSu6PUxNfU6ecoRAnoZAKCRRp7F4PJ5nqDLuOoHccXDiNglswCgrXzi 5fcT04VlFCnpiWMkQRpbPyI= =qg6r -END PGP SIGNATURE- -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Another panel movement patch (Re: Getting a usability patch into gnome-panel package?)
Le lundi 11 février 2008, à 20:16 -0400, William Lachance a écrit : > 3. Am I asking these questions in the appropriate forum? As an > unaffiliated developer, I'd be just as happy to do this work upstream. > Unfortunately, there's no GNOME mailing list for panel issues that I > know of (and I don't get nearly the same level of feedback through > bugzilla). desktop-devel-list is the upstream mailing list for the panel. It's mentioned in the README ;-) Vincent -- Les gens heureux ne sont pas pressés. -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Another panel movement patch (Re: Getting a usability patch into gnome-panel package?)
On Sun, 2008-02-10 at 17:11 -0400, William Lachance wrote:
>
> On Sun, 2008-02-10 at 22:09 +1300, Matthew Paul Thomas wrote:
> > The panel could copy this behavior: Alt+dragging could move the
> > panel,
> > while normal dragging does nothing. That way people would be much
> > less
> > likely to move the panel by mistake.
>
> FYI, I'm working on this solution (which is even better than anything
> suggested so far: thanks Matthew). Annoyingly, it seems as if I'll need
> to modify metacity in order to make this work. I'll keep everyone
> updated on my progress...
Ok, the two attached patches make it so you need to hold the ALT key
(actually mod1) down to move the panel. Some modification of metacity
was required, not yet sure if said modifications are in the appropriate
place (I'll try to get ahold of the metacity developers to see what they
think).
Things I'm still wondering about:
1. Metacity has a special gconf setting
(/apps/metacity/general/mouse_button_modifier) so that the user can
specify which key they'd like to use as a modifier for making just the
window move. Should gnome-panel respect this setting, even though it's
only supposed to apply to metacity?
2. In the spirit of removing modes, would it also be reasonable to
remove the "locked" mode on each panel applet... and make it so _they_
can only be moved with the mouse when the modifier key is pressed?
3. Am I asking these questions in the appropriate forum? As an
unaffiliated developer, I'd be just as happy to do this work upstream.
Unfortunately, there's no GNOME mailing list for panel issues that I
know of (and I don't get nearly the same level of feedback through
bugzilla).
4. Finally, I'll reiterate my original question: how _does_ one get a
patch into the Ubuntu gnome packages? ;)
--
William Lachance <[EMAIL PROTECTED]>
Index: src/core/display.c
===
--- src/core/display.c (revision 3500)
+++ src/core/display.c (working copy)
@@ -4900,8 +4900,11 @@
while (tmp != NULL)
{
MetaWindow *w = tmp->data;
- meta_display_grab_focus_window_button (display, w);
- meta_display_grab_window_buttons (display, w->xwindow);
+ if (w->type != META_WINDOW_DOCK)
+{
+ meta_display_grab_focus_window_button (display, w);
+ meta_display_grab_window_buttons (display, w->xwindow);
+}
tmp = tmp->next;
}
Index: src/core/window.c
===
--- src/core/window.c (revision 3500)
+++ src/core/window.c (working copy)
@@ -646,8 +646,11 @@
meta_window_ensure_frame (window);
meta_window_grab_keys (window);
- meta_display_grab_window_buttons (window->display, window->xwindow);
- meta_display_grab_focus_window_button (window->display, window);
+ if (window->type != META_WINDOW_DOCK)
+{
+ meta_display_grab_window_buttons (window->display, window->xwindow);
+ meta_display_grab_focus_window_button (window->display, window);
+}
if (window->type == META_WINDOW_DESKTOP ||
window->type == META_WINDOW_DOCK)
Index: gnome-panel/panel-toplevel.c
===
--- gnome-panel/panel-toplevel.c (revision 10713)
+++ gnome-panel/panel-toplevel.c (working copy)
@@ -3179,6 +3179,9 @@
toplevel = PANEL_TOPLEVEL (widget);
+if ((event->state & gtk_accelerator_get_default_mod_mask ()) != GDK_MOD1_MASK)
+return FALSE;
+
if (event->button != 1 && event->button != 2)
return FALSE;
signature.asc
Description: This is a digitally signed message part
--
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Getting a usability patch into gnome-panel package?
On Thursday 07 February 2008 18:18:34 Jan Claeys wrote: > Middle click + drag moves panel applets too (if they aren't locked). > -- > Jan Claeys Thanks for the tip, I didn't know about that. -- BUGabundo :o) (``-_-´´) http://Ubuntu.BUGabundo.net Linux user #443786GPG key 1024D/A1784EBB My new micro-blog @ http://BUGabundo.net ps. My emails tend to sound authority and aggressive. I'm sorry in advance. I'll try to be more assertive as time goes by... signature.asc Description: This is a digitally signed message part. -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Getting a usability patch into gnome-panel package?
On Sun, 2008-02-10 at 22:09 +1300, Matthew Paul Thomas wrote: > The panel could copy this behavior: Alt+dragging could move the > panel, > while normal dragging does nothing. That way people would be much > less > likely to move the panel by mistake. FYI, I'm working on this solution (which is even better than anything suggested so far: thanks Matthew). Annoyingly, it seems as if I'll need to modify metacity in order to make this work. I'll keep everyone updated on my progress... -- William Lachance <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Getting a usability patch into gnome-panel package?
Matthew Paul Thomas wrote: > The panel could copy this behavior: Alt+dragging could move the panel, > while normal dragging does nothing. That way people would be much less > likely to move the panel by mistake. Matthew, do you have any suggestions on how discoverability of this can be improved? I don't think Alt+dragging is a well known concept to general public or am I wrong? -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Getting a usability patch into gnome-panel package?
Le dimanche 10 février 2008, à 22:09 +1300, Matthew Paul Thomas a écrit : > On Feb 7, 2008, at 9:06 AM, William Lachance wrote: >> ... >> A while back I fixed up a patch originally written by Novell to GNOME >> panel, which makes it impossible to move without unlocking it first >> (the default setting is locked). This prevents the user from >> inadvertently moving the panel when (e.g.) they're just trying to open >> an application. >> ... >> This really is a serious usability problem: it's tripped up my >> girlfriend at least once, and you can see lots of complaints in the >> bugs about this happening to other people as well. I'd really love to >> see it fixed. > > Unfortunately this is not a good solution to the problem, because it > introduces an unnecessary mode -- unlocked versus locked. Modes should > be avoided whenever possible, because remembering which mode you're in > takes extra mental effort. > > A better solution would be to introduce a quasimode, a temporary mode > based on a physical action. We already have an example of this for > dragging in Ubuntu: holding down the Alt key currently lets you move > windows by dragging anywhere, even on areas where dragging would > normally do something else. > > The panel could copy this behavior: Alt+dragging could move the panel, > while normal dragging does nothing. That way people would be much less > likely to move the panel by mistake. FWIW, the current plan, discussed at GUADEC, is to have both solutions: "edit mode" (where you can easily move/add/remove applets and panels) and the alt+drag for moving applets and panels. It just needs to be implemented :-) Vincent -- Les gens heureux ne sont pas pressés. -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Getting a usability patch into gnome-panel package?
On Feb 7, 2008, at 9:06 AM, William Lachance wrote: ... A while back I fixed up a patch originally written by Novell to GNOME panel, which makes it impossible to move without unlocking it first (the default setting is locked). This prevents the user from inadvertently moving the panel when (e.g.) they're just trying to open an application. ... This really is a serious usability problem: it's tripped up my girlfriend at least once, and you can see lots of complaints in the bugs about this happening to other people as well. I'd really love to see it fixed. Unfortunately this is not a good solution to the problem, because it introduces an unnecessary mode -- unlocked versus locked. Modes should be avoided whenever possible, because remembering which mode you're in takes extra mental effort. A better solution would be to introduce a quasimode, a temporary mode based on a physical action. We already have an example of this for dragging in Ubuntu: holding down the Alt key currently lets you move windows by dragging anywhere, even on areas where dragging would normally do something else. The panel could copy this behavior: Alt+dragging could move the panel, while normal dragging does nothing. That way people would be much less likely to move the panel by mistake. Cheers -- Matthew Paul Thomas http://mpt.net.nz/ PGP.sig Description: This is a digitally signed message part -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Getting a usability patch into gnome-panel package?
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 t
Re: Getting a usability patch into gnome-panel package?
On Fri, 2008-02-08 at 13:36 +, Greg K Nicholson wrote:
>
> > doesn't it make sense to remove the "Lock"
> > option on individual applets at the same time?
>
> Yes; such a design is described on Gnome Live:
> 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?
> Another (in my opinion, better) approach would be to copy xfce: xfce's
> panel items are arranged according to their *order* rather than their
> *position*. There are flexible spacers to move items to the end of the
> panel. This is very similar to Firefox's and Evince's approach to
> editing toolbars.
I like how this sounds in principle. I'd have to try playing around with
XFCE to see how well it works in practise. 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? In terms of difficulty of implementation,
we're talking about the difference between hours and weeks.
--
William Lachance <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
--
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Getting a usability patch into gnome-panel package?
> doesn't it make sense to remove the "Lock" > option on individual applets at the same time? Yes; such a design is described on Gnome Live: http://live.gnome.org/DesktopInterface#head-e6057484973caefd20f5965074e57c4505ecaf12 Another (in my opinion, better) approach would be to copy xfce: xfce's panel items are arranged according to their *order* rather than their *position*. There are flexible spacers to move items to the end of the panel. This is very similar to Firefox's and Evince's approach to editing toolbars. Panels that are attached to an edge or corner of the screen cannot be moved by dragging; floating panels can, by a handle at the end of the panel. (Note that panels can only be attached to the middle of each edge.) The panel's Properties dialogue is used to choose whether a panel is attached or floating, and (if it's attached) which edge or corner it's attached to, or (if it's floating) whether it should display horizontally or vertically. (If a floating panel is dragged towards the edge of the screen, it may make sense to have it snap to the corner or the middle of the edge, and the handle disappear; but it should be possible to drag it back to floating as long as the mouse button is still pressed.) In xfce, the panel Properties dialogue is also used to toggle whether an attached panel expands to fill the screen; it would be better if that was implied by the presence or absence of a flexible spacer. This model means: 1. items that appear to be in the corner of a panel are always *right* in the corner (allowing unwitting users to exploit Fitts's Law) 2. when an item contracts (for example, when an icon disappears from the system tray) adjacent items always remain adjacent 3. when items are moved, they always end up in a tidy position; trying to shift an item by just a couple of pixels results in it staying where it was 4. there's no need to lock anything as nothing can be accidentally dragged To migrate from a position-based panel arrangement to an order-based one, I'd suggest replacing any gap wider than about 48 pixels with a flexible spacer, and ensuring there's a flexible spacer before the last set of items – to make sure that the clock and system tray (for example) stay at the far right. This would produce a reasonable approximation (or an exact replica) of the previous layout in most cases. -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Getting a usability patch into gnome-panel package?
Op donderdag 07-02-2008 om 09:39 uur [tijdzone -0400], schreef William Lachance: > That being said, the lock option for individual applets seems quite > useless. All it does is make it so you can't move an applet without > the toggle in the context menu, but you can only move the applet by > opening up the context menu anyway Middle click + drag moves panel applets too (if they aren't locked). -- Jan Claeys -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Getting a usability patch into gnome-panel package?
On Wed, 2008-02-06 at 13:59 -0800, Ted Gould wrote: > On Wed, 2008-02-06 at 16:06 -0400, William Lachance wrote: > > A while back I fixed up a patch originally written by Novell to GNOME > > panel, which makes it impossible to move without unlocking it first (the > > default setting is locked). This prevents the user from inadvertently > > moving the panel when (e.g.) they're just trying to open an application. > > While I like this better, doesn't it make sense to remove the "Lock" > option on individual applets at the same time? I don't see why you'd > need both. The lock option on the individual applets does something completely different: preventing the user from moving the applets around. That being said, the lock option for individual applets seems quite useless. All it does is make it so you can't move an applet without the toggle in the context menu, but you can only move the applet by opening up the context menu anyway (thus making it difficult to move the applet by accident). In conclusion: yes, we should probably remove the lock option on individual applets (unless there's something missing; I'll look into this more deeply if I have time later this week), but that's a separate issue. Which brings us back to my original question (see subject line). :) -- William Lachance <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Getting a usability patch into gnome-panel package?
On Wed, 2008-02-06 at 16:06 -0400, William Lachance wrote: > A while back I fixed up a patch originally written by Novell to GNOME > panel, which makes it impossible to move without unlocking it first (the > default setting is locked). This prevents the user from inadvertently > moving the panel when (e.g.) they're just trying to open an application. While I like this better, doesn't it make sense to remove the "Lock" option on individual applets at the same time? I don't see why you'd need both. --Ted signature.asc Description: This is a digitally signed message part -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
