[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pykde
Subject:    Re: [PyKDE] Issue with QDialog and lifetime
From:       "Phil Thompson" <phil () riverbankcomputing ! co ! uk>
Date:       2005-07-07 14:01:36
Message-ID: 28762.194.203.13.71.1120744896.squirrel () river-bank ! demon ! co ! uk
[Download RAW message or body]

> Phil Thompson <phil@riverbankcomputing.co.uk> wrote:
>
>> 1. Either add an optional parameter to exec_loop() which does the
>> transfer
>> or have exec_loop_and_transfer() (or something less of a mouthful). At
>> least that way it won't break existing code.
>
> I like this solution. Then I can do:
>
> class QDialog(QDialog):
>     exec_loop = QDialog.exec_loop_and_transfer
> sys.modules["qt"].__dict__("QDialog") = QDialog

I don't really like it. I've realised that my worry about seg faults is
misplaced - it's an issue for generic SIP generated bindings, but Qt's
parent/child handling will avoid it in this case - so I'm reconsidering
the original proposal.

The original proposal would cause problems in the following scenario...

1. One or more modal dialogs that are hidden when not used, rather than
being re-created each time they are needed.

2. The dialogs are Python sub-classes of QDialog or the dialog has
instance objects (ie. there are useful Python objects tied to the C++
instance).

3. No application references to the dialogs are maintained. The
application relies on finding a dialog again by searching its parent's
children.

This would seem to be an untypical way of doing things - is anybody going
to shout that their 5 million line application relies on this technique?

In fact, from a consistency point of view, I think I might prefer to make
the solution apply to all dialogs - by removing the /TransferThis/ from
the ctors.

Phil

_______________________________________________
PyKDE mailing list    PyKDE@mats.imk.fraunhofer.de
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
[prev in list] [next in list] [prev in thread] [next in thread]