[Bug 165134] desktop context menu: disable menu entries, do not remove them (HIG violation)

[Maciej Pilichowski]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=165134         




------- Additional Comments From bluedzins wp pl  2008-06-29 08:34 -------
> 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.