Hugh Gibson wrote:
>
> There may be framework errors from this (see message about combobox).
> Fixing these can't be done by simple dispose calls - there's a more
> complex question about who has ownership of the created subsidiary
> objects.
>
Well said.
>
> But when the cell event has finished, you definitely don't want to be
> destroying the parent scroller object!
>
I've corrected this, thanks to a report from Romain.
> This needs a lot more careful analysis.
>
That's perfectly true. Actually, I thought the primary widget
maintainers would jump in and take over for their respective code. As
this didn't happen, I thought the next best thing would be to give it a
go, and then sort out any issues with missing objects that come up. All
I want to achieve is a consolidated situation where all remaining
'missing' messages of the disposer have to be in and be in for a reason
("Faking" object disposal with _disposeFields as now in CellEvent might
be a good way of showing it has been taken care of).
> And finally could I say that tracing the patches and reasons for changes
> is very difficult when you haven't got an issue for them, with full
> logging of issue number in SVN checkin messages; and SVN revision numbers
> in the issue.
>
I see what you're hinting at. I'm not sure, though, this "double
bookkeeping" is feasible for us, but that's only my 2 cents.
Thomas
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
