[PyKDE] PyKDE update

[Jim Bublitz]

On Monday September 29 2003 02:52, Roland Schulz wrote:

> I had to many tests at university to look at getting
> QtDesigner Plugins to work. Has someone taken a look at it in
> the meantime? Any advices how I should starting this now that
> I have a little bit of time?

I believe someone else on the list has been looking into this - 
hopefully they can give you an update. I'd recommend an approach 
similar to PyKPanelApplet/libpykpanelapplet in PyKDE3.8rc2 
(available at http://www.sourceforge.net/projects/pykde). That 
includes doing two things:

1. Embedding Python - libpythonize already takes care of this, 
although I suspect for QtDesigner you'll run into the same 
problem panel applets had, which is problems in loading multiple 
plugins with a single instance (single pid) owning libpythonize. 
There is a fix for this (for panel applets anyway - works for 
KControl also I believe), but it needs some more work and 
testing.

2. Creating a .so lib - libpykpanelapplet is a single .so lib 
that loads any (well-behaved) Python-based panel applet, so 
Python users don't need to create the .so lib. The same should 
be possible for QtDesigner. For panel applets, kicker calls a 
factory function ('init' in this case). From the info kicker 
passes to the factory function (basically the config file name), 
it's possible to locate and load a properly named/located panel 
applet.

libpythonize is not dependent on PyKDE - it just isn't available 
any place else at the moment. I'm hoping the same approach will 
work for all the plugin environments in both KDE and Qt (panel 
applet, panel extension, KControl modules, KParts, QtDesigner, 
style plugins, etc., and even plugins for Kontact and KOffice 
eventually).

I'd be happy to provide whatever assistance I can on this, and 
would appreciate any input on libpythonize if you use that and 
find you need changes/extensions. I'll be working on related 
stuff for PyKDE over the next several weeks.

> > I also have completely new documentation generation working
> > - you'll end up with two choices: you can use a provided
> > documentation reader. or you can generate a complete HTML
> > class reference. The HTML runs about 3MB. The reader
> > generates HTML on the fly and the data file is only about
> > 600KB.  The new docs provide a Python formatted description
> > for every method and also provide links to the KDE classref
> > docs. The reader has two panes - one for the PyKDE docs and
> > one for the linked KDE docs. The generator for the full HTML
> > docs will set the same links if provided with the path to
> > the KDE classref docs. The reader also allows you to add
> > your own annotation to the docs, and the annotations are
> > kept in a separate file and should survive version changes.
> > I have some work to do to make this installable and usable,
> > but it seems to work pretty well.

> Is this also possible for the QT Documentation?

It'd be a lot of work. There are a couple of problems - here's 
the long explanation:  This works by starting from both the h 
files and sip files for a given PyKDE version. I use presip 
(code generator - generates sip files from h files normally) 
with a switch to generate a documentation text file instead of 
sip files. Each major element (namespace, class, method, enum, 
typedef, variable) has an encoding that the viewer/html 
convertor can use to generate HTML (either on demand in the 
viewer, or to a file using the convertor - same input format and 
HTML format either way).

The problems with PyQt are that Phil organizes the project 
differently than PyKDE. That isn't a major problem, but it means 
creating PyQt project files for presip (not too hard) and 
running a parallel project, which is always a pain to keep in 
sync and updated. The more serious problem is that a) PyQt 
supports a lot of older Qt versions (I think this is a Good 
Thing, but it's a problem in this specific case) and b) in PyKDE 
most h files have variable names for method args, while in Qt 
more methods don't.  The end result of both of those is the docs 
aren't as useful as in the PyKDE case. presip gets the variable 
names from the h files (if they exist) and with the older Qt 
versions, many of the methods have disappeared or changed 
significantly. The method declaration in the docs ends up with 
all of the correct types, but variable names like "a0", "a1" 
etc., which makes it harder to reconcile with the Qt C++ docs 
and less useful on its own.

I did try this a few weeks ago and it "works", but PyQt would 
also need a different HTML format than PyKDE - don't recall why 
I thought that exactly, but what made sense for PyKDE wasn't as 
good for PyQt.  Certainly the variable name problem was a big 
part of it. There are some other issues with marking up 
handwritten code - I didn't go far enough to see if I could 
bootstrap that from the current PyQt doc format or not. PyKDE 
uses it's own embedded markup method for handling that (also 
generated mostly automatically)

I also don't want to oversell this - pretty much all it does is 
give you a Python formatted method declaration like:

	KEdit (parent= None, name = "")
        returns a KEdit instance

	argument   type        default
       -----------------------------------
        parent       QWidget    None
        name        char *         ""

for each method, tells you if it's limited to specific versions 
(or not implemented at all),  provides a few other details 
(static, virtual, pure virtual, etc), and links to the KDE C++ 
docs for more explanation. I can add text to each method, but 
have in only 2 or 3 cases. It's unlikely I'll spend much time 
writing docs, but probably will add text for special cases. This 
probably isn't nearly as good as what theKompany is currently 
offering.

What I'd want (and I believe Phil agrees - we've discussed it a 
little) is a solution that's transparent and automatic - for 
various reasons, it's not desireable or even a good idea to 
expect PyQt to conform to what presip expects for project 
organization/markup, while at the same time  I don't want to be 
doing Qt docs on a regular basis. This might work out some time 
in the future, but it isn't going to get a high priority right 
now.
        
> > I've also test-generated PyKDE3.2alpha1 and fixed a few
> > problems with my sip file generator. I won't be releasing a
> > PyKDE version for PyKDE3.2 until I can get KDE3.2 binaries
> > to install and test against - compiling KDE from source just
> > looks too
> > time-consuming at the moment.

> Do you know of Konstruct
> (http://developer.kde.org/build/konstruct/)? I works very
> good. This way it only takes long for the computer ;-). In
> case you have SuSE I could also send you the compiled bineries
> as tgz. Creating rpm would take too much time I guess. All
> just in case you're intrested. I don't need PyKDE3.2 at the
> moment.

Thanks for the offer - I'll probably look at it in the future. 
I'd need to set up a specific partition for this plus do the 
compile. As you point out, most of that is machine time but 
depending on circumstances, it still involves a few days of 
elapsed time, and I have a lot of other stuff I want to get to 
first with the time I have available. I would like to get to it 
ahead of the 3.2 final release though.

Jim