[PyKDE] QtDesigner - simpler proxy

[Jim Bublitz]

On Sunday November 2 2003 09:42, Roland Schulz wrote:

> I'm not sure, is it the default behavior of an widget to get
> the results for all these functions from its children?
> What is displayed incorrect? On my computer in my version it
> diplays correct - exacltly like the c++ version. Funny is that
> the preview looks little bit different from the version in the
> edit mode. In the preview there is no space between the button
> and the lineedit. But this is the same in the C++ version.

The original widget displayed is just a small square. If you 
enlarge it, the button and line edit are squashed together, and 
beyond a certain point, the line edit can't be made any larger - 
space is just added to the right of the button, or below the 
pair. I haven't really looked at the code for FileChooser to see 
if it sets any sizing limits. I'm sure that's due to 
"reparenting" FileChooser - it worked fine for me too if I just 
pass back the FileChooser widget (but of course that doesn't 
allow the meta object manipulation).

> In what way is QListView a "compound" widget? Do you mean
> QListViewItem or QListViewPrivate as part? Both don't have
> singals/slots.

QListView is a QScrollView descendent and all QScrollViews have a 
viewport widget (and a clipper). The viewport handles a lot of 
the interesting events (like mouse events when clicking 
QListViewItems) via slots that aren't part of the QListView 
interface. You can access them via viewport(), but I haven't 
noticed any support for this in QtDesigner.

> You have write access to the pykde.sf.net cvs as developer.
> Just import qtdesinger
> http://sourceforge.net/docman/display_doc.php?docid=14033&grou
>p_id=1#commandimport http://sourceforge.net/cvs/?group_id=61057
> and add me as developer for pykde.

QtDesigner isn't part of PyKDE really. I don't really have a 
"policy" on this, but my current attitude is that PyKDE is the 
basic Python bindings for KDE. Related stuff like panel applets, 
KControl, KParts plugins are just that - related. I did panel 
applets differently, but my current plan is to add stuff like 
that in the contrib/ directory and have it build separately, be 
maintained separately, etc. 

As I've mentioned before (and it will be even more true with 
Phil's sip 4.0 enhancements), PyKDE is not a 'traditional' 
project. It mostly gets generated automatically in one big pass 
in about 3 minutes and then I go back in and add whatever new 
handwritten code is required (for KDE 3.1.4 that was none). As 
such, it really doesn't lend itself to CVS or concurrent 
development, and anything that becomes "part of" PyKDE I'd like 
to have fit that scheme. contrib stuff just gets dropped in a 
directory when I package the tarball.

There isn't anything on the sf CVS (unless someone else has put 
something there).. In the interest of full disclosure, I'm not 
that familiar with CVS, so it takes me a lot of time to do 
simple tasks with it and I usually screw them up at least once. 
My feeling is I wouldn't like CVS even if I understood it.

> If you don't want to add me as a developer to pykde, I can
> create a new project for the plugin. If you don't want to
> import it, I'll do after you send it me and added me as
> developer. Of course we don't have to use cvs, but I think
> this would make it a lot easier (and would reduce traffic on
> the mailinglist).

You SHOULD make it a separate project - it's largely your (and 
David's I presume) work. You should maintain control over it 
(and maintain it, do bug fixes, handle questions, etc), or if 
you're unable, allow someone else to pick it up as maintainer. 
You seem to be doing a good job - this isn't necessarily 
something that will happen quickly or easily.

My opinion would be that it belongs with (as in "related to", not 
necessarily "part of") PyQt. The set of PyQt users is much 
larger than the subset that use PyKDE, and I'd hate to see 
people have to install PyKDE to use this. That means 
libpythonize needs to be moved someplace else too - either 
standalone or part of PyQt or part of your project.  I'll be 
happy to maintain a distribution of that (since I wrote it), but 
I'd be just as happy if someone else picked it up and improved 
it. It isn't very big or complicated, but it shouldn't be a 
static lib IMHO. It would make sense to have a common version of 
libpythonize for all of this stuff, and also to have installers 
check for it, and not re-install it if it's already available.

If nobody has a better suggestion, I'll put libpythonize up on 
the SourceForge PyKDE site as a separate project/tarball - 
probably in a week or two. The unit test stuff is broken at the 
moment, but otherwise it's fairly complete and even has its own 
docs.

I also don't have any knowledge or resources to do a Windows port 
of QtDesigner plugins (or a Mac port), and I have a lot of work 
piling up for sip 4, KDE3.2 and other projects of my own I'd 
like to complete and release.

Jim