This is consistent with the HIG, and the 'Rename' entry in
the context menu already behaves like that.
Details
- Reviewers
ngraham - Group Reviewers
Dolphin VDG - Commits
- R318:1340e9854875: Show the Delete context menu entry even when disabled
Right click on /home. The context menu should contained
the 'Delete' entry, but it should be disabled.
Diff Detail
- Repository
- R318 Dolphin
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
From a Ux point of view Ui elements should be disabled instead of hidden if they are not available but the user expects them to be there. The "Rename" entry currently gets disabled. You think it makes more sense to hide it instead?
'Delete' and 'Rename' entries are in the same section, but one gets disabled when the other one is hidden. I think they should behave the same way.
But should we disable (but show) 'Delete' or hide 'Rename', I can fix the patch to go one way or the other.
I agree it is usually better to only disable an entry that is not available. One argument in favor of hiding is that lot of things are already disabled usually in that situation (Cutting, Create new), it makes the context menu a bit cluttered.
Yeah, we prefer to disable inapplicable menu items rather than hiding them. See https://hig.kde.org/components/navigation/menubar.html#appearance
My vote is to re-work this patch to do that instead.
Dolphin does this already. Might be an idea to only disable the Delete or Move to trash entry though. Not sure.