Version: (using KDE KDE 3.1.3) Installed from: Unspecified Linux Compiler: gcc 3.3 OS: Linux I maintain PyKDE (Python bindings for KDE). I get requests from PyKDE users to be able to write panel applets in Python. Panel applets of course require not only a .so lib, but a .la lib, meaning Python programmers would have (pre Qt3.2.0) to go through autotools and libtool agony (not even qmake) to write a Python panel applet. The easier way is for me to write one (1) .so lib (with .la) that can identify which Python-based panel app should be loaded. In order to do that, the .desktop file would specify X-KDE-Library=pykpanelapplet for *every* PyKDE panel applet. To identify the Python applet to be run, I need another field (I like X-PyKDE-Script, but really don't care). The change I would like is that instead of the AppletInfo ctor assigning a random string to 'configFile', I'd like it to use the the value of the X-PyKDE-Script field as the configFile value. Then, anytime 'init' is called for my one (1) .so lib, I can tell which .desktop file requested the lib and which Python script should be loaded. I have everything else coded and mostly working. This seems a fairly simple change and shouldn't have any side effects or backwards compatibility problems. I don't believe it amounts to more than a dozen lines of code. I'll be happy to provide code if you like. Please let me know if you have any questions. Thanks Jim Bublitz
Of course only use X-PyKDE-Script value when present - otherwise default to current behavior. Jim
A more general solution to this problem would be to provide a .desktop key which, when present, can be used to initialize the KPanel library. I can see this being of enormous use to lots of different KDE bindings who would like to take advantage of scripted panel applets. Without breaking too much backward-compatibility (adding params, etc.), it might even do something as simple as put the value in the environment somewhere (is that cross-platform enough?).
yes, a patch would be great and i'd be willing to look it over... would this approach be extensible to other script language bindings? we should try and do so if possible...
just following up on this again, is there a patch forthcoming? is there still demand for this? i'm fine with adding way to pass in an additional bit of information to an applet lib. this doesn't need to be python specific, either. anyone?
> is there still demand for this? Well, as KDE is the only desktop environment I use, and python the only language I *whish* I could use, I've written a bunch of tools in python ; and in order to keep them quickly available, I'm used to launch then using ksystraycmd. Now, what would be the added value of writing a panel applet in python ? I think I'm missing the point...
Kicker is currently unmaintained, you can look to your distribution for help, however.