Re: [jfx16] RFR: 8252389: Fix mistakes in FX API docs [v3]
On Sat, 30 Jan 2021 20:21:59 GMT, Nir Lisker wrote: >> The usual doc fixes (for OpenJFX 16). >> >> Can wait until RDP2 to see if something else comes up. > > Nir Lisker has updated the pull request incrementally with one additional > commit since the last revision: > > Addressed review comments Marked as reviewed by aghaisas (Reviewer). - PR: https://git.openjdk.java.net/jfx/pull/380
Re: Make javafx.controls open and community-driven
Desktop is already a smaller market compared before. And the competition has become toucher because of several toolkits out there - Electron, Flutter, Compose for Desktop, etc. Hence, the need for more open and community-driven JavaFX project. On Wed, Feb 3, 2021, 12:14 PM Ty Young, wrote: > On 2/2/21 8:16 PM, Nir Lisker wrote: > > > Hi Mike, > > > > First of all, I would have you consider revisiting your medical > observation > > on the state of JavaFX. If you've read the almost-weekly recurrent > threads > > of "should I use Swing or JavaFX" in r/Java, you'd realize that reports > of > > JavaFX's death are greatly exaggerated. But yes, it is very understaffed. > > Other than that, there is a discussion list, > > openjfx-disc...@openjdk.java.net, where you can bring up general > community > > and social media related topics and continue that branch of the > discussion > > there. > > > > 1. I also advocated for having JBS more open in the past. I was told that > > Oracle tried opening JBS for everyone, but it was a big mess. I > > remember Alan Bateman saying a few years ago in an Ask The Architect > > session, when he was asked about this, that more than half of the bugs > > submitted are about OpenGL in Minecraft. These are the things you don't > see > > from the outside. > > > I'm guessing some of those are the OpenGL segfault crash on exit that > affects (nearly?) *every* OpenGL based Java application for the last few > years, including JavaFX and Minecraft, on Nvidia hardware. I have to > clear out my build directory often because of it. > > > > As for the OCA, it is a license requirement for all of OpenJDK. The > > developers here have nothing to do with it. I suspect you will have to > take > > it up with the legal department of Oracle. Good luck :) > > > > OCA is more of a symptom of a larger problem IMO: gate keeping. > > > A long time ago I suggested a 1-liner change to JavaFX's build script > that would simply place the source zip generated with the JavaFX source > build *outside* the lib folder. Generating this zip inside the lib > folder caused runtime problems with Ant and Netbeans whenever you > designated the entire folder as a lib directory in a project and it > didn't make sense anyway. It was rejected, IIRC, because of Oracle's or > Gluon's server configuration issues with the change. There were no > issues doing a local build that I'm aware of when I tested the change > locally. > > > More recently, Oracle decided to break Swing applications that use the > GTK L on Arch Linux based distros in JDK 16, was notified of the issue > multiple times by multiple people, and AFAIK refused to revert the > changes simply because Arch Linux isn't a "supported" distro. AFAIK, > it's still not possible to even launch Netbeans on Arch Linux without > overriding the L > > > Even more recently, I suggested (and was willing to actually do) what I > thought to be reasonable API changes to Project Panama, which I use in > my JavaFX application, were rejected because it was decided a year ago > behind closed doors discussions that the direction of that API part was > already decided. Not only that, but the ability to even have a public > discussion was basically shut down. > > > Someone has to be that person to make the decisions in the end, but > often times it feels like free outsourcing rather than contributing. One > moment it's "You should contribute!" and the next it's "No, I didn't > mean contribute *that* way!". > > > Anyway, this is a much larger issue that goes beyond JavaFX and I don't > want to derail, I'm just pointing out that not only when someone > suggests reasonable changes and fixes or, better yet(by far!), is > willing to make those changes, they are denied the ability to do so > because of reasons that person could not possibly be aware of. > >
Re: Make javafx.controls open and community-driven
On 2/2/21 8:16 PM, Nir Lisker wrote: Hi Mike, First of all, I would have you consider revisiting your medical observation on the state of JavaFX. If you've read the almost-weekly recurrent threads of "should I use Swing or JavaFX" in r/Java, you'd realize that reports of JavaFX's death are greatly exaggerated. But yes, it is very understaffed. Other than that, there is a discussion list, openjfx-disc...@openjdk.java.net, where you can bring up general community and social media related topics and continue that branch of the discussion there. 1. I also advocated for having JBS more open in the past. I was told that Oracle tried opening JBS for everyone, but it was a big mess. I remember Alan Bateman saying a few years ago in an Ask The Architect session, when he was asked about this, that more than half of the bugs submitted are about OpenGL in Minecraft. These are the things you don't see from the outside. I'm guessing some of those are the OpenGL segfault crash on exit that affects (nearly?) *every* OpenGL based Java application for the last few years, including JavaFX and Minecraft, on Nvidia hardware. I have to clear out my build directory often because of it. As for the OCA, it is a license requirement for all of OpenJDK. The developers here have nothing to do with it. I suspect you will have to take it up with the legal department of Oracle. Good luck :) OCA is more of a symptom of a larger problem IMO: gate keeping. A long time ago I suggested a 1-liner change to JavaFX's build script that would simply place the source zip generated with the JavaFX source build *outside* the lib folder. Generating this zip inside the lib folder caused runtime problems with Ant and Netbeans whenever you designated the entire folder as a lib directory in a project and it didn't make sense anyway. It was rejected, IIRC, because of Oracle's or Gluon's server configuration issues with the change. There were no issues doing a local build that I'm aware of when I tested the change locally. More recently, Oracle decided to break Swing applications that use the GTK L on Arch Linux based distros in JDK 16, was notified of the issue multiple times by multiple people, and AFAIK refused to revert the changes simply because Arch Linux isn't a "supported" distro. AFAIK, it's still not possible to even launch Netbeans on Arch Linux without overriding the L Even more recently, I suggested (and was willing to actually do) what I thought to be reasonable API changes to Project Panama, which I use in my JavaFX application, were rejected because it was decided a year ago behind closed doors discussions that the direction of that API part was already decided. Not only that, but the ability to even have a public discussion was basically shut down. Someone has to be that person to make the decisions in the end, but often times it feels like free outsourcing rather than contributing. One moment it's "You should contribute!" and the next it's "No, I didn't mean contribute *that* way!". Anyway, this is a much larger issue that goes beyond JavaFX and I don't want to derail, I'm just pointing out that not only when someone suggests reasonable changes and fixes or, better yet(by far!), is willing to make those changes, they are denied the ability to do so because of reasons that person could not possibly be aware of.
Re: RFR: 8260475: Deprecate for removal protected access members in DateTimeStringConverter [v2]
> Deprecating protected members in DateTimeStringConverter. Internal > implementation should not be exposed (similar to `NumberStringConverter` and > others). Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Added javadoc deprecation tags - Changes: - all: https://git.openjdk.java.net/jfx/pull/390/files - new: https://git.openjdk.java.net/jfx/pull/390/files/9fb95ba8..fb6d71a7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=390=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx=390=00-01 Stats: 15 lines in 1 file changed: 15 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/390.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/390/head:pull/390 PR: https://git.openjdk.java.net/jfx/pull/390
Re: Make javafx.controls open and community-driven
Hi Mike, First of all, I would have you consider revisiting your medical observation on the state of JavaFX. If you've read the almost-weekly recurrent threads of "should I use Swing or JavaFX" in r/Java, you'd realize that reports of JavaFX's death are greatly exaggerated. But yes, it is very understaffed. Other than that, there is a discussion list, openjfx-disc...@openjdk.java.net, where you can bring up general community and social media related topics and continue that branch of the discussion there. 1. I also advocated for having JBS more open in the past. I was told that Oracle tried opening JBS for everyone, but it was a big mess. I remember Alan Bateman saying a few years ago in an Ask The Architect session, when he was asked about this, that more than half of the bugs submitted are about OpenGL in Minecraft. These are the things you don't see from the outside. Another thing you need to consider is that we don't want to split the discussion of an issue between JBS and the mailing list. While I agree it's more comfortable to just be able to add a comment in the issue you are already reading, you can just write an email here, like you just did, with the extra info. I'm willing to spend the 30 seconds (most of which are spent on JBS loading :) ) of linking the discussion thread to the JBS issue myself. No one is being stopped from sharing their findings, this is the place to do it. As for the OCA, it is a license requirement for all of OpenJDK. The developers here have nothing to do with it. I suspect you will have to take it up with the legal department of Oracle. Good luck :) 2. There is a very good reason for hiding implementation. When you make something into a public API, you're making a long term commitment to its existence and functionality. This makes it very difficult to change it without breaking any existing behavior. Making everything public API is one of the worst decisions in terms of library design that wants to keep a contract with its users. There needs to be a way to allow controls extensions, I agree, but through an API that was designed for it. JS libraries break things all the time, which means that whenever you update a dependency you might need to rewrite some part of your code. That's the other side of the coin. The middleground is far from trivial. As for your points: - JavaFX is already on GitHub, it was one of the first (if not the first) OpenJDK project to transition. The javafxports repo was before Skara happened, and it has been defunct for a while now. We are on github.com/openjdk/jfx. - The mailing list is open, not hidden [1]. Social media is not a place to make formal announcements. The correct usage is to link announcements and such there (as done with all other OpenJDK projects and r/Java, for example). Since every reply here has agreed that it should be easier to customize controls, and there are many able bodies there, it seems like a discussion should start on a design plan (which is not "make everything public/protected). I would suggest first to break the general statement about controls into smaller chunks, like i18n, skins, css, behavior, extending an existing control vs creating a new one etc. Then look at existing issues for each, there have been many discussions on them in the past and this will give a good starting point. [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/ Best, Nir On Tue, Feb 2, 2021 at 8:37 AM wrote: > Hello. > > JavaFX is a great toolkit, which personally I like a lot, but it's slowly > dying for the past 5 years. You can barely > argue with that. Most of the devs still prefer Swing. Have a look how many > topics like "JavaFX is dead" on Reddit or > similar resources. Look how many community libraries are abandoned or > badly maintained > (https://github.com/mhrimaz/AwesomeJavaFX), including most popular ones, > like ControlsFX. Look how small the numbers of > real-world JavaFX apps. Also notice that no major Java apps adopted JavaFX > or have plans to use it in any near future. > Eclipse sticks with SWT, NetBeans uses FlatLaf ( > https://github.com/JFormDesigner/FlatLaf) and JetBrains puts lots of > resources into JetPack Compose. They even implemented interop layer for > Swing apps > ( > https://blog.jetbrains.com/cross-post/jetpack-compose-for-desktop-milestone-2-released/ > ). > > OpenJFX team is understaffed while modern desktop and mobile applications > require more components that JavaFX could > provide (and support) at the moment. javafx.controls are outdated and > Modena theme doesn't look pleasing anymore. But > that's not the worst part about it. The worst part is that it's almost > impossible to extend existing components. I do > understand that current resources and maintainers time are very limited > and maintaining graphics layer should be top > priority. The only thing I ask is to REMOVE BARRIERS that stop those who > want to improve standard controls. Make > javafx.controls fully open. Allow community
Re: Make javafx.controls open and community-driven
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
Re: Make javafx.controls open and community-driven
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.
Re: Make javafx.controls open and community-driven
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. -- Pedro Duque Vieira - https://www.pixelduke.com
Re: RFR: 8255572: Axis does not compute preferred height properly when autoRanging is off [v3]
On Tue, 22 Dec 2020 09:32:36 GMT, Ajit Ghaisas wrote: > > > At first, I thought this setTickLabelRotation() call violates the method > javadoc above. On a second look, I found that the javadoc is applicable only > if AutoRanging() is true. > Method calls - calculateNewSpacing() and calculateNewFirstPos() also set > properties if AutoRanging is false. Hence, this fix seems OK to me. hmm ... indeed they do, unexpected for me, reading the must-not-effect-the-state in the javadoc ;) Sounds like a doc error, if the intention was to clearly state that the method shouldn't do the auto-ranging itself? - PR: https://git.openjdk.java.net/jfx/pull/342
Re: RFR: 8255572: Axis does not compute preferred height properly when autoRanging is off [v6]
On Mon, 1 Feb 2021 23:13:02 GMT, Jonathan Vusich wrote: >> I do see that there are no changes from last time, which is good, so it will >> be fine for this time. >> >> When ready, you can add the new test by pushing a new commit. > > @kevinrushforth I was not aware of that, thank you for letting me know! > I wrote a new test for vertical axes and discovered that there were more > issues with axis layout calculations, which I also addressed. > > I also found out that the layout tests sometimes fail without a short pause > using `Util.sleep()`. I don't really like having to add sleeps, but I did > find that it got rid of any test flakiness. wondering about the system test - what stands in the way to add a simple "normal" unit test? - PR: https://git.openjdk.java.net/jfx/pull/342
