Validation Support

[Robert Lichtenberger]

Am 08.03.24 um 00:40 schrieb Marius Hanl:
> One note here regarding that a lot of things are final in JavaFX:
> The problem is not that everything is final - this is intended and 
> makes sense, since we speak mostly of properties here. Overriding 
> those will not give you any benefit.
> You mostly want to override e.g. Controls if you add something new to 
> it (a new property) or may just want to set another default skin.
> This design is mostly superior than e.g. Swing, where you can override 
> things and easily break something if not too careful.
> Pretty sure that this were some lessons learned from the development 
> of Swing.
> The biggest problem is rather that a lot of methods are package 
> private or 'Accessors' are used to call specific methods, which is not 
> just a questionable design but also restrict the usage.
> It is often not possible to override even a minor feature inside the skin.
> So you may rather want to recreate the skin then, and copy the 
> existing skin and just change some stuff. But this will mostly not 
> work either, as there is a lot of internal API usage, e.g. Accessors 
> or some com.sun.javafx.scene.control.skin.Utils usage.

Yes, I had such a problem yesterday. TableView uses <Ctrl>+<Space> as 
shortcut to toggle selection of current row. I want to use that key 
combination as a "global" shortcut however. I have a regular menu bar 
with a menu item that has <Ctrl>+<Space> as accelerator.

Now I need to remove that bit from the TableView's behavior. I've seen 
that there are efforts under way to make behavior public API. I would 
really welcome that :-).


BTW, https://bugs.openjdk.org/browse/JDK-8088068 is also an issue 
concerning accelerators that I currently need a separate class as 
workaround.


Other issues that I currently work around somehow (inconvenient, but no 
showstopper):

JDK-8092315, JDK-8087981, maybe also JDK-8123117, but I think that on is 
correctly closed as  "not an issue", will have to check.

To put this into perspective, we have a lot more references to JavaFX 
issues in our code, which have all been fixed :-).


One major pain point that we have at the moment is CSS performance, I 
think (but did not investigate yet) that some kind of performance 
regression happened somewhere between 17 and 21.


Overall speaking, with the ongoing efforts for a RichText-control and 
making behavior public API, I think JavaFX is definitely on the right 
track, at least from my perspective :-).


--Robert

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240308/441a4e3f/attachment-0001.htm>