I've noticed there's two big classes of things I usually want to do with files: 1. Execute, view, or "open" it (example: view HTML in a web browser). 2. Edit it (which usually means opening it in a text or image editor). So I'd like to suggest a feature: each file type (including directories) should have both an "open" tool and an "edit" tool associated with it, and we have double-left-click open it (like now) while double-right-click edits it. (In some but not all cases, the two programs might be the same.) Examples of programs I might set as open/edit defaults: * Code files can be opened and executed as a program, or edited in VSCode. * Directories: view with Dolphin (so double-left-click on a desktop folder opens it), edit in VSCode (open it as a workspace). * Doc files: Probably set LibreOffice as both the open and edit program. * PDF: view in Okular, edit in LibreOffice. In short, I want to have some kind of "secondary action" that can be done with double-right-click (or triple-left-click, I'm not wedded to the details).
It's an interesting idea, but I'm not sure this would make sense, as it would: 1. …not be discoverable 2. …conflict with the normal right-click mechanics 3. …be a nightmare to implement universally everywhere 4. …not work outside of KDE apps For those reasons, I think the cons outweigh the pros, sorry. But thanks for the idea anyway!
(In reply to Nate Graham from comment #1) > It's an interesting idea, but I'm not sure this would make sense, as it > would: > 1. …not be discoverable > 2. …conflict with the normal right-click mechanics > 3. …be a nightmare to implement universally everywhere > 4. …not work outside of KDE apps I was actually going to suggest resolutions to these issues, but in an ironic twist, I learned there's already a very similar feature in KDE, it's just not discoverable! Apparently, middle-clicking text files will open them in KWrite instead of my default text editor. In addition to discoverability, the current implementation isn't configurable. (What if I don't want to use KWrite?) I'd suggest killing two birds with one stone by adding a second column to the "default apps" picker, which lets you set the secondary action (e.g. editor) for MIME types that happens on a middle-click.
It opens the file in the second item in the priority list for that file type — whatever it is. It's not hardcoded to be KWrite. You can edit this in priority list in System Settings > Default Applications > File Associations > find a file type > change the "Application Preference Order".
(In reply to Nate Graham from comment #3) > It opens the file in the second item in the priority list for that file type > — whatever it is. It's not hardcoded to be KWrite. You can edit this in > priority list in System Settings > Default Applications > File Associations > > find a file type > change the "Application Preference Order". Oh, thanks! In that case, I suppose I've run into three issues with the current implementation: 1. Looking at the file associations, editing them one-by-one seems unwieldy—there's way too many filetypes for me to set the correct secondary program for each one. 2. The connection between middle-clicking and being second in this list is hard to discover. 3. Middle-clicking a directory seems to be special-cased, which keeps me from mapping middle-click to opening the folder in VSCode. This could be solved either by having users open folders in a new tab with `ctrl+click` and making middle-click behave consistently,* or by allowing users to open the second option for either files or folders with something like `alt+(double) click`.