Kate D-Bus Interfaces, used at all?

I just started to clean up the content of kate.git, moving things around, fixing compile warnings and similar stuff.

I stumbled over warnings in our dbus interfaces.

The main use of them is to allow Kate to reuse an existing instance for opening files and sessions. This part (e.g. the interface of the application object itself) works fine and is needed.

But all other interfaces, like the ones for docmanager, mainwindows, … are mostly non-existant or not implemented. I now play with the idea of just removing the nearly empty skeleton implementations, as it seems nobody missed them during the complete 4.x series.

Is there somebody out there that actually uses them and if, how?

4 thoughts on “Kate D-Bus Interfaces, used at all?”

  1. Well, do I use them _now_, no, but I use the same window manager as sven (AwesomeWM, see his video) and it offer powerful APIs to integrate applications deeper into it. I already use that for some apps, but as you said, Kate ones are umm, incomplete, but I must say I did not try harder than looking at qdbusviewer for the session stuff and ended up just parsing ~/.kde/share/apps/kate/sessions and using X11 clues for guessing the current session.

    As for removing them, my opinion is that it doesn’t have to be part of the core, but should be a plugin at some point. I guess I am probably one of the only one who use dbus to control his app, so while there is a valid use case, there is probably not the critical mass for fixing it now. If I want it back, making a small IPC plugin may be enough.

  2. I’m not necessarily advocating strongly one way or the other, but…

    At work, for complicated reasons, I am still stuck with KDE3’s Kate. There, to have *some* kind of integration with ID file support, i.e. a crude version of the new Python ID plugin, I use the old DCOP (!) interfaces to be able to (a) open a document and (b) navigate to a given line/column position.

    So, a bit like @elv13, the ability to integrate with Kate from “outside” was a valuable facility.

  3. KRemoteControl offers the possibility to browse and control all existing D-Bus interfaces. When I had to do a lot of presentations during University, I used them to open documents and browse through them via an IR remote control. This probably isn’t a very common use case but still one thing I was proud of KDE supporting it.

    I agree that having broken and non implemented interfaces is worse than don’t having them at all, so don’t have a strong opinion on removing some from Kate. Just wanted to show you one more point of view when thinking about D-Bus interfaces.

  4. Seems like the consensus is to remove the cruft, and implement it as a plugin when someone wants it enough to do the work. Perhaps it would be worth moving the code into a skeleton unimplemented and unbuilt plugin, then doing a git rm, so that someone who does later want to get it going, has something to start from.

    A plugin can always be reintegrated once it’s working cleanly with new kate codebase.

Leave a Reply