[PyKDE] Status of panel applets?

[Jim Bublitz]

On Friday 27 August 2004 12:35, Maurizio Colucci wrote:

> On Monday 21 June 2004 23:11, Jim Bublitz wrote:
> > On Monday 21 June 2004 22:07, Maurizio Colucci wrote:
> > > Can I write a kicker applet completely in PyKDE? If so, could you
> > > please give me some hint how to do it? (e.g., where do I put the init()
> > > function, where do I copy the .py file, how do I cope with the
> > > requirement of having a .la file...).

> > > If I can't, what is the least amount of C++ code I have to write?

> > The status of panel applet support is a little murky at the moment. It
> > was included in PyKDE-3.8, but removed from PyKDE-3.11 (and you don't
> > want to go back to 3.8). It will eventually be part of an addon package
> > separate from PyKDE (but requiring PyKDE), but the people (including me)
> > doing the development haven't worked out the details yet.

> > I have working code (including installation) and could probably send you
> > something if you're in a real hurry (let me know). Otherwise, a general
> > release is probably a month or more away (probably "more"). It requires
> > sip 4.0, which is available in rc form now and final release soon.

> This was two months ago. :-)

> What is the current status of panel applets?

That's a good question. Between David, Simon and myself, none of us has really 
taken charge of getting panel applets (and related stuff like KParts, 
IOSlaves,  Control Center modules) packaged up. I know I simply haven't had 
time to get back to it, and I suspect that's the case with David and Simon 
too.

The last time I did anything with it (sometime in spring), panel applets were 
working fine but I never got to testing the other related stuff.  I think all 
of the problems with the Python interpreter (basically embedding it) are 
resolved with sip 4, although that needs to be tested too. 

The only thing that wasn't working was the Python-based installer written for 
installing panel applets. Even that works except that it had a built-in 
applet test capability, which may not be easy to get working because of the 
way applets now expect to be called (from C++ with C++ pointers that they 
convert to Python instances from within Python - it's just a sip function 
call to do that).

There is a nice project here if someone wants to pull it all together, 
covering:

1. Panel applets and panel extensions (not sure about panel menus, but the 
other two are essentially done)

2. Writing KParts in Python (PyKDE already imports KParts)

3. IOSlaves written in Python

4. Control Center Modules written in Python

5. Qt Designer plugins in Python

The common element to all of these is that it involves embedding Python code 
in C++ apps in more or less the same way (some variations), and it makes 
sense to have a consistent approach.

Most of the basic work is done - it just needs to be pulled together with 
things like installation and some tools for installing applets/KParts/etc. to 
make it easier for people to use, code cleanup, docs, etc.  The one problem 
area is Qt Designer - one of the things that should be possible is to make 
widgets written in Python available to Qt Designer. Even most of that worked 
(I think), but there was a problem with having to load the Python interpreter 
a second time (once for the plugin, once to execute the widget the plugin 
loaded). I don't think that's a big problem any more either, but haven't 
tried it in a long time.

If someone wants to take the lead on this (and I hope someone does), it would 
help if they'd speak up (if only so we have someone to bitch at :) ). I'll be 
happy to provide assistance, latest code, whatever, as I'm sure David and 
Simon would. Otherwise, I'll get to it eventually, but I'm pretty busy at the 
moment and PyKDE is my priority.

There are some good reasons why I don't want this to be part of PyKDE - 
basically problems with changes between sip3 and sip4 and that it makes PyKDE 
building/installation more complicated.

> > Basically, the panel applet/extension (about the same for both) interface
> > uses a single C++ lib to handle all instances of Python-based applets or
> > extensions - you just need to install this, along with libpythonize.so,
> > which is a very simple wrapper for the Python interpreter. You don't need
> > to write any C++.
> >
> > There is an appletInstall.py application (needs some cleanup, but
> > working) which will simplify installing Python-based panel applets.
> > Assume you write someApplet.py: In someApplet.py, you need a factory
> > function
> > ("createApplet" - the code is pretty much the same for all cases) and a
> > class sub-classed from KPanelApplet that actually implements your applet.
> > What the installer does is:
> >
> > 1. Creates a .desktop file that references "libsomeApplet.so" and places
> > it in the share/apps/kicker/applets directory along with your Python
> > file.

> Shouldn't I be able to write (part of) the .desktop file?
> .desktop files usually contain important informations (icons, K-menu
> entries, Actions...)

Yes, you can write your own (and in fact the installer allows for that 
possibility). It's just easer for some people to have it done automatically.

> > 2. Creates a symlink in the appropriate directory from libsomeApplet.so
> > to libpykpanelapplet.so (the single applet interface lib)
> >
> > 3. Creates a fake libsomeApplet.la file in the approprieate directory
> >
> > (The installer does some file renaming too - your file will be installed
> > as someApplet_py_applet.py - not usually a big deal).
> >
> > When kicker reads the .desktop file, it loads libpykpanelapplet (via the
> > symlinked name and fake .la file). libpykpanelapplet has the required
> > 'init' function which loads the Python interpreter supplied in the
> > libpythonize.so lib (if not already loaded), loads the requested Python
> > applet script into the interpreter, runs the factory function and returns
> > a KPanelApplet * for your applet back to kicker. sip handles all of the
> > Python<=>C++ conversions (in the createApplet function, which you can
> > mostly just cut and paste).
> >
> > Because of the way Python<=>C++ conversions are now handled, applets may
> > be a little more difficult to debug - I still have to look into that.

> In C++ I find the program "appletproxy" very useful. It is a must for
> debugging. Essentially you run

>  appletproxy /usr/share/kicker/applets/mydesktopfile.desktop

> and you see your applet in a window, and this time you can see the stdout
> of your applet.

appletproxy (there's a complimentary program for panel extensions too) is 
definitely a big help, but it's still difficult to debug applets. The problem 
is that the way the lib/loader is now written, the applet expects to get a 
C++ instance pointer/return a C++ instance pointer, whereas before that was 
done with PyObjects. That means it's difficult to actually test the applet 
from Python, which was easy before. 

That's all mostly transparent to the programmer - you just need to call 
'sipwrapinstance' and 'sipunwrapinstance' in the right places within the 
applet script. Overall it's a much better solution - it just makes debugging 
a little harder.

Jim