[PyKDE] QtDesigner - simpler proxy
jbublitz at nwinternet.com
Sun Nov 2 20:41:01 GMT 2003
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
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
> 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
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.
More information about the PyQt