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
and
 - 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
confusing.

> 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
do?

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.


_______________________________________________
Kde-bindings mailing list
Kde-bindings@kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings