[PyKDE] KDE Panel Applets in Python

[Jim Bublitz]

On 11-Apr-03 Ricardo Javier Cardenes Medina wrote:
> On Thu, Apr 10, 2003 at 10:44:19AM -0700, Jim Bublitz wrote:
>> 'parent' doesn't contain any useful info (for loading).
>> 'configFile'
>> contains the applet name (eg 'khelloworldapplet plus some
>> garbage
>> plus '_rc' for one of the example applets), but it forms the
>> value
>> of configFile from the lib name. If you name the lib
>> "libXXXapplet.so" in the .desktop file, configFile ==
>> XXXappletzzzzz_rc, even if the desktop file is "YYYapplet". The
>> only possibility is if there's a way to specify an arbitrary
>> name
>> for the config file in the .desktop file, but I didn't find one.
>> The way it looks, every applet needs a distinct lib name. 
>> 
>> There is one other possibility - create a single lib that puts
>> "Python applet" in the Add | Applet menu. In the factory
>> function
>> for that lib (init) popup another menu that lists the available
>> Python applets (ie - put the Python applets in
>> share/apps/kicker/applets with the rest of the desktop files,
>> then
>> have the Python applet loader scan there for *.py files. Seems
>> like
>> that should work - I haven't given it much thought though.
> 
> Another one... It seems that Kicker relies on the .la file that
> comes with every .so. If you don't have the .la, it won't even
> load the applet. 

Yes - KDE plugin loading in general does that.

> Given:
> 
>    libfooapplet.so
>    libfooapplet.la
>    libbarapplet.la -> libfooapplet.la
> 
> With libbarapplet.la being a link, and two .desktop files, one
> referring to libfooapplet and other to libbarapplet.
> 
> That works. You could have one "libpykdegenericapplet.{so,la}"
> installed, and have every Python applet provide one .desktop
> file, and then link libThisPyKDEapplet.la to
> libpykdegenericapplet.la.
> 
> Not so clean (ye gods! it's a kludge), but works (and saves disk
> space) :-)

Lemme think about this ...

kicker will see libbarapplet, so it will load libbarapplet.la which
is in fact the link. It will call libfooapplet::init with 'parent'
and configfile == barapplet<hash>_rc, so in some way libfooapplet
will be able to figure out that barapplet is to be loaded (as a
Python script). Should work. I thought about links but for some
reason thought there was more kludginess that was going to be
involved (offhand I can't think of what that was at the moment). An
installer can make that all transparent to the end user.

The only other thing needed would be some kind of applet
"registration" so the Py applet loader can recognize valid names
using the equivalent of 'startswith', although requiring the applet
py script name == applet lib name would probably take care of that.
There's a possiblility of name conflicts with that scheme, but it's
probably manageable (like having the installer report a conflict).

I like this because I don't have to write as much C++ :) It's also
more in line with the requirements of similar plugin stuff so it
leads to a more general solution (or at least a common base class).

Jim