KTrader and "search paths"

[Shaheed Haque]

On 29 May 2013 23:07, Albert Astals Cid <aacid at kde.org> wrote:

> El Dilluns, 20 de maig de 2013, a les 21:26:07, Shaheed Haque va escriure:
> > HI,
>
> 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?
>

I guess so.


> 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-
>

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



> Cheers,
>   Albert
>
> >
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20130529/b805c60e/attachment.htm>