KTrader and "search paths"

Albert Astals Cid aacid at kde.org
Wed May 29 23:07:53 BST 2013

El Dilluns, 20 de maig de 2013, a les 21:26:07, Shaheed Haque va escriure:
> HI,


> Over in Kate's mailing list (
> http://lists.kde.org/?l=kwrite-devel&m=136804130419019&w=2) there is a
> discussion about how to support the discovery of plugins written in Python.
> Currently, this is done in a very Python-centric way using KStandardDirs to
> find the plugins, and then docstrings within the .py files to load (for
> example) the description of the module. One problem that has emerged from
> this approach is that i18n of the docstring-based description strings is
> problematic, and one possible option to deal with this is to use .desktop
> files in the usual way.
> First, note that the plugins written in Python don't plugin to Kate in the
> normal sense of a KDE C++ plugin, but they themselves plugin into a
> "hosting" plugin called Pate which *is* a normal KDE C++ plugin with a
> .desktop file and all.
> Second these Python plugins are intended to encourage user-hacking by
> allowing a "search path" concept. So, if the system has the foo Python
> plugin in these three places:
> $HOME/.kde/share/apps/kate/pate          <<< my in-development plugin
> versions
> /usr/local/share/apps/kate/pate                <<< my locally installed
> plugins
> /usr/share/kde4/apps/kate/pate                <<< distro default
> installation
> then Pate will (a) load the user's version but also (b) show the user than
> the other two versions exist, but have been overridden. The idea being that
> user's get the notion that s/he can simply copy a system plugin to a
> directory under $HOME and hack it.
> I believe if I combined the current manual walking of the KStandardDirs
> with KService, I could make this work, I wondered if KTrader might be used
> to simplify things a bit. I've done some experiments with ktraderclient,
> and think the following issues would have to be overcome:

There's no KTrader class anymore, do you mean KServiceTypeTrader?

AFAIK (dfaure would be better to answer this) KServiceTypeTrader works 
directly on ksycoca which is already "set into stone" so no you can't modify 
the paths at your will from the program and I think it doesn't support 
returning the matches that where not selected-


> 1. Is there a location under $HOME where KTrader will look for desktop
> files?
> 2. Does KTrader support a search path, and if it does, can it return the
> non-first hits?
> 3. The DesktopEntryPath returned by KTrader is not a fully qualified path
> (the docs for KService::desktopEntryPath() and KService::entryPath()
> suggest this might be possible, but I cannot fathom how to trigger this
> behaviour via KTrader)
> Any ideas welcome!
> Thanks, Shaheed

More information about the kde-core-devel mailing list