Closed renyuneyun closed 6 years ago
renyuneyun
commented
6 years ago By the way, I'm willing to help, but I have no experience with krunner (well, also no experience with ruby...). What's the basics of developing krunner plugins?
p.s. I'm also archlinux user, and hope to see this package on aur :)
XanClic
commented
6 years ago Hi,
As far as I know (and I don't know much there, actually) there are two ways of writing krunner plugins. The usual way is to write a C++ (maybe also other languages) plugin that is linked directly to krunner (dynamically, I guess) – in this case you don't need to run a daemon because the plugin is loaded when krunner is started. I didn't go that way mostly because (as far as I remember) I didn't find enough documentation on how to do all of that exactly (like, where can I get the development headers, how do I link everything against krunner, etc.).
So the other way to write krunner plugins (which was added only rather recently) is to write a DBus service. krunner will look for .desktop files in the kservices directory which describe which services it's supposed to look for. I suppose the .desktop files that contain X-Plasma-DBusRunner-{Service,Path} keys are the ones that match. Once it has found such services, it can talk to them. However, as they are separate processes they need to be started first. So my solution was to keep this plugin always running in the background, because I haven't yet found out how to make krunner start it – I actually don't know if you can do that at all. But then again, so far I haven't invested time in it at all...
Judging from some other .desktop files in the kservices directory, there are an Exec and an X-DBUS-StartupType key, maybe I can something with those. But even then, I'd actually rather have this service always running in the background than have krunner start it up every time I press a key in krunner (because that is basically how often all plugins are queried)… Maybe there's a way to allow both ways so the user can choose just by changing the X-DBUS-StartupType value in the .desktop file?
Anyway, I'll have a look. About the AUR… Well, I haven't put anything into it yet, so maybe this is the time to learn how to do so. But in any case, I suppose I'll have to figure out how to make KDE/krunner start the plugin service automatically without relying on the usual KDE autostart mechanism first.
Thank you for your interest! :-)
XanClic
commented
6 years ago As of commit b9ded33ffa0ac7145eea3d7007ac966ce0786ddf, krunner should launch the plugin automatically. I haven’t yet investigated whether it’s possible to not keep it in the background and instead always exit once a result has been returned (and then be reloaded once another query comes in), though. But again, I’m not sure whether that's actually a good idea in the first place… So I guess I’m closing this issue for now…?
XanClic
commented
6 years ago Oh, and by the way, apart from the MPD and the DBus connection, the plugin actually is stateless (regarding the code). So it’s only a matter of exiting every time a response has been sent and modifying the .desktop file (and maybe the .service file?) to make krunner launch the service every time it’s needed. I guess I’ll open a separate issue for that and probably look into that later (as a configure option).
I'm looking for a krunner plugin which can control mpd (without launching a GUI), and find this one.
The description says I need to launch a ruby program (as a daemon in fact) in order to make this plugin work. But why is there a need for a daemon...? Shouldn't this intend to be only "controlling" the mpd, rather than "reporting" it, which means it doesn't need to be stateful (i.e. it should be stateless)?