[Kde-bindings] Qt, Qyoto buttons work intermediately

[Arno Rehn]

On Tuesday 16 February 2010 23:39:56 James Mansion wrote:
> Arno Rehn wrote:
> > Yes, trapping show and hide events is not exactly a nice way to keep
> > track of used windows. But the visibility of a window is the only
> > feature I could think of that indicates whether a window is still used
> > or not.
> 
> I'm not sure that show and hide are quite the right events - its the
> destroy event really.
> You can logically regard the native window handle (which is owned by the
> windowing
> system) as owning a reference to its on proxy object, and release it
> when the native
> handle is destroyed.
So what you suggest is preventing deletion through the GC/the programmer 
completely and just wait for Qt or the windowing system to delete it. That 
would be a possibility, yes. But it completely defeats the purpose of having a 
GC in the first place. Its job is to delete the window when it's appropiate. 
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.
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 guess systems that defer instantiation of the native window until
> first show or some
> such can result in a race anyway. Its definitely safer to keep such
> windows in a global
> somewhere.
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.

-- 
Arno Rehn
arno at arnorehn.de