What do you think about decoupling javafx.controls from other modules private API? Is it possible? In current situation it may be the best solution, because this would allow to fork it. So, those who interested could play with fork(s) and backport changes when neccessary. It would also allow to develop other controls libs, those aren't based of javafx.controls, e.g. just for mobile.
Best regards Mike On Tue, 2021-02-02 at 13:40 -0800, Kevin Rushforth wrote: > There are two separate issues here. I won't address the first point from > the initial poster, other than to say that I understand that the lack of > direct write access to JBS for occasional contributors is a pain point. > I don't think it is stopping anyone from contributing, though. As for > the other part of this point, JavaFX is already on GitHub along with the > rest of the JDK, and it's easy enough for someone who is motivated to > provide a pull request for a bug fix. > > The more interesting question is the one about extensibility that others > have also responded to. This raises the question of which areas are most > in need of new public API to facilitate this. "Just make every internal > detail of your implementation public or protected" isn't the right way > to frame the discussion. Anything that makes it into the public API is > something that needs to be documented, tested, and supported. It > requires us to consider what it means to support that API forever; we > take compatibility seriously. The main idea is to think in terms of > "stewardship" when evolving the JavaFX API. > > Keeping that in mind, there are certainly areas that could be made > easier to extend. Two things in the UI Controls area that were brought > up are skins, which are public API with not all of the fields and > methods of the skins are public/protected, and behaviors. The former > isn't too difficult to address. It requires some amount of thought, > discussion, API documentation, implementation, and testing, but doesn't > need a whole new design. VirtualFlow has been extended in this fashion > to provide missing pieces for third-party controls. If there are others, > developers can propose them and we can discuss them. This is definitely > an area we would welcome well-thought-out contributions in. > > The harder area is that of behaviors. For a little background, a public > behaviors API was originally part of the proposed new public API for FX > in JDK 9, which was done via JEP 253 [1]. It was decoupled from that > JEP, but still remains an open enhancement request tracked by > JDK-8091189 [2]. That JBS issue has a very long discussion thread about > possible approaches for the API. This would be a very large effort, and > would require someone with a very good understanding of both UI control > design in general and the design and implementation of JavaFX UI > Controls in particular to lead the effort. It isn't something that we > would accept from an application developer who is just wanting to make > their life easier. Again, think of it in terms of API stewardship. I'm > not saying there is no way this could be done, just that it's unlikely. > > I'm sure there are other areas outside of UI controls that could be made > more extensible, too (although knowing how fragile CSS is, I wouldn't > have much enthusiasm for that). What we would need is a concrete > proposal that we could discuss. > > -- Kevin > > [1] https://openjdk.java.net/jeps/253 > [2] https://bugs.openjdk.java.net/browse/JDK-8091189 > > On 2/2/2021 6:30 AM, Michael Paus wrote: > > 1+ > > > > Am 02.02.21 um 15:12 schrieb Pedro Duque Vieira: > > > Hi, > > > > > > Although I don't agree with everything said here at the start of this > > > thread, I agree with the base idea that JavaFX would benefit from being > > > more open than it is currently. It's something I've already said here in > > > this mailing list and since it's been a while and that discussion > > > probably > > > already got forgotten I'll add the comments to this thread again. > > > > > > Not even just the controls case but more hooks to extend JavaFX just > > > generally by adding API that allows for that and making things less > > > private/final/etc. It would be great to be able to extend more parts of > > > JavaFX in a library independent way (i.e. by creating your own > > > library that > > > extends some parts of JavaFX in more fundamental cool way). > > > Besides what was already said about controls, here's another example: > > > wouldn't it be great for the community to be able to create a library > > > that > > > could extend the CSS parser by adding animations, layout support, > > > etc, etc. > > > One could argue, why don't you just contribute a PR to the JavaFX > > > code base > > > that does just that (adds animation support to CSS, or something less > > > trivial like that)? I'd say that that process is too lengthy and > > > often out > > > of possibility for an individual developer that wants to improve > > > JavaFX but > > > doesn't have time to do it that way. > > > > > > I see the advantage of exposing less of the internals and why the JavaFX > > > team decided to do it. Many of the same guys that developed JavaFX were > > > part of the Swing team which were bothered by the inverse situation, > > > i.e. > > > being too open (which also can have its disadvantages). > > > Weighing in the pros and cons, I still think there's a bigger > > > advantage in > > > being more open than closed. This hinders the capacity for the > > > community to > > > create libraries that extend JavaFX in new and fundamental ways without > > > having to fork JavaFX. > > > And this is more of a reality now that the JavaFX team is smaller > > > (than the > > > original team) and hence has less capacity to keep improving and adding > > > features to JavaFX which means it has to rely more on the community. > > > > > > I also agree with the process of submitting a bug and following upon it, > > > commenting, etc. Ideally it should be easier. That's something that has > > > also been brought up before. > > > > > > Anyways, this mail is not meant to put down the guys working on > > > JavaFX, there are no perfect toolkits, each one has its downfalls. > > > Think it > > > more like throwing in ideas and sharing my experience of using JavaFX > > > for > > > creating libraries and applications. > > > > > >
