On 29 May 2013 23:07, Albert Astals Cid <[email protected]> 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 >
