Version: (using Devel) Installed from: Compiled sources desktop context menu: disable menu entries, do not remove them In http://bugs.kde.org/show_bug.cgi?id=158275#c4 William noted that the context menu in locked and unlocked mode differs. It is hard for user to realize that it is not that some feature is missing, but just the mode is changed. I can only add this is HIG violation -- if some options are unavailable then they should be disabled, not removed (example: when clipboard is empty you don't remove "paste" from edit menu).
*** This bug has been marked as a duplicate of 158275 ***
:-) I intentionally separated this from this other report, oh well...
Sebastian, please either this report or the other one. The other report is fixed indeed, but this one is not, but both are closed now. Thank you.
oh well, Maciej. I am yet not sure if it makes really sense to explain the reason for closing it since at our last discusion I got the feeling it's your intention to do chat with me at the report rather then trying to exchange arguments and I normally use irc for chatting rather then bugzilla cause it's just much more efficient just like I normally don't use irc to report bugs. Anyway; > context menu in locked and unlocked mode differs Just like the context menu between right-click at a tar.gz (has the items "Open with Ark" and "Extract...") and a directory (has the item "Compress...") differs (and *please* don't create a bugreport for this!). That's btw why they are named *context* menu since the deal with the context. See http://en.wikipedia.org/wiki/Context_menu "The term context menu (or contextual menu, shortcut menu) is commonly used for menus which pop up when clicking an item in a graphical user interface, offering a list of options which vary depending on the context of the action, the application running, and the item selected." Everything else once we chat at a medium that is made for such kind of talks, thx :)
> > Just like the context menu between right-click at a tar.gz (has the > > items "Open with Ark" and "Extract...") and a directory The context is object, not situation! You should get the same context menu (items list) when you click on tar.gz in read-only mode and when write is possible. The same object, the same context menu. The same context menu for directory in read-only mode and write mode. Directory is another object so it is ok, the context menu changed (comparing to tar.gz). If you read explanation (and arguments) given by William you would notice the mentioned benefits. Currently both context menu are very similar, so similar then they are not really different context menu (as for .tar.gz vs. directory) but the same, with some hidden features. The point is, that disabling them instead of hiding gives user extra information, user sees the function is there, that nothing is missing. And the bottom line is, that this behaviour violates HIG, quote: " Menu items should not be added or removed during runtime. Disable or enable them instead. " I didn't wrote this, I just quote this, and I believe all KDE apps should follow HIG, do you agree with that? ( btw. reopening, since it is not a duplicate, those reports are related to context menu but have something different in mind ). > See http://en.wikipedia.org/wiki/Context_menu Good link. Look at the first image at that page. Yes, this is correct example of context menu, unavailable option is _disabled_ not _removed_. ( with IRC there is problem of synchronizing people and thus I avoid this, but if you would really prefer this, please let me know about the details )
" Menu items should not be added or removed during runtime. Disable or enable them instead. " is from the main-menu section which is != context-menu.
I know, the same applies to context menu. Look at the image I pointed out -- you don't remove "paste" you just disable it.
this isn't disabling actions, this is entering a "locked down" state. that's why it isn't a HIG violation, it was how it was also done in kde3 and there are indeed people who want exactly this behaviour as well (so even if you did manage to convince me that you are correct, i'd just end up with other bug reports ;)
> this isn't disabling actions, this is entering a "locked down" state. Right, but the object is still the same -- desktop. > it was how it was also done in kde3 Not true. I just clicked on desktop -- desktop currently is in "non-undoable" state, yet "undo" entry is not hidden, it is just disabled. Those entries disabled/enabled are _exactly_ that for -- to reflect the _state_ of the object. If something is not available -- disable it, if it is --> enable it. This UI behaviour is well established now, so please do not reinvent things. > there are indeed people who want exactly this behaviour as well If they are I would like to hear the arguments. Till now I heard just one. And there are much more arguments in favor of this wish -- William provided nice use case for it and it is convincing (at least me, because I also had feeling "something is missing"). I could add examples of context menu and states but you can check it by yourself -- try it in KMail, Konqueror, you name. __NONE__ changes its context menu entries list depending of the state, only depending of the object. And this is correct UI.
"Not true." please don't argue with me about code i wrote. "desktop currently is in "non-undoable" state, yet "undo" entry is not hidden, it is just disabled." that is an example of an action being available, but inactive. as i already stated, what we're talking about here is not an example of that, but rather of entering a locked down state where the action is actually unavailable. "__NONE__ changes its context menu entries list depending of the state" from konq_popupmenu.cpp in libkonq: if (KAuthorized::authorizeKAction("bookmarks")) q->addAction( act ); that's one example of dozens. there's 8 or so in libkonq itself. if you're interested, read up on the kiosk framework and look for uses of KAuthorized on lxr.kde.org (there are other means of using kiosk, but that one's easy to find). in any case, this is a WONTFIX. you may continue discussing it with yourself if you wish.
Joel goes even further: http://www.joelonsoftware.com/items/2008/07/01.html " A long time ago, it became fashionable, even recommended, to disable menu items when they could not be used. Don't do this. Users see the disabled menu item that they want to click on, and are left entirely without a clue of what they are supposed to do to get the menu item to work. Instead, leave the menu item enabled. If there's some reason you can't complete the action, the menu item can display a message telling the user why. "