For the open/save dialogs' Open File Manager context menu item, this patch adopts KIO::highlightInFileManager() and modernizes the name to match current convention ("Open Containing Folder").
BUG: 392330
Details
Details
- Reviewers
broulik - Group Reviewers
Frameworks - Commits
- R241:05fe10da0034: Highlight selected items when showing parent folder from the open/save dialog
Deploy change and invoke the open dialog from Kate, then...
- Right-click on one or more items and select Open Containing Folder. See that items are highlighted in the window that opens.
- Right-click on the background (i.e. select nothing) and select Open Containing Folder. See that current folder is highlighted in the window that opens.
Diff Detail
Diff Detail
- Repository
- R241 KIO
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Comment Actions
Good idea.
How about folders? Perhaps we should use a different behavior for folders as you're imho more likely to want to open a folder in the file manager than look "where it is"
| src/filewidgets/kdiroperator.cpp | ||
|---|---|---|
| 666–671 | When no folder is selected, this does nothing. It should open the current folder instead, or change labels accordingly. "Open With $filemanager" vs "Open Containing Folder" | |
Comment Actions
Fix the case where nothing is selected (i.e. when the user right-clicks on the background)
Comment Actions
I kind of like the consistency here; you always know what "Open Containing Folder" will do: open the containing folder, no matter what the selected item may be. Since it's pre-selected in the window that opens, it's really easy to open it if it's a folder and view the contents; just hit the Return key immediately.
Comment Actions
Also, we have a request to add an Open action to the menu (https://bugs.kde.org/show_bug.cgi?id=392329), which would take care of the use case of wanting to directly open the folder. I plan to submit a patch for that, too.