You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Following on from #9375 by @iceteagroup, disposing of widgets manually causes the same problems as having to manually dispose ordinary objects - IMHO it arises less often only because many applications never remove widgets from their UI.
A clean solution will be to make wigets auto-dispose; I think that this may be possible by delaying registering widgets in qx.core.ObjectRegistry until they are actually added to the UI and de-registering them when they are removed. Because we no longer have to decouple DOM from JS, the only reason that this register/deregister is needed is for backwards compatibility, ie to allow code to be able to rely on widget.toHashCode() being listed in ObjectRegistry. The DOM objects already have been modified so that they have the widget as a property (ie not just a string of the hash, but the actual Qx object).
However, the key principal with auto-dispose is that the destructor does not do anything of any significance and the difficulty is that widgets often only do cleanup when they are destroyed - eg qx.ui.core.Widget destructor removes the widget from appearance queues, and this code would have to be moved to a new "onDetach" function.
This should be fine for backwards compatibility because any existing user code which removed objects will either call dispose() (in which case onDetach will have been called, plus the user's destructor) or they were allowing the leak so are no worse off.
There are a number of references under qx.event.handler.* where references to widgets are kept, and these could be confirmed as being cleaned up by onDetach or converted to decoupled via hash codes.
The text was updated successfully, but these errors were encountered:
Following on from #9375 by @iceteagroup, disposing of widgets manually causes the same problems as having to manually dispose ordinary objects - IMHO it arises less often only because many applications never remove widgets from their UI.
A clean solution will be to make wigets auto-dispose; I think that this may be possible by delaying registering widgets in
qx.core.ObjectRegistry
until they are actually added to the UI and de-registering them when they are removed. Because we no longer have to decouple DOM from JS, the only reason that this register/deregister is needed is for backwards compatibility, ie to allow code to be able to rely onwidget.toHashCode()
being listed inObjectRegistry
. The DOM objects already have been modified so that they have the widget as a property (ie not just a string of the hash, but the actual Qx object).However, the key principal with auto-dispose is that the destructor does not do anything of any significance and the difficulty is that widgets often only do cleanup when they are destroyed - eg
qx.ui.core.Widget
destructor removes the widget from appearance queues, and this code would have to be moved to a new "onDetach" function.This should be fine for backwards compatibility because any existing user code which removed objects will either call
dispose()
(in which caseonDetach
will have been called, plus the user's destructor) or they were allowing the leak so are no worse off.There are a number of references under
qx.event.handler.*
where references to widgets are kept, and these could be confirmed as being cleaned up byonDetach
or converted to decoupled via hash codes.The text was updated successfully, but these errors were encountered: