GNOME Bugzilla – Bug 142605
Panel should allow removal of locked applets
Last modified: 2004-12-22 21:47:04 UTC
There is no reason to prevent locked applets from being removed through their context menu. Reasoning under http://lists.gnome.org/archives/desktop-devel-list/2004-May/msg00221.html regs, Chris
Created attachment 27752 [details] [review] Proposed patch against HEAD.
What about the case when the desktop as a whole is locked (for public kiosks, computer labs and so on)? If the "lock/unlock" feature is intended to lock panel objects in place permanently for this case, allowing people to remove them would defeat this function.
gnome-panel/applet.c:panel_applet_create_menu only seems to create the menu if !panel_lockdown_get_locked_down() is true. Playing around with the /apps/panel/global/locked_down gconf key revealed that it in fact doesn't construct any of these menu entries if the panel is locked down. regs, Chris
The locked / unlocked applet is only for position on the Panel and has nothing to do with the "locking down" of the desktop. see bug 132967 for more discussion on the terminology of this. I agree that users should be able to remove the applet even when it is locked down, as the "lock down" is simply about positioning of the applet. Is there a patch available to fix this?
I would strongly disagree with this. Locked should be locked and should not allow the individual to modify the applet in any way. Consider the Menu Applet, this applet has only 4 options in the right-click menu. Help, Remove, Lock/Unlock, Move. If a user were to accidentally remove the menu they could be at a loss how to add things back and in the meantime they have lost their menu. Not a good situation to be in. This could easily happen if a distribution ships with a locked down menu in the applet position is locked sense (not the menu can't be user modified sense). The other thing to keep in mind is menus which involve a certain amount of customization. You don't want these to be easily and accidently removed. In terms of general philosophy it makes sense to lock everything with the Lock/Unlock choice. It is relatively infrequent that one adds or removes applets. And generally they do this at the same time they move applets around. For instance last week I started using the desklets weather applet. I removed the weather applet on the panel which freed up some space and I then moved stuff around. Having to unlock the weather applet before I removed it was no big deal considering I had to unlock half the other menus to move them. Finally I don't think it is confusing in any way. If the applet is locked then pretty much everything except the Unlock choice is grayed out. Any confusion should be cleared up relatively quickly when they note that the only choice next to the option which they want which is not grayed out is the correct choice namely Unlock. So please please please please don't change this behavior.
Okay, I'm committed a patch to HEAD to allow locked applets to be remove based on Bryan's comment. Manny: I've use your patch, but removed the change to use "Lock Position" terminology (see #132967) and I've also made it possible to remove launchers/action buttons etc. See the applet.c changes. 2004-06-02 Mark McLoughlin <mark@skynet.ie> * applet.[ch]: (panel_applet_lock), (panel_applet_create_menu), (panel_applet_register): Allow all other panel objects to be removed even when locked. 2004-06-02 Mark McLoughlin <mark@skynet.ie> Patch from Christian Neumair <chris@gnome-de.org> in bug #142605. * panel-applet-frame.c: (panel_applet_frame_sync_menu_state): Allow applets to be removed even when locked.