Phil Thompson <[EMAIL PROTECTED]> wrote: > 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?
It looks like a *very* untypical way of doing things -- at least for modal dialogs. I believe 99.999% of modal dialogs out there are not meant to live more than the scope of the function/method where they are invoked. > 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. Uhm, I do not like this. I prefer the current state of things to this solution: at least now we are consistent among all widgets. With this solution, we will have to remember that modeless dialogs have to be specially handled as an exception to the exception. I still think the best point where to patch this is QDialog.exec. It is a specific call of QDialog, and used only for modal dialogs. I can't see why one would realistically have to call exec() and still keep the object around even after exec() executed. For this kind of things, people do setModal(True) + show() (e.g. progress bars). Another suggestion: for PyQt3, we add a parameter to exec, like QDialog.exec(transferback=True), with default=False for backward compatibility. For PyQt4, we remove the default argument and we force people to use either exec(True) or exec(False). This makes sure people think of the lifetime issue every time they use a dialog and pick the correct behaviour for their code. Explicit is better than implicit, after all. -- Giovanni Bajo _______________________________________________ PyKDE mailing list [email protected] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
