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 _______________________________________________ PyKDE mailing list [EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
