Jeanette Winzenburg

did a bit of experimenting, trying to eat and keep the cake at the same time :) Or in terms of the new skin api: have a nice new life-cycle...

hmm .. with the singleton handler problem (f.i. [JDK-8268877](https://bugs.openjdk.org/browse/JDK-8268877)) out off the way (a skin must not set such a handler), it seems we are very near to a solution...

> > @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...

> 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...

> the constructor cannot distinguish between this property set by the user true, but currently it doesn't even _try_ to. So IMO that's __not__ a problematic pattern (as already pointed...

trying again: the current state of a (arbitrarily complex property) // constructor setting a property unconditionally control.setYY(myYY); // dispose if (getSkinnable().getYY() == myYY) getSkinnable().setYY(myYY); We agree that setting the property...

ahh .. at least I seem to see now where we talked past each other: YY userYY; // install userYY = control.getYY(); control.setYY(myYY); // dispose: reset to previous user installed...

that's basically the problem we identified as not solvable by current api, though I would formulate slightly differently: there are two bugs in our current implementation, one in step 3...

forgot: will not be near my IDE until next Monday - then I'll run the tests and see for myself :)

a bit confused about the [csr](https://bugs.openjdk.org/browse/JDK-8290741) - shouldn't that be focused entirely on SelectionModel.isSelected)? That's where we clarify the contract - all changes to TableXXSelectionModels are implementation changes, fixing their...