On Mon, 15 Aug 2022 15:37:15 GMT, Jeanette Winzenburg <[email protected]> wrote:
>>> A quick PoC is in [my fork off Andy's >>> PR](https://github.com/kleopatra/jfx/tree/exp-skin-install-supportsInstall) >> >> @kleopatra : >> Thank you so much for your effort to research the alternatives. >> >> The main issue that necessitates creation of install() and moving it outside >> of the skin's constructor is the fact that certain code just cannot be >> inside of the skin's constructor - because the old skin is still attached. >> So it must be called after the old skin has been removed in setSkin(). I >> don't think there is a way around it. >> >> Those user-defined skins (and the affected core skins) that modify >> singletons or rely on internals of the superclass - must be refactored. The >> others, which only add listeners and children nodes, can remain unchanged. > >> >> @kleopatra : Thank you so much for your effort to research the alternatives. >> > > thinking about alternatives is our job, isn't it :) > >> The main issue that necessitates creation of install() and moving it outside >> of the skin's constructor is the fact that certain code just cannot be >> inside of the skin's constructor - because the old skin is still attached. >> So it must be called after the old skin has been removed in setSkin(). I >> don't think there is a way around it. > > There might be such code, but I doubt that there is anything (at least > nothing validly installed) in our skins. Haven't looked into the install > children that are defined in the control itself (like f.i. editors in the > combo/spinner et al). > >> >> Those user-defined skins (and the affected core skins) that modify >> singletons or rely on internals of the superclass - must be refactored. > > As long as custom classes play by the rules (aka: don't violate the spec) > we'll have a hard time imposing code changes onto custom classes. Or if we > do, we might see us in the middle of many pointed fingers. Like (from [kinds > of compatibilty](https://wiki.openjdk.org/display/csr/Kinds+of+Compatibility)) > >> While an end-user may not care why a program does not work with a newer >> version of a library, what contracts are being followed or broken should >> determine which party has the onus for fixing the problem I'd like to move forward with this PR. Despite many insightful suggestions from @kleopatra , I don't think there is a way around this problem except to create a new method. Thank you. ------------- PR: https://git.openjdk.org/jfx/pull/845
