[PyKDE] PyKDE with KDE 3.0.1?
Jim Bublitz
jbublitz at nwinternet.com
Tue Jun 4 02:58:00 BST 2002
On 03-Jun-02 Bret McMillan wrote:
> On Mon, 3 Jun 2002, Jim Bublitz wrote:
> More data:
> [bretm at zealot kde]$ hostname
> zealot.devel.redhat.com
> [bretm at zealot kde]$ pwd
> /usr/include/kde
> [bretm at zealot kde]$ grep -r KDE_VERSION .
> ./kdeversion.h:#ifndef _KDE_VERSION_H_
> ./kdeversion.h:#define _KDE_VERSION_H_
> ./kdeversion.h:#define KDE_VERSION 301
> ./kdeversion.h:#define KDE_VERSION_STRING "3.0.0-10"
> ./kdeversion.h:#define KDE_VERSION_MAJOR 3
> ./kdeversion.h:#define KDE_VERSION_MINOR 0
> ./kdeversion.h:#define KDE_VERSION_RELEASE 1
> ./kdeversion.h:#endif // _KDE_VERSION_H_
> ./kprotocolmanager.h:QString("Mozilla/5.0 (Konqueror/%1;
> compatible MSIE
> 5.5; X11)").arg(KDE_VERSION_STRING)
> [bretm at zealot kde]$
Thanks! I'm assuming from KDE_VERSION_STRING and the RH7.3 release
date that it's still 3.0.0, despite the '301'.
Of course the other possible fix is to modify kdeversion.h (even
temporarily - just while running configure). Presently configure
only looks at the KDE_VERSION line - just change '301' to '300'.
>> 3. Enabling Python-based plugins and panel applets for KDE (not
>> necessarily PyKDE related - separate project/still sip-based).
> Hmmm. Got any info along these lines? If this is done cleanly,
> I'd consider using PyKDE for my panel applet instead... :)
I'm not sure this applies perfectly to panel applets, but here's
how I did it for KSpread: You basically need two C++ libraries. The
first is a general library which wraps the Python interpreter and
provides some hooks for loading/running scripts and returning
results. That lib should support any kind of Python-based plugins,
applets or KParts. (Basically KDE-specific embedded Python)
The second lib is specific to the app you're plugging into, so each
app needs it's own wrapper (not full bindings though). That lib
knows the API of the parent app (for example, KSpread, noatun,
panel applets) and also knows how to load the first (interpreter)
lib and talk to it. You also need an app specific .rc file for the
plugin lib.
The KDE app finds the .rc file in it's
share/apps/<appname>/kpartsplugin subdirectory and uses that to
load the app-specific lib. The app-specific lib loads the the
interpreter lib. In the case of KSpread, the .rc file/lib also
includes some menu additions to allow you to load an arbitrary
Python script via the plugin. The script imports bindings for the
parent app's wrapper (say 'import pyKSpread') - the bindings are
just a simple wrapper:
In C++:
void Wrapper::setCell (char *cellAddr, char *value)
{
someKSpreadClassInstance->setCell (row (cellAdrr), col (cellAddr),
value);
}
In sip:
class Wrapper
{
setCell (char *, char *);
};
In Python:
from pyKSpread import Wrapper
pi = str (3.1416)
w = Wrapper ()
w.setCell ("A3", pi)
That's really what most of the wrapper consists of on the
C++/sip side. To get KSpread to run arbitrary Python scripts or load
Python-based "built-in" spreadsheet formulas adds about 1MB of
overhead - 800KB+ of which is the Python interpreter. With the
little testing I did, Python based formulas were within +/- 10% of
the compiled in formulas - close enough in speed that they might
have even been slightly faster (KSpread overall is horribly slow
compared to StarOffice). Like any plugin, this actually calls into
the KSpread C++ code to do it's work - the Python script just makes
those calls. It's all pretty high level.
In addition, the simple C++ wrapper allows you modify the exposed
API - for example, the KSpread API only takes (int row, int col)
for cell addresses, so I wrote a little extra code to handle cell
addresses like ("A3") or ("A1:H3"), etc. as well as regrouping the
classes/methods in a more manageable fashion for scripting (an
architecture that makes sense for a standalone app isn't
necessarily the best way to script it). When done this should be
pretty newbie friendly, unlike PyKDE/PyQt.
So you basically have: C++ interpreter lib, C++ interface/wrapper
lib, XML rc file and wrapper/binding (another lib via sip).
The code to do all this took about 4-5 hours (really easy). It
probably took another 20 hours to figure out the KSpread API, and
about 40 hours or more (not kidding) to get the configure/make stuff
working. Of course it still needs a lot of cleanup, testing and
especially docs. The only other thing I plan to add is simplified
dialog construction, since the rest of the GUI is already in
KSpread. Don't need PyKDE at all for this (although it could be
imported, just like any other Python lib).
Anyway, I have all this stuff put together, but the makefiles are
pretty machine specific and nothing's too organized. I'm not sure
if it even works at the moment. If you want to take a stab at it, I
can send you stuff, but it's really a mess right now. It's also
still at KOffice 1.1, but that doesn't matter for panel applets. As
far as the wrapper and bindings - they're really easy and I can give
you a few general rules for creating the wrapper and the sip files
for the bindings. I'm not sure you want to go that far, but if you
do, let me know. If not, don't worry about it - I like doing this
stuff.
Jim
More information about the PyQt
mailing list