[Kde-bindings] Qt, Qyoto buttons work intermediately

James Mansion james at mansionfamily.plus.com
Thu Feb 18 06:06:54 UTC 2010

Arno Rehn wrote:
> Now we have to decide when this point is reached.
> One condition is, of course, to have no more valid references to the window in 
> code.
Yes, but:
 - I can see it and interact with it
 - the window system might deliver an event to it that causes it to reappear

I think your strategy handles the former, but I'm concerned about 
timers, network events and so on.

> As top-level widgets in a fully managed GUI toolkit would for sure have valid 
> references in some hashtable or list, the window probably wouldn't be deleted 
> while it's visible (except if the user explicitly wants it to be deleted). So 
> currently I try to emulate that behaviour by catching show and hide events.
I understand - I just think 'visible' is the wrong way to do it: I might 
have a window that is
orphaned like this and is protected while visible but then destroyed 
just because some timer
or other handler *owned by the window* elects to hide it temporarily.  I 
think that will be very

> I can't think of any situation where this would cause a race condition. The 
> window is created, the show() method is called and we create a global 
> reference to it so it won't be deleted until it's hidden again. Can't see a 
> step where a race condition could occur here.
By 'race' I mean 'be destroyed by GC' since the decision to start GC is 
essentially asynchronous.
In your scheme it might be OK - its an issue with create/destroy in the 
native window system.

I think theer is precedent for retaining unowned top level windows in 
PyQt isn't there, and
probably elsewhere?  Why not just look at other GC'd windowing systems 
and see what they

I suspect that a window that is logically 'open' (and has no parent) is 
normally retained, and
I'm arguing that it should be open/close, not show/hide that drive this.

More information about the Kde-bindings mailing list