[PyKDE] The thingie that makes your user interfaces....
rasky at develer.com
Tue Apr 5 18:48:18 BST 2005
Torsten Marek <shlomme at gmx.net> wrote:
>> I created a new release (0.2.1, same place as yesterday) showing two
>> of putting implementations and UI files together.
>> The first one uses some deeper Python magic to create types on the fly
>> not. A lot of implicit stuff and some restraints (?) like not having to
>> base class constructor. Furthermore, you inherit from PyQtUI but this is
>> your base class at all.
>> The second one is more typing on the user side and you need to make sure
>> you inherit the correct base class and call your base class constructor,
>> it's more obvious what happens.
>> Preferences, anybody?
>> Although I like the dark stuff happing in (1), I'd go for (2).
It's not clear to me what happens in the second case if whatever you bring
up from the UI parser is not a QDialog, since you already constructed a
The other solution proposed by Truls has another side effect, in that you
lose the ability of having the class defined at import time, with the
obvious fallouts (if you have to inherit 10 other classes from it in 10
different modules, things get harder and harder).
I would go for something like:
I like your first solution, but it's not clear to me why you are using
__new__, it does not seem to bring any benefit, and makes us violate the
usual paradigm of calling __init__ on the base class. I think the better way
would be something like:
def __init__(self, uifile, *args, **kwargs):
newcls = p.parse_withType(uifile)
self.__class__.__bases__ = (newcls, )
newcls.__init__(self, *args, **kwargs)
def __init__(self, parent):
PyQtUI.__init__(self, "mywindow.ui", parent)
# now it's a QDialog!
assert isinstance(self, QDialog)
The fact that isinstance() works as expected has other benefits (for
instance, you can find such widgets through queryList() and the such).
More information about the PyQt