SUMMARY There are instances when I'd really like to be able to do certain tasks more efficiently, things that could be done with a command line -- or a command line calling a script -- but I want those things to be done within a specific folder. Utilities like xbindkeys can be used to bind global shortcut keys to command lines, but those commands will always be executed in the same directory. Either in the home directory or wherever the command specifies. I think it would be a highly useful and extremely versatile tool to be able to bind commands to shortcut keys within Dolphin, where the command will be executed relative to the current directory that's open in the active Dolphin window. Or, if not shortcut keys, then perhaps custom toolbar buttons. (Of course, the option to do either/both of those would be great as well.) In my use-case, I'd use it for things like creating a new document (which Dolphin currently doesn't allow single-press shortcuts for), or for calling certain scripts that sort and filter the files within that folder. But that's just one use-case. This sort of thing potentially has a lot of unforeseen uses that could be different for every user savvy enough to set them up. Some other examples of what a user could create: - a button to call ffmpeg to easily batch-convert all media files in the current folder to their favorite format - a button to call an image editing script to batch resize images in the current folder - custom batch renaming scripts run on the current folder - calling rsync to automatically sync the current folder to a pre-specified destination - calling a housekeeping script that deletes all files in the folder older than a certain date - compile the contents of the current folder - calling an anti-virus program to scan the current folder - automatically opening one or more files in the folder, based on various criteria (such as quickly opening the most recently modified .blend file to resume work left unfinished) - one-press commands to compress or extract the contents of the current folder And probably a lot of other things I'm not thinking of at the moment, all of which could really help certain people who have to do those tasks frequently, greatly speeding up their workflow because you could make it so that any of these actions are done with a single click or key combination. You'd need a backend that takes these user-entered commands and executes them when called, and you'd need a frontend that gives the user settings for entering custom commands and assigning those to shortcut keys and/or custom toolbar buttons.
In the Dolphin settings there is a "Context Menu" category. There one can download new plugins and services which will then be available from the context menu and will act on the currently selected files or will act on the currently open folder. These actions can be user-defined and downloaded. There are tutorials for this online if you need anything specific. >Some other examples of what a user could create: Some of these indeed are already available for download there! About binding these to keyboard shortcuts: This is indeed not possible currently. There is a long-standing bug report with many duplicates for this. I don't have it at hand at the moment but it shouldn't be too hard to find it. It might make sense to mark this bug report here as a duplicate of that bug report if this is the only aspect missing to resolve this bug report.
Hmm... The only way I can find for doing so is: Configure Dolphin --> Context Menu --> Download New Services --> Download New Stuff window --> contribute your own --> open KDE store website --> create account on KDE store website --> confirm email on KDE store website --> log in to KDE store website --> click on user icon --> Add Product --> (go through a seemingly rather complicated process of setting up an addon there, which is *far* more complicated than it needs to be for just executing a single command for one user) --> back to Configure Dolphin --> Context Menu --> Download New Services (again) --> search for the service you just created --> download it While it may technically be possible to do things this way ... this process seems a bit unnecessarily convoluted if you're just trying to do something simple. And it seems to require making your new addon publicly available, which could be just cluttering the store with things so specific they're only relevant to you personally, or it could possibly even have privacy concerns, if the command you need to run includes private information. That seems far from ideal to me. It's a reasonable process for adding a new Plasma widget or desktop theme, sure ... but far too complicated to just get Dolphin to execute a console command. It would be much nicer and simpler to have one of those list items in the Context Menu settings be "Run Command:" with a text box or popup or something to enter your command into. (And a new blank "Run Command:" entry added afterward.)
(In reply to ocalhoun from comment #2) > Hmm... The only way I can find for doing so is: > > […] > > While it may technically be possible to do things this way ... this process > seems a bit unnecessarily convoluted if you're just trying to do something > simple. And it seems to require making your new addon publicly available, > which could be just cluttering the store with things so specific they're > only relevant to you personally, or it could possibly even have privacy > concerns, if the command you need to run includes private information. > > That seems far from ideal to me. It's a reasonable process for adding a new > Plasma widget or desktop theme, sure ... but far too complicated to just get > Dolphin to execute a console command. It is way easier than that and you don't need to upload anything. Here is the guide: https://develop.kde.org/docs/apps/dolphin/service-menus/ One only needs to create a file with a specific format in a local folder and then one can execute custom commands from the Dolphin context menu. > It would be much nicer and simpler to have one of those list items in the > Context Menu settings be "Run Command:" with a text box or popup or > something to enter your command into. (And a new blank "Run Command:" entry > added afterward.) This is not exactly what you are asking for, but the upcoming release (I think in August?) will have a feature so one can set a custom command for double-clicking the view (https://invent.kde.org/system/dolphin/-/merge_requests/764). Generally speaking though, the way of creating service menus as described in the guide I linked is the better way currently. However, there is actually a service menu for creating service menus in the store page: https://store.kde.org/p/1952905/ I haven't tested it, but it seems to allow creating service menus for custom scripts very easily.
> This is not exactly what you are asking for, but the upcoming release (I > think in August?) will have a feature so one can set a custom command for > double-clicking the view > (https://invent.kde.org/system/dolphin/-/merge_requests/764). Heh, yeah -- that's pretty much exactly what I was asking for. Double-clicking the view is kind of a weird way to activate it (as opposed to shortcut keys or a button) but it would work. Since that feature already gets it 90% of the way there, maybe buttons/shortcuts for that could be implemented later? At any rate, I'd be fine with closing this feature request now if you want to, since that feature is already so close to it.
> Heh, yeah -- that's pretty much exactly what I was asking for. Great! > Since that feature already gets it 90% of the way there, maybe > buttons/shortcuts for that could be implemented later? Well, that feature is specifically about what to do when double-clicking the view. For the other custom service menus I linked a guide to there is indeed a long-standing bug report with many duplicates to allow users to bind those custom commands to keyboard shortcuts. I hope some contributor will find the time to work on this but it might be tricky to implement, so it might take a while for this to happen. > At any rate, I'd be > fine with closing this feature request now if you want to, since that > feature is already so close to it. Yes, let's close this then. It would be confusing to keep a bug report around that is already 90% done, instead of having new bug reports that are very specific about what still doesn't work as expected.