[Kde-bindings] Qt, Qyoto buttons work intermediately

[Arno Rehn]

On Monday 15 February 2010 19:58:25 Richard Dale wrote:
> On Monday 15 February 2010 06:20:04 pm Robert Riemann wrote:
> > > Yes, Richard was right. In your main.cs file your create the MainWindow
> > > simply with
> > > new MainWindow();
> > > but don't save it in a variable. The GC thinks it is now eligible for
> > > collection since there are no other references to it anymore.
> > > I had already committed a fix a while back that should have prevented
> > > visible top-level widgets from being collected, but I didn't cover
> > > every possibility. I just committed another fix which makes this
> > > works. Thanks for the report!
> > 
> > I think such kind of fixes should be removed from trunk. Using widgets
> > without a reference seems to be dirty coding style to me,
> > which doesn't need  to be supported.
> 
> Well most Qt language bindings do attempt to support this. For instance, in
> QtRuby during the garbage collection mark phase, the QtRuby runtime
> traverses the QObject heirarchies and marks everything in the trees as
> still in use. So in the case of a QMainWindow, maybe it has the
> QApplication as a parent, even though there isn't an instance of the
> window live in the application code, it can still be treated as a live
> reference and kept.
It might be bad coding style in C/C++, but in managed languages you can expect 
this to "just work". I guess we should follow the principle of least surprise 
here. If you create a new window with 'new Foo()' and it appears on screen, 
you don't expect it to magically stop working and at some point of time simply 
crash.
Figuering out that you would have to create a static member variable in the 
containing class which keeps a reference to the created window is definitely 
not intuitive.

> > Trying to fixing it would be something like a workaround which isn't
> > really necessary imho, but creates overhead.
> > 
> > I vote for removing these workarounds.
> 
> Well it depends what you mean be a workround. I'm not so sure trapping show
> and hide events is a good idea, but at the moment I think the trunk is a
> good place to experiment as we don't have a new KDE release for about six
> months.
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.

-- 
Arno Rehn
arno at arnorehn.de