This patch adds an Open menu item to the open/save dialogs' context menu.
FEATURE: 392329
Details
Details
- Reviewers
- None
- Group Reviewers
Dolphin Frameworks
I am not 100% sure about this feature. The bug report requested the feature for previewing files, but maybe the deeper issue is discoverability and usability of the inline and aside previews? This patch is offered as much for discussion as to implement the feature and close the bug, but it does essentially work:
- Right-click on a file → Open -> Opens the file in the default app for it
- Right-click on a folder → Open -> Opens the folder
- Right-click on the background → Open -> Opens the parent folder
- One issue is that if the item opens in the very same app that invoked the open/save dialog, the resulting window can't actually be interacted with or closed because the dialog is modal.
Diff Detail
Diff Detail
- Repository
- R241 KIO
- Branch
- add-open-to-context-menu (branched from master)
- Lint
No Linters Available - Unit
No Unit Test Coverage
Comment Actions
Shouldn't this be using the "Open With" menu? If I'm in the Open dialog for Kate and click "Open" for a text file, it will just open in a new Kate instance (rather than opening in the application the dialog belongs to as I would expect from naming)
Comment Actions
TBH I'm not convinced that's something which should be added. That's a pretty weird workflow in general, and the bug reporter's use case of selecting a file in a web browser for upload essentially wants the existing F11 preview feature and perhaps a better preview feature in the web application itself. Also note that you could just drag-and-drop the file onto Dolphin, which should then open the default app, or onto Gwenview's launcher etc.
My concern is that the naming as well as the concept itself clashes with the regular Open button while doing something different. Also, this recursive opening thing has all sorts of issues. Instead of cluttering the context menu with more entries, going the extra step via Open Containing Folder is good enough IMO.
Maybe I'll change my mind if you can come up with a very compelling use case which is so great it's worth living with the disadvantages. For now my (i.e. take this with a grain of salt) recommendation would be to not add this.
Instead of adding Open buttons everywhere, a more elegant and generic approach would perhaps be to tackle this from a Plasma angle: Currently we have KRunner for typing things and Klipper's actions for (automatically) acting on content added to the clipboard. I could imagine a dynamically opening Plasmoid tailored for drag-and-drop operations could complement this nicely, e.g. upon initiating a drag operation it could present various drop targets like opening in apps, deletion, quick-preview, adding to the stash, tagging, user-configurable scripts, access to Dolphin's mimetype-specific actions etc.
Another (less exciting) idea would be to add what this patch does to the preview itself, which currently has no buttons and no context menu.
Comment Actions
Yeah, I wasn't convinced either.
One thing I realize is that when we turned on previews by default in Dolphin, we didn't do so in the open/save dialogs. So that might be low-hanging fruit to improve discoverability of file previews in those dialogs.
Comment Actions
The inline preview only gives thumbnails which are not usable when one wants to read text on the image (zoom to 100%). For me, the preview should take place before it is uploaded to the web application because I want to make sure the right thing is uploaded.
Also note that you could just drag-and-drop the file onto Dolphin, which should then open the default app, or onto Gwenview's launcher etc.
Interesting. Thanks for the hint.
My concern is that the naming as well as the concept itself clashes with the regular Open button while doing something different.
+1. If the function is added, it should be named Open with... to not be confused with the Open button.
Maybe I'll change my mind if you can come up with a very compelling use case which is so great it's worth living with the disadvantages. For now my (i.e. take this with a grain of salt) recommendation would be to not add this.
I come from Windows where the Open item is also available. Not having it feels like a lack of flexibility. I think having it in the context menu will not affect the "normal" user. Your proposed workaround with "Open containing Folder" -> Press Enter is certainly ok.
Comment Actions
Coming from the Mac world, they have an even better solution: you can invoke the Quick Look preview from open/save dialogs. So you just select the item, hit space bar, and you get a huge preview that you can even make full screen if you'd like. Hit space bar (or escape, or hit the close button) to close it again. It's super useful and super elegant.
At some point in the Plasma 4 days, we had something similar in the form of KLook. Alas, it broke with the 4 -> 5 transition and I have not been able to find anyone willing to become a new maintainer. See https://bugs.kde.org/show_bug.cgi?id=272539
That would be a really killer solution IMHO, if we could find someone willing to resurrect it.
Comment Actions
After thinking about this for a few weeks, I can't imagine and haven't seen a use case for using the Open File dialog to open the file in a different app that wouldn't be better served in another way.