I assume since JFX stated with and was closely coupled with Java prior to being removed from the JDK/JRE, this allow for the link up with the java bug link.
The case could be made it could be similar to the other library’s. I believe some other existing libraries (JAXB?) were removed [maybe more for modularity and smaller profiles but] in favor of the having dependency when needed but allowing development separately as independent projects but the specific I’m a little fuzzy on). Since JFX was Sun/Oracle IP, I assume this also accounts for some of the restrictions. As I understand in the grand open bizaar scheme that if there are areas that are closed, re-implement and replace it with open where applicable. Now with all those comments out of the way... Regarding the decoupling java fix.controls...With modularity in mind, would it be worth having a service layer / package / module interface added in some way and then make existing controls implementations of the service then further improvements could implement and/or extend as preferred as implementations of this? Eric Bresie ebre...@gmail.com (mailto:ebre...@gmail.com) > On February 3, 2021 at 6:24:20 AM CST, naast...@gmail.com > (mailto:naast...@gmail.com) wrote: > 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. > > > > > > > > >
