<div dir="ltr">On 29 May 2013 23:07, Albert Astals Cid <span dir="ltr"><<a href="mailto:aacid@kde.org" target="_blank">aacid@kde.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
El Dilluns, 20 de maig de 2013, a les 21:26:07, Shaheed Haque va escriure:<br>
> HI,<br>
<br>
Hi<br>
<div><div class="h5"><br>
><br>
> Over in Kate's mailing list (<br>
> <a href="http://lists.kde.org/?l=kwrite-devel&m=136804130419019&w=2" target="_blank">http://lists.kde.org/?l=kwrite-devel&m=136804130419019&w=2</a>) there is a<br>
> discussion about how to support the discovery of plugins written in Python.<br>
> Currently, this is done in a very Python-centric way using KStandardDirs to<br>
> find the plugins, and then docstrings within the .py files to load (for<br>
> example) the description of the module. One problem that has emerged from<br>
> this approach is that i18n of the docstring-based description strings is<br>
> problematic, and one possible option to deal with this is to use .desktop<br>
> files in the usual way.<br>
><br>
> First, note that the plugins written in Python don't plugin to Kate in the<br>
> normal sense of a KDE C++ plugin, but they themselves plugin into a<br>
> "hosting" plugin called Pate which *is* a normal KDE C++ plugin with a<br>
> .desktop file and all.<br>
><br>
> Second these Python plugins are intended to encourage user-hacking by<br>
> allowing a "search path" concept. So, if the system has the foo Python<br>
> plugin in these three places:<br>
><br>
> $HOME/.kde/share/apps/kate/pate          <<< my in-development plugin<br>
> versions<br>
> /usr/local/share/apps/kate/pate                <<< my locally installed<br>
> plugins<br>
> /usr/share/kde4/apps/kate/pate                <<< distro default<br>
> installation<br>
><br>
> then Pate will (a) load the user's version but also (b) show the user than<br>
> the other two versions exist, but have been overridden. The idea being that<br>
> user's get the notion that s/he can simply copy a system plugin to a<br>
> directory under $HOME and hack it.<br>
><br>
> I believe if I combined the current manual walking of the KStandardDirs<br>
> with KService, I could make this work, I wondered if KTrader might be used<br>
> to simplify things a bit. I've done some experiments with ktraderclient,<br>
> and think the following issues would have to be overcome:<br>
<br>
</div></div>There's no KTrader class anymore, do you mean KServiceTypeTrader?<br></blockquote><div><br></div><div style>I guess so.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
AFAIK (dfaure would be better to answer this) KServiceTypeTrader works<br>
directly on ksycoca which is already "set into stone" so no you can't modify<br>
the paths at your will from the program and I think it doesn't support<br>
returning the matches that where not selected-<br></blockquote><div><br></div><div style>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.</div>
<div style><br></div><div style>Thanks for the reply, Shaheed</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Cheers,<br>
  Albert<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> 1. Is there a location under $HOME where KTrader will look for desktop<br>
> files?<br>
> 2. Does KTrader support a search path, and if it does, can it return the<br>
> non-first hits?<br>
> 3. The DesktopEntryPath returned by KTrader is not a fully qualified path<br>
> (the docs for KService::desktopEntryPath() and KService::entryPath()<br>
> suggest this might be possible, but I cannot fathom how to trigger this<br>
> behaviour via KTrader)<br>
><br>
> Any ideas welcome!<br>
><br>
> Thanks, Shaheed<br>
</div></div></blockquote></div><br></div></div>