DevHeads.net

KTrader and "search paths"

HI,

Over in Kate's mailing list (
<a href="http://lists.kde.org/?l=kwrite-devel&amp;m=136804130419019&amp;w=2" title="http://lists.kde.org/?l=kwrite-devel&amp;m=136804130419019&amp;w=2">http://lists.kde.org/?l=kwrite-devel&amp;m=136804130419019&amp;w=2</a>) 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:

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

Comments

Re: KTrader and "search paths"

By Albert Astals Cid at 05/29/2013 - 17:07

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

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-

Cheers,
Albert

Re: KTrader and "search paths"

By Shaheed Haque at 05/29/2013 - 17:33

I guess so.

Ack, that's pretty much what I thought. I guess I'll have to look into
using KService directly, and workaround the fully-qualified path issue
using my own directory search logic.

Thanks for the reply, Shaheed