Bug 62859

Summary:	Feature request to enable panel applets written in Python
Product:	[Unmaintained] kicker	Reporter:	jbublitz
Component:	general	Assignee:	John Firebaugh <jfirebaugh>
Status:	RESOLVED UNMAINTAINED
Severity:	wishlist	CC:	baris, landrews, nicolas.girard
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Unlisted Binaries
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description jbublitz 2003-08-18 07:02:14 UTC

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

Comment 1 jbublitz 2003-08-18 07:04:30 UTC

Of course only use X-PyKDE-Script value when present - otherwise default to current 
behavior. 
 
Jim

Comment 2 Frederick Polgardy 2003-08-19 23:37:39 UTC

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?).

Comment 3 Aaron J. Seigo 2003-09-04 00:35:19 UTC

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

Comment 4 Aaron J. Seigo 2004-10-25 05:10:40 UTC

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?

Comment 5 Nicolas Girard 2005-02-24 18:04:04 UTC

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

Comment 6 A. Spehr 2009-05-23 04:36:16 UTC

Kicker is currently unmaintained, you can look to your distribution for help, however.