<div dir="ltr">HI,<div><br></div><div style>Over in Kate's mailing list (<a href="http://lists.kde.org/?l=kwrite-devel&m=136804130419019&w=2">http://lists.kde.org/?l=kwrite-devel&m=136804130419019&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.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>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:</div><div style>
<br></div><div style>$HOME/.kde/share/apps/kate/pate          <<< my in-development plugin versions<br></div><div>/usr/local/share/apps/kate/pate                <<< my locally installed plugins</div><div>
/usr/share/kde4/apps/kate/pate                <<< distro default installation</div><div><br></div><div>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.<br>
</div><div><br></div><div>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:<br>
</div><div><br></div><div style>1. Is there a location under $HOME where KTrader will look for desktop files?</div><div style>2. Does KTrader support a search path, and if it does, can it return the non-first hits?</div><div style>
3. The DesktopEntryPath returned by KTrader is not a fully qualified path (the do<font face="arial, helvetica, sans-serif">cs for KService::desktopEntryPath() and KService::entryPath() suggest this might be possible, but I cannot fathom how to trigger this behaviour via KTrader)</font></div>
<div style><br></div><div style>Any ideas welcome!</div><div style><br></div><div style>Thanks, Shaheed</div><div style><br></div></div>