After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 132967 - Lock/Unlock objects should be "Lock to Panel" ?
Lock/Unlock objects should be "Lock to Panel" ?
Status: RESOLVED DUPLICATE of bug 114055
Product: gnome-panel
Classification: Other
Component: general
2.5.x
Other Linux
: High major
: ---
Assigned To: Panel Maintainers
Panel Maintainers
Depends on:
Blocks:
 
 
Reported: 2004-01-30 15:39 UTC by Arvind S N
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Have changed "Lock" to "Lock Position" (1.66 KB, patch)
2004-05-14 18:04 UTC, Madhan Raj M
none Details | Review
Patch for displaying Lock / Unlock Position (1.66 KB, patch)
2004-05-17 07:17 UTC, Srinivasa Ragavan
none Details | Review

Description Arvind S N 2004-01-30 15:39:51 UTC
On locking, the launcher the Properties menuitem still exists. 
We should make it insensitive. Hiding would leave the popup menu not look
great.
Comment 1 Luis Villa 2004-02-05 19:49:43 UTC
Hrm, pretty nasty. Certainly not 'locked'. :) Retitling to make a
little more clear. I think this is high, but I can see how others
would disagree- if that was not part of the design, Mark, please knock
it down.
Comment 2 Mark McLoughlin 2004-02-06 08:32:25 UTC
The intention for the feature is that the objects when locked, are
locked to the panel so they can't be accidently pushed/dragged around.
Its not a lockdown feature.

Originally I was thinking of having the menu item be "Lock to Panel"
or something along those lines. That might prevent the confusion.

Usability people?
Comment 3 Calum Benson 2004-02-06 14:14:25 UTC
I'm sure we went through all these permutations in some other bug and
discarded them all for one reason or another, but maybe "Lock
Position" or something would make the intention clearer.  (Although
that doesn't particularly indicate that you can't then remove it
altogether either).
Comment 4 Madhan Raj M 2004-05-14 17:58:39 UTC
I'll agree with Calum. "Lock Position" would be better coz it just tells that we are just making 
the objects immovable. It is more clear . : ) 
Comment 5 Madhan Raj M 2004-05-14 18:04:40 UTC
Created attachment 27712 [details] [review]
Have changed "Lock" to "Lock Position"
Comment 6 Srinivasa Ragavan 2004-05-17 07:17:39 UTC
Created attachment 27771 [details] [review]
Patch for displaying Lock / Unlock Position

I have added a patch, that changes Lock / Unlock to Lock / Unlock Position
(From Calum's comment). Instead of Lock Position, something like 'Stick to
Panel' should also be nice i feel. Any usability comments calum?
Comment 7 Madhan Raj M 2004-05-17 18:07:23 UTC
How about freeze/unfreeze. Would it make sense. What do u say Ragavan, Calum, Mark... 
Any comment ? 
Comment 8 Bryan W Clark 2004-05-17 19:38:20 UTC
Ok, so I believe bug 114055 has some of the discussion on the original lock
position terminology.  The agreed term was "Lock to Panel" on a checkbox and it
looks like it never got through, however I think this is the way to go.  I'll
make a note on that bug as well.

In a related bit, since the intention of the feature is just to lock position
then I would say removing the applet should be allowed too, yes? like in bug
142605  I don't see why if someone is trying to remove the applet they should
know to 'Unlock' it first and then remove it.  Discussion on this should
continue on that bug.

Then to top this all off, bug 114160 has some discussion on locking multiple
applets at once, which perhaps could be taken into account for a better way of
just locking all applets at once; say from a panel menu option.  But this too is
a topic for the other bug I suppose.
Comment 9 Christian Neumair 2004-05-18 16:26:53 UTC
#142605 contains a patch as well. The other one changes a few more bits as well,
though.
Comment 10 Mark McLoughlin 2004-06-02 12:33:57 UTC
Marking this as a dup of bug #114055.



*** This bug has been marked as a duplicate of 114055 ***