Sure, I agree ...

I was considering this in the bigger context of "panel lockdown" that
we were talking about ... locking down individual applets wasn't meant
to satisfy that requirement, it was more meant as a way to help users
not mess things up unintentionally ...

The way I was imagining locking down a panel to work was that you
wouldn't be able to add/remove/move applets, wouldn't be able to move
the panel, wouldn't be able to configure the panel (i.e. no properties
dialog) ...

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

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

It seems we now have a locked_down key for each toplevel. So the
foundation is here. The only problem is that panel should be restarted
to make it work correctly because the context menus (for applets or
for the panel) are built differently if the panel is locked or not.

So I have three solutions to make this work nicely:

   1. when the user (un)locks a toplevel, we go through each panel
objects and unref the object's context menu, so it will be build again

   2. when the user (un)locks a toplevel, we go through each panel
objects and change a flag telling if, when the context menu was built,
the panel was locked or not. And when we popup the menu, we verify
that the flag and the lock state of the panel is the same.

   3. we build the context menu with everything in it, and we only
hide/show items depending on the lock state of the panel.

Another problem is consistency: currently, when the whole toplevel is
locked, then we hide some context menu items for the applets. But when
an applet is locked, we just set these items insensitive. What's the best?

Oh, btw, we have a global locked_down for gnome-panel. This key locks
everything. If you change the key, you need to restart the panel. I
think we should change the behaviour to something instant-apply,
shouldn't we?

> currently, when the whole toplevel is
> locked, then we hide some context menu items for the applets. But when
> an applet is locked, we just set these items insensitive. What's the best?

The rule that's generally been used so far[1] is that items made unavailable by
the sysadmin (such as applet 'lock' or 'unlock' when the sysadmin has locked
down the whole panel anyway) should be hidden, whereas items that the user can
potentially make available (such as 'unlock' when they've just locked the item
themeselves) should be greyed-out.

Would be interesting to get a docs perspective on this though, as there is
obviously some impact if users look up online help and see options that are not
visible on their screen.

[1] contrary to the current lame HIG advice, btw...

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

Seth, Bryan and I discussed the problem today that if you drag a toplevel menu
panel, you get totally screwed; it's nearly impossible to drag it back if your
launchers are taking up the screen.  Right now we only have the "locked_down"
key which disallows everything, like even adding new launchers.

Vincent: I don't see an individual panel locked_down key in GConf.  I tried:
gconftool-2 -t bool -s /apps/panel/default_setup/toplevels/top_panel/locked_down
true
but it had no effect.

It seems to me that it would be useful to have a per-panel "locked_position" key
that doesn't disallow adding new launchers.  Having that on would be a sane
default.  However, if we also want a per-panel "lock panel and every applet"
thing, then the question is - what UI do we want?  Should we have both "Lock
Position" and "Lock" in the context menu?  Or just put them in the properties? 
Or both?

My instinct is to put the Lock Position in the context menu, and put the
full-lockdown in the properties menu.  This is asymmetric with respect to the
existing "Lock" menu item on applets, but I think that's probably fine, since I
would expect locking/unlocking the entire panel to be a less common operation.

This bug is old, but I think it needs to be addressed. I just can't see the use
case for wanting to lock individual components on a panel. An option to lock the
whole panel is surely all that's needed.

I propose that the context menu (from anywhere on the panel, including any
component) should contain the option "Lock Panel". This should:
 - stop components from being moved on the panel
 - stop the panel itself from being moved (see Bug #309721)

Being able to lock BOTH the panel AND individual components would be confusing
and irritating even for long-time GNOME users like myself, let alone new users.
At least, take away the interface for locking individual components. Sysadmins
admittedly may want to lock down some features of the panel and not others - if
that's the case, the inteface for locking components still isn't necessary.

It's worth pointing out that new computer users have poor mouse control, can't
double-click correctly or double-click when it's not necessary. I've seen panels
(in Windows and GNOME) dragged all over the place to the point where they're
unusable [and unfixable by this new user]). Locking the entire panel easily is a
must - in fact, it should be locked as a whole (as described above) by default
to avoid this.

I wholeheartedly agree with the comment from Mark Florian - I have been using
GNOME for a considerable amount of time now, and being a developer, I consider
myself to be an 'advanced' user. There has not been a single case where locking
down individual panel components has been necessary, and I don't envision there
to ever be in the future either.

Mark makes a good point that the current behaviour is very confusing, and
perhaps undesirable to the average/new user, and given that a number of other
comments seem to come from advanced users, perhaps not for them either? In the
case that a sysadmin would want to tweak this setting, it certainly shouldn't be
visible, but be a GConf key, or accessible through an admin settings UI.

Given the age of this bug, I do hope it receives some attention in the
not-so-distant future :)

I just experienced a bug that made me with the "lock to panel" was a global
preference and not per applet.

The panel crashed (really don't know why) and when it restarted, it didn't set
the "expand" option, so when i turend that on, every applet/launcher was
positioned wrong. I had to left-click and de-select "lock to panel" for 8
applets and 15 launchers to be able to move everything back where it belongs -
now, this sucked.

So +1 for dropping per-applet locking in favour of a global key!

Mass changing: milestone 2.12.x => milestone 2.14.x

Having to lock or unlock every applet individually is rather cumbersome.  I've always wished there was just an option to lock or unlock the panel itself.

I'd like to third, fourth or fifth the comments on this bug. In particular I (by no means a newbie) have messed up my panel by dragging it unintentionally to the side. When moving it back to the top all the icons are in the wrong place. So most of all I would like to be able lock down the panel position. One context menu item to unlock all the applet would be fantastic too, as unlocking and locking each applet individually is a fiddle.

One more thought: Perhaps we shouldn't be able to drag the panel at all (i.e. it is always locked), meaning that there is no need for the potential confusion of locking and unlocking the panel versus locking and unlocking applets. I think it might be better to set its position (left, right, top, bottom) in the config menu that selects whether the panel autohides.

I often return to my desktop from playing a game (that is, an application that uses a resolution different to my desktop resolution) and find my panel messed up too. Apparently, this is caused by the resizing of the panel back and forth to a lower resolution and a lack of space on the panel in that resolution.

Can it be done to save the panel state for each resolution separately? That would be useful for people like me, who work with different resolution all the time.

so...who is in charge for this? i would like to do it, wich way we are going for?

I did some thinking out loud about a possible solution to this on my blog:

http://www.stevenbrown.ca/blog/archives/207

Basically, my suggestion was to have a panel-layout-editing mode, for moving, locking, unlocking applets and panels themselves.  Rough mockup in blog.  I'm interested in following and contributing to this discussion.  Does gnome-panel have it's own mailing list or would discussion most likely happen here on this bug report?

I for one would be happiest with a global "locked" switch for all panels, which would both prevent moving the panels by dragging, and moving individual applets.  It should be on by default to prevent accidental panel dragging.

Trashing the individual applet locks at the same time would be a bonus in my book.  Is there really a use case for allowing some applets to be moved while preventing others?

Steven Brown's "edit mode" suggestion sounds like it's mostly the same, but with an inverted option sense.

Also, I think having the global lock (as a gconf key) would remove/replace the need for the locked_down key, since a mandatory global lock value would be effectively the same as the locked down key.

In any solution, it would be nice that locking an applet/bar unable the remove option.

I agree with Joe Dalton.
It is rather disturbing to accidentally remove a supposedly locked trash can from the Ubuntu control panel instead of emptying it !

That said, a global "locked" switch would be nice.

IMO This should work like "customize [toolbar]" in Firefox (maybe even borrow some code?).  Everything is locked until "customize" is selected, and then "add to panel" and/or "[panel] properties" would also come up.

I Agree:
One lock("customize") for the whole toolbar and disallow removel if locked.

Benefits
- less clutterd right click menus on applets (3 menu items less): let the user focus on what he wants to do
- dont remove menu bars accidently (I've installed gonme for my mother and everytime(!!) i have a look at it some applets are accidently missing)

I agree gnome panel will be very easier to use with that possibility.

There is an option in the program ubuntu-tweak (screen Desktop -> GNOME) to lock or unlock panels (exactly the desired behaviour). So I think this bug is not very hard to fix.

The program ubuntu-tweak just switches the boolean gconf key "/apps/panel/global/locked_down".

In Ubuntu 8.04, when I switch this key (e.g. with gconf-editor) the change immediately applies: all panels are locked - very nice.

So the low-tech variant of making this really useful would be a panel applet to switch this key with one click.

A better version would be to have another boolean gconf key (e.g. "/apps/panel/global/locking_editable") that adds a menu item "Un-/Lock Panels" to all panels' context menus.

With this in place, locking of individual panel objects would have become obsolete.

I have also tried to enable/disable this boolean in gconf on ubuntu 9.04, and it works very well too.

So, we just need a little option which can be rushed from somewhere on gnome-panel which enable/disable this boolean.

Created attachment 140846 [details] [review]
First try to add a global lock

Here's my first attempt to create a global lock function for the panels. 

It reuses the most of panel_lockdown infrastructure but does not use the gconf setting as the switch (I think that one is used for "real" lockdowns). Instead I created a runtime-only switch that enables editing the panels (after relogin you're back to a non-editable panel).
I've also ripped out most of the locked-per-applet stuff but the function signature remains as they are (I'm not sure if this will break any api, so assistance here is welcome).
What else to say, it seems to work well even in conjunction with the real lockdown feature.

Comments? Am I completely off or am I going in the right direction?

PS.
In panel-widget.c around line 2216 - without the "!" it wouldn't let me move bonobo (?) applets with middle button and was screaming about cannot grab mousepointer and "invalid time" as error code.

 	event_time = event->time;
-	if (event->send_event)
+	if (!event->send_event)
 		event_time = GDK_CURRENT_TIME;

Created attachment 140847 [details]
Screenshot showing the patch in action

(sorry about the spam before but new bugzilla wouldn't let me attach the patch as a patch (I hadn't chosen a status, but couldn't), had to workaround by creating a plain text first)

I have just tried your patch, it seems to work well.

It is exactly what we need. The checkbox item is only shown on panel's  options dialog, not on widgets option dialog, it is perfect :)

One problem : I cannot move the panels, I have not tested before the patch, so perhaps it is a problem with my virtual machine (I use Alt + left mouse button)

Thank you very much for your work.

Thanks for trying the patch. I also have the same problem with dragging panels (even without the patch) in Virtual Box.

Follow up on the middle click moving thing; http://bugzilla.gnome.org/show_bug.cgi?id=588488 has an attached patch that fixes the issue.

The new way to to edit panels (which requires a modifier on the context menu) removes the need for this, IMHO.

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