Version: (using KDE 4.2.3) Installed from: Ubuntu Packages On the desktop context menu there are two actions with similar wording: Lock Screen Lock Widgets "Lock Screen" makes it so that the screen cannot be used. That implies that "Lock Widgets" would make it so that the widgets cannot be used. I propose "Set Widgets", or better yet, "Set Plasmoids" to replace "Lock Widgets".
"Lock" is more meaningful than "set". The widgets are locked in place. I wouldn't expect anything else from this notation. "Set widgets" is like "setup", I'd expect it to be the same as "unlock".
How about "Anchor Plasmoids"?
"Anchor" sounds reasonable IMHO, everybody should now what that means. :)
as a North American English speaker, "anchor" has zero meaning to me in relation to widgets :)
Not native English speaker here. "Anchor" is pretty accurate. It is meaningful to me and other users because of applications like OOWriter. Since it is used for many years I would say we should reuse it because of the similarity (unless there is some better choice, "lock" isn't because of the dissimilarity). It has also good counterpart in Polish, while "lock" does not have.
> as a North American English speaker, "anchor" has zero > meaning to me in relation to widgets Aaron, what words _do_ have meaning in relation to widgets? Only those words for which we make the context. "Lock" certainly had no meaning in relation to widgets when widgets were invented. In any case, as it has been stressed to call the Plasma-specific widgets "Plasmoids" no word in any language yet has meaning in context!
This is not a WishList item. It is a usability issue. Are usability issues bugs or should we have an additional category for them? What 'Unlock Widgets' should be is 'Configure Widgets'. I can't think of something for an opposite string, I suggest that it should simply be 'Configure Widgets' and it could be turned on and off.
"Configure widgets" not even suggests, it simply says, it configures widgets, which would be untrue. [ ] anchor plasmoids is more appropriate (actually it is my favourite, Peter proposition (from ML) with "pin" is #2).
In light of bug #196201 (the term "plasmoid" is not to be shown in the UI) I propose either: 1) ☐ Anchor Widgets // when 'unlocked' ☑ Anchor Widgets // when 'locked' 2) ☑ Configure Widgets // when 'unlocked' ☐ Configure Widgets // when 'locked' 3) Anchor Widgets // when 'unlocked' Configure Widgets // when 'locked'
ad.3) it is HIG violation and should not be used ad.2) it is misleading/confusing, you would use term "configure" as an action and as a state (even maybe in the same menu, not good)
Why not to change this to "Lock/Unlock widgets editing" - does not confuses with lock screen. Or "Lock/Unlock layout" - in this mode we change layout more than widgets itself.
Lukas is on the right track, I think that it could be improved to "Enable Widgets Editing".
(In reply to comment #12) > Lukas is on the right track, I think that it could be improved to "Enable > Widgets Editing". Yes, that would be OK. IMHO, the one important issue is not to have "Locked" be the first word of the phrase since it is easily confused with "Lock Screen".
How did E17 managed this task? Them have a sort of "editing status" of desktop objects.
If anything, as a native english speaker, I would say that "Lock widget layout" would make the most sense. Not "anchor", not "set widgets", not "Lock widget editing", and certainly not "Configure Widgets".
Hello! This feature request was filed for KDE Plasma 4, which reached end-of-support status in August 2015. KDE Plasma 5's desktop shell has been almost completely rewritten for better performance and usability, so it is likely that this feature request is already implemented in Plasma 5, or is no longer applicable. Accordingly, we hope you understand why we must close this feature request. If the requested feature is still desired but not implemented in KDE Plasma 5.12 or later, please feel free to open a new ticket in the "plasmashell" product after reading https://community.kde.org/Get_Involved/Bug_Reporting If you would like to get involved in KDE's bug triaging effort so that future mass bug closes like this are less likely, please read https://community.kde.org/Get_Involved#Bug_Triaging Thanks for your understanding! Nate Graham