[PyKDE] Panel Applets, KControl, Plugins, etc.

[Jim Bublitz]

There has been some discussion lately (and in the past) about 
things like panel applets, plugins, control center modules, 
ioslaves, themes, styles, etc. The "hangup" for most of this 
stuff is the need for a libtool .so lib to init/interface to the 
Python code for accomplishing the task. IO Slaves are probably 
somewhat different, but the rest of the list behaves pretty 
similarly (at least to the extent I've coded or investigated 
it).  It seems to me a good solution would be to build a single 
.so framework that enables all of these to be scripted in 
Python.

The primary requirements (IMO) are:

1. An .so that can load as a plugin (apps like kicker or kspread 
know how/where to look for these - usually via an .rc file) to 
init and communicate with the scripting interface. For example, 
for a panel applet you need to:

  a. Get kicker to recognize your plugin (which will locate and 
enumerate the available .py scripts and add them to the kicker 
menu)

  b. Have a menu click load and execute your applet script

2. An .so that also loads as a plugin, but is loaded by (1) and 
contains the Python interpreter (.so or .a) and means to allow 
(1) to load/execute scripts and return results.

(1) may not be completely generalizable (panel applets might 
require different methods than styles at some level, although 
locating/enumerating might be the same in every case); (2) 
should be common to just about everything.

Beyond that, it would be nice if there were a 
build/Makefile/install mechanism to simplify putting all of the 
libs and .rc files in the right places (usually somewhere in 
share/apps for the .rc files). Also, keep security in mind - you 
probably don't want this to execute scripts as promiscuously as 
something like Outlook. Requiring scripts to reside in the 
kde/share/apps hierarchy (not ~/.kde/share/apps) might be a good 
idea, for example, as it requires root privs to put something 
there. At the very least, users should be able to restrict where 
the scripts go, even if you allow them the possibility of 
residing in a world-writable directory.

Again, IO Slaves are probably somewhat different, but it might be 
possible to combine whatever lib support those require with the 
stuff that plugins need in a single .so (at worst a set of .so 
files).

Given that framework, it should be possible to write everything 
except plugins directly in Python (except for the lib layer of 
course). Plugins require an additional wrapper for the app's 
API, but these are fairly simple to generate on a case by case 
basis using C++ and sip.  I believe someone on the list 
indicated it was possible to fake the libtool .la lib, so that 
qmake can be used instead of autoconf/automake/libtool/etc, 
which also makes things *a lot* easier IMHO.

The use of dcop also comes up from time to time - again I haven't 
looked at it in detail (or written any code), but it appears to 
me that dcop is suitable for some tasks (like controlling an mp3 
player) but somewhat limited for a full-blown scripting 
interface (for example, what I'd want for KSpread). However, 
dcop could be handled with a project like this as well.

Obviously I'm having trouble just finding the time to keep PyKDE 
up to date, and it appears from the list that some of you are 
making a lot more headway on extensions for this stuff than I 
will in the forseeable future. What I'd suggest is that you all 
work  together - either informally as individuals or better yet 
set up a project to address some of this stuff. Quite honestly, 
if you start with something like kspreadcalc (see 
share/apps/kspread/kpartplugins/kspreadcalc.rc), a simple panel 
applet, and some of the KParts/plugin and other docs KDE has 
available, I think you'll find this is pretty simple and pretty 
clean to setup. 

About a year ago I did most of this for KSpread and it took 
perhaps several weeks (including a complete wrapper and some 
utilities) and I could script KSpread and write "built-in" 
spreadsheet formulas in Python. I am not a particularly good 
programmer - certainly not as competent as some of the people 
asking about this stuff. It's mostly a matter of figuring out 
how KDE does the interfacing and then plugging a few 
holes/bridging a few gaps with C++ so that you can use Python. 
I'd be surprised if went much over a few K lines of code.

What little code I have is fairly broken (KSpread has been 
revised incompatibly) and crude, but I expect you guys can come 
up with something much better anyway. The advantage of doing 
something like this (for KDE users anyway) is that you 
eventually end up with KDE being Python-scriptable system wide, 
similar to the relationship between Windows and Visual Basic, 
but with a real programming language and source code. 
Additionally, when I played around with KSpread, I found I could 
use Python to do things KSpread itself couldn't do - for example 
read/modify/link multiple spreadsheets in the background 
simultaneously, or write formulas with interesting side-effects. 
I suspect having Python access to KDE's "guts" would enable a 
lot of other cool stuff as well without having to go through the 
agony of writing it in C++.

I'll be happy to provide some pointers to docs (online and paper) 
and I have had a little correspondence with a KOffice developer 
who was interested in related stuff and can provide that 
contact. I'd start by identifying the different interface 
requirements informally and going for a general solution where 
possible, but I'd also pick something fairly easy (panel applets 
seems a good choice) and get some code running as soon as 
possible. If you have running code, you'll be more able to get 
the KDE guys to accomodate you if you need something from them 
(although I think this will bolt on pretty easily). You 
absolutely want to avoid any KDE dependencies on your libs or 
libpython, but this should also be easy.

If no one else picks this up, I'm still really interested in 
getting something like this working, but if you're waiting for 
me it's going to be quite a while. I'll be happy to provide 
whatever help I can. Even though this isn't necessarily PyKDE 
related, it certainly seems on topic for this list.

Talk amongst yourselves.

Jim