This is consistent with the HIG, and the 'Rename' entry in
the context menu already behaves like that.
Details
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
Diff Detail
- Repository
- R318 Dolphin
- Branch
- arc_hide_rename (branched from master)
- Lint
No Linters Available - Unit
No Unit Test Coverage - Build Status
Buildable 5137 Build 5155: arc lint + arc unit
Comment Actions
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?
Comment Actions
'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.
Comment Actions
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.
Comment Actions
Dolphin does this already. Might be an idea to only disable the Delete or Move to trash entry though. Not sure.