[Kde-bindings] Qt, Qyoto buttons work intermediately
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
- 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
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