I was writing a custom quickview app in python to use it in Dolphin and had trouble passing the selected file paths in Dolphin to my app. Searched the web, turned out others have tried it but since Dolphin does not support adding keyboard shortcuts to service menu actions, all solutions are very hacky (xdotool, ydotool, etc). Looked at the KDE bugtracking forum, turned out it’s been a decade since the first request (https://bugs.kde.org/show_bug.cgi?id=260266).
Since I am a python guy, I used LLMs to communicate with the Dolphin repo, and it looked like most of the functionality for this feature is already there. The LLM developed most of it, with lots of issues, but after a couple rounds it looks good to me. It works with no issues in the last couple of days I’ve been using it.
Now my question is, is there a particular (security?) reason, why this feature has not been implemented yet? If not, then I would go ahead and trying pushing it.
Don’t open a MR if you don’t understand the code generated. “It works for me” is not sufficient, and will make reviewing this a nightmare most likely.
This feature will need to be implemented partly in KIO i.e outside of dolphin code base.
To parse the shortcuts. Then the shortcut must be checked for duplication.
The service menus must be loaded on dolphin start, whereas currently they are loaded when the context menu opens. You need to be able to change the shortcuts and save the shortcut defined…
Still the code generated could be a draft or a starting point, but it rests on the contributors author to meet quality standards and understand what they do.
There should be some care regarding shortcuts definition: we don’t want a random service menu shortcut to be a way to launch some adversarial code when a simple key is pressed.
what i’m hearing is that it would not be as simple as adding a key=value pair to the service menu because it might conflict with pre-existing shortcuts, and there would be no easy way to check for that or configure that from inside dolphin.
but could the shortcut settings in plasma be changed to offer up service menus ala the + Add Application... button?
i tried using the + Add Command... button to run the exactly same code as the exec= value in one of my service menus but it does not parse the item selected in dolphin or on the desktop so service menu variables like %f or %F don’t get resolved.
what’s needed is a + Add Service Menu... button that would somehow find out what dolphin thinks is selected.
i know this has been asked before about some external way to access what is selected in dolphin, but here is another example of where exposing that could be useful.
this is making sense to me now, so ignore my suggestions about global shortcuts or exposing dolphin selections outside dolphin …
when looking at the dolphin shortcut settings, they appear to only be for the built in dolphin features and there appears no way to add to the list of things that can have shortcuts defined for them, even tho you can add service menus to dolphin elsewhere in settings.
would it then be possible to list the checked service menu items that are active in the context menu as show by this settings page
to list them here in the shortcut setting in a new section so that each could have a shortcut assigned and dolphin would be in charge of resolving conflicts.
I see. This is my first serious C++ MR, not the first MR in general, so I understand it’s my responsibility to meet the quality standards. I understand my MR, but since I have very little experience in C++ code bases, let alone in a big existing one, I expect some (hopefully not major) issues, which I believe I will be able to fix. I enjoy dolphin a lot more since I have this feature, so I am motivated to try this if encouraged.
You likely mean the mimeTypeListContains(). For my local usage I just copied it over since it is a static function, but I don’t see any reason why this shouldn’t be public. I assume the correct order would be to make it public in KIO then reuse it in this feature?
Shortcut duplication is handled by KActionCollection since I reuse it, so it’s being checked and the warning message pops up offering the user to reassign. In this context, adding a new field to the .desktop file is probably meaningful, which can be checked for conflicts when the files are scanned. In case of a conflict the user can be notified and the shortcut ignored.
The flow at the moment:
Dolphin starts → ServiceMenuShortcutManager parses all .desktop files
Actions registered with KActionCollection
User opens Settings → Keyboard Shortcuts → sees their action under “Service Menu Shortcuts” category
User assigns shortcut → KShortcutsEditor checks for conflicts as usual. If conflict, dialog appears → user resolves
Shortcut saved in dolphinui.rc
When the action is invoked, it’s validated in the ServiceMenuExecutor using MimeTypes and current selection(s). If it fails, the user gets notified. At the moment, the action is checked per file, so that if multiple files are selected and the action is valid for a subset of these files, then it still will be executed on this subset and the user will be notified that it failed for the rest.
I can elaborate with much more details, I am just not sure if this is the right place or should I just be abstract here and talk the details in an MR?
Honestly, this is where I would have to heavily rely on experience reviewers.
Ideally, This list of actions should be cached (i.e static), so that the parsing is not redone after the applications is started when the context menu is shown.
We could then have dynamic reload of settings when the folder ~/.local/share/kio/servicemenus/ changes to refresh the cached data.
And pay attention to not forget about KAbstractFileItemActionPlugin case.
Services menus are a dolphin-only feature, it can work outside of dolphin.
We might want to share those shortcuts settings.
I think we might want to silence it by default or at least add a “don’t repeat this dialog” checkbox/button.
That’s seems reasonable, although i am not entirely sure there isn’t a reason not to have a “all of nothing” type of behavior. We have KFileItemActionsPrivate::checkTypesMatch we can reuse.
We have KFileItemActionsPrivate::shouldDisplayServiceMenu to use to be consistent with the context menu after file filtering by mime-type.
This is nicely detailed.
I think you can open a Draft MR, the KIO modification should not be that big, mostly refactoring, your LLM could help there.
This also means Dolphin code changes will need some #ifdef depending on kio (i.e kde frameworks) version. KF_VERSION in the code.
Try to use git clang-format to make sure it matches our coding style, and when the LLM becomes verbose it probably means we can reuse some code from Qt/KIO/Dolphin.
Although that would depend on your LLM and I don’t have much experience with those, so I don’t know what to expect exactly but I am curious.
Thanks for the great feedback and useful info. Styling and docs noted, thanks.
Parsing
Yes.
Filtering plugins
Can you elaborate how plugins are related? I would think it’s out of scope for this discussion. I am also unsure what you mean by KAbstractFileItemActionPlugin case either. I see the abstract class, but cannot make the connection. You might have a bigger concept for this feature in mind than I.
Caching
In my implementation I do use caching, but you are suggesting one caching place, right? Just to clarify, we have two options, 1. reuse the actions scanning from KIO and cache in the ServiceMenuShortcutManager, and leave KIO as it is now or 2. unified solution: Add caching in KIO, since it is useful for both context menu and ServiceMenuShortcutManager. And the cache should be updated using KDirWatch and KConfigWatcher, correct?
Sharing settings
Can you elaborate? Did you mean Service menus are NOT dolphin-only feature? And by sharing shortcut settings you mean we should save the settings in a shared place so that other apps say gwenview also uses those?
Compatibility
I assumed I need to enable this feature only for the updated KIO API. If you think it should also support the old KIO API, then code duplication is, imo, is unavoidable (at least mimeTypeListContains()). Do I have to support updated and old KIO in one go or can I add and enable this feature only for the updated KIO API and then push a separate MR to support old KIO versions?
Related to MRs, do I need to group 2 MRs, one for KIO and one for Dolphin, so the devs can see the whole picture, or do I start with KIO MR and move to Dolphin after the MR for KIO is merged? If I were a reviewer, I would prefer the latter, but I would go by convention.
LLM usage
In this code base the LLM serves mostly as translation/reminder/explainer layer between me and C++ lines. When I asked it to implement this feature without giving it design and proper supervision, it did a poor job (no reusing functionality, ~30% dead code, unnecessary for-loops, dirty hacks, etc). But it still enables me to go much faster when I give it a design and supervision, and tbf, it does suggest very good ideas sometimes I would not think of, because its shallow general understanding is vast and it does dozens of web and tool calling in the code base. I would strongly recommend an agentic framework, otherwise it will waste your time instead of saving it. Let me know if you want to hear more.
I was saying ideally, caching would be shared in KIO, but doing it in dolphin is fine too.
Parsing and filter the enabled actions must be done in KIO, otherwise that’s just tech-debt.
Then ServiceMenuShortcutManager can do the caching or not be needed at all if caching is in KIO.
If KIO does the caching it could optionally do the file watching.
Sharing settings
I meant service menus are not a dolphin only feature (the not got forgotten).
The shortcuts could be stored in dolphin settings or shared, both would be acceptable.
The sharing of the shortcut could be done later, meaning for now this can be stored in dolphinrc
Compatiblity
Absolutely.
No need to have some support for older versions. That’s a new feature that can only be added at the earliest in 26.04 (in April) in a few months, we have time to get the needed changes released in KIO by now so dolphin can depend on a new KIO version.
Only support in updated KIO version, no need to have the feature implemented for dolphin with older KIO, which would be more work and less good.
Merge requests
You can open the KIO merge request first, just explain briefly your future use case (link this conversation).
Chances are, you will have time to open the dolphin MR before the KIO MR is finished and merged. I say that by experience, new contributors often learn a lot during the review and hence this can take a while.
Rest assured as long as you manage to not have painfully hard to review code, I will be helping. That’s one of the two most requested feature for dolphin AFAICT.
LLM
LLM can help for sure.
I’d be curious to know what did you use. I’d like to have some local one personally.
Concerning the plugins, do you think this feature need to be implemented for both file based and plugin based service menus in one go? If so, why? If not, then I would rather do it in 2 steps.
Thanks a lot for the help, and I promise, I will do my best to make it a clean MR.
Off topic
LLMs: I think the fastest and probably the best way to try it out would be opencode. Very easy to install and run, since they offer free models. Obviously they collect data, but AFAIK no other agentic framework offers such LLMs like GLM 4.7 for free. You will quickly learn that you will need additional scaffolding to minimize the slop, especially on bigger projects. Although opencode does already a lot, I found plugins like conductor2 are really helpful since it sets high quality workflow, otherwise you end up with a spaghetti not only in the code but also in your git history.
Local vs cloud: I am a local fan, but unfortunately got very limited VRAM so cannot run big models and the small ones still make too many mistakes in coding. Some folks at r/localllama have 4x3090 or even more, so they run quantized big models like GLM 4.7 or even DeepSeek 3.2 locally, which of course lag behind the absolute best and most expensive closed models behind APIs, but not by much. That being said, smaller models are advancing rapidly, every week/month there is a new SOTA model in this category. Just a few hours ago a distilled version of GLM 4.7 has been released, and in my first tests it is a big step in the agentic direction. You can absolutely run this locally at acceptable speeds. If the current trends continue, in a year we’ll be able to run a models locally that are as good as today’s best closed enormous models, so I would recommend starting today even if the current local models often fail.
Decompress file actions provided by ark and implemented with a plugin.
Users would expect to set shortcuts to any context menu entries including those.
We already have someone that asked for this specific case.
But handling .desktop service menus at first is fine.
It might not get through the review without plugin support though, I won’t be the only reviewer.
Yes, but this is taking longer than I planned, because I tried to implement the whole thing including plugin shortcut support (the hardest part for me), and it became too big, I got overwhelmed with too many decisions, and had to learn many aspects of KIO and Dolphin.
Now, I am breaking it into 3 parts, so the issues can be caught early on and I keep it on the right track from beginning. First MR would require some refactoring around moving stuff from KFileItemAction to Scanner, Executor and Utils. These then will be used for file based, plugin based and context menu actions, to avoid a lot of code duplication.
The caching will go into a struct like below, which will be common as well.
// Service-menu specific constraints
QStringList requiredProtocols;
QStringList mimeTypes;
int minUrls = 0;
// …
Today is over, and I have not enough time tomorrow, but hopefully will push the first draft MR in 2 days. This first MR will also include all major decisions for supporting file and plugin based shortcuts.
Loaded by KFileItemActionsPrivate::addServiceActionsTo you need to extract the part that loads those into a function, serviceMenuFilePaths loop in particular.
Then have something to have a QMap<Qstring, QKeySequence>, actionId to shortcut, save/loaded, this can be done in dolphin too.
