Re: Moving discussions to GitHub? (Philip Race)
I, for one, would be opposed to moving these discussions off the mailing lists. Most of the "issues" are straw men. The mailing lists are a "push" technology so I don't have to do anything special to get the info since my mail client is always on when my computer is on. I do not, and will not, place my code on a platform that is ruled by fiat by an organization as fickle and error prone as Microsoft. Hence, I seldom access anything on GitHub and will not receive any of the discussions if they move there and I have to do another sign-on to retrieve (and attempt to find) the information. In my experience GitHub is not a user friendly place and it IS NOT easy to find ANYTHING there. I don't see any issue with formatting or searching in mailing lists. Maybe users need a better mail client or something. Just my $.02. On Fri, Aug 20, 2021 at 3:27 AM Sebastian Stenzel < sebastian.sten...@gmail.com> wrote: > I am among the younger people here on the mailing lists (at least I think > so) and I can very much relate to what Michael suggests. So here is my > personal answer to the _why_ question: > > Mailing lists create an enormous barrier to external devs like myself who > are willing to contribute: > * Signing up to a means of the 80s feels just strange > * Signing up to _any_ additional tool is deterring (same holds true for > JBS), especially when you're used to low-threshold contributions to other > projects can be > * Therefore, signing up feels like a liability that you may not want to > commit to, if you merely want to express your support for a single comment > * It can be hard to find the correct mailing list for the topic you want > to discuss > * You'll >* either receive digests and miss a topic you're interested in >* or dozens of additional mails each day, alienating people who just > want to follow specific discussions > * No proper formatting > * No proper linking to code, issues, PRs, ... > * Hard to track diverging discussions > * Very hard to search - I basically need to use Google and restrict the > search to some mail archive > * Linking to different topics means you need to either quote the whole > thing or link to an archive > > On the other hand I see one important argument against GitHub Discussions: > We have no control over how Discussions will change in the future. Even if > they seem suitable today, we can't tell if it may be necessary to switch to > yet another tool in 5 years. Each time you switch, you strip connections to > discussions that took place on the previous platform. Switching tools > always comes with a commitment to it and bears this risk. > >
Re: JavaFX 16 and 17 artifacts on maven central [was: RFR: 8269597: Change JavaFX release version to 18]
Maybe it's a Netbeans indexing problem then because Netbeans does not see 16GA or 17EA. Thanks for info. Last thing NB sees is 16-ea+6. On Tue, Jul 6, 2021 at 6:58 AM Kevin Rushforth wrote: > [starting a new thread so this doesn't show up as a review comment in > the PR] > > There already are JavaFX 16 GA artifacts on maven central. Also, there > are JavaFX 17-ea artifacts. > > -- Kevin > > > On 7/6/2021 6:45 AM, Chuck Davis wrote: > > Anybody know if Maven central is ever going to be updated for 16 and 17? > > > > On Tue, Jul 6, 2021 at 5:58 AM Kevin Rushforth > wrote: > > > >> Bump the version number of JavaFX to 18. I will integrate this > immediately > >> after forking the `jfx17` stabilization branch, which is scheduled for > >> Thursday, July 8, 2021 at 16:00 UTC. > >> >
Re: RFR: 8269597: Change JavaFX release version to 18
Anybody know if Maven central is ever going to be updated for 16 and 17? On Tue, Jul 6, 2021 at 5:58 AM Kevin Rushforth wrote: > Bump the version number of JavaFX to 18. I will integrate this immediately > after forking the `jfx17` stabilization branch, which is scheduled for > Thursday, July 8, 2021 at 16:00 UTC. > > Leaving it as `Draft` for now. I'll make it `rfr` next week. > > - > > Commit messages: > - 8269597: Change JavaFX release version to 18 > > Changes: https://git.openjdk.java.net/jfx/pull/554/files > Webrev: https://webrevs.openjdk.java.net/?repo=jfx=554=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8269597 > Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod > Patch: https://git.openjdk.java.net/jfx/pull/554.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/554/head:pull/554 > > PR: https://git.openjdk.java.net/jfx/pull/554 >
Re: Moving src.zip out of the lib directory of the JavaFX SDK
I'm only an application developer but I look at scr.zip occasionally and your proposal makes a lot of sense to me. On Wed, Jun 23, 2021 at 6:51 AM Kevin Rushforth wrote: > Are there any IDE users who are currently having problems as a result of > this? If not, I'll retarget this for a future release. > > -- Kevin > > > On 6/14/2021 1:15 PM, Kevin Rushforth wrote: > > We deliver a set of modular jars in the lib directory of the > > standalone JavaFX SDK. We also deliver src.zip for use by IDEs into > > that same directory. If you add the lib directory to your > > application's module path in your IDE, it will try to load src.zip as > > if it were a jar file, and will fail. This is a pain point for > > developers using the SDK. This problem has been raised on the mailing > > list a couple of times, and I think it's time to fix it. This issue is > > tracked in JBS by JDK-8258499 [1]. > > > > I propose to move the src.zip file from the lib directory to the top > > directory of the SDK. > > > > Alternatively, we could create a new directory for src.zip (either a > > sibling of lib or sub-directory under lib). However, I think it would > > be easier to find in the top dir of the SDK, and I don't see the need > > for a new directory just to hold src.zip. > > > > Before I create the PR and the associated CSR, I'd like to hear > > developer's opinions on this. > > > > -- Kevin > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8258499 > > > >
Re: Minimum JDK policy for OpenJFX
I use JFX with NetBeans every day with no problems. NetBeans 12.3 and JFX 16 on OpenJDK16 SceneBuilder creates the dialogs. NetBeans writes the code. The NB JFX is too old. You have to update from Maven (which is, itself, still stuck on old versions of JFX -- hasn't been updated for some time, unfortunately). BUT, using JFX with NetBeans is not a problem here. On Tue, May 18, 2021 at 1:52 PM Matthias Bläsing wrote: > Hi, > > Am Dienstag, dem 18.05.2021 um 08:17 -0700 schrieb Kevin Rushforth: > > > > In general, we only guarantee that JavaFX N runs on JDK N-1 or later. In > > practice, though, we don't bump it for each release, as there are some > > advantages in being able to run with the latest JDK LTS. Since JavaFX 17 > > will release at roughly the same time as JDK 17 LTS, I can't think of a > > good reason to not update our minimum. > > > > Comments? > > I'd like to be able to use JavaFX with NetBeans. Everytime I tried to > reach a state where it became usable I hit issues in FX and the latest > crasher bug will only be fixed in 17 and at this time NetBeans still > tries to stretch from 8 to 16 (ok, 9 and 10 were left in the dust). > > IMHO stability and compatibility with the past is a feature, not a bug > and the "lets brake it" attitude I feel the last years in the java > landscape is irritating. > > Greetings > > Matthias > >
Re: list digest
Thanks Scott for the advice. I played a little with that but didn't think about using it in that way. I'll investigate more. I think it is a work around that should not be necessary but I'll check'er out. Thanks. On Tue, Dec 22, 2020 at 12:22 PM Scott Palmer wrote: > You might consider supplying your own sortPolicy (see sortPolicyProperty > <https://openjfx.io/javadoc/15/javafx.controls/javafx/scene/control/TableView.html#sortPolicyProperty>). > It could remove your "total" object, call the DEFAULT_SORT_POLICY > <https://openjfx.io/javadoc/15/javafx.controls/javafx/scene/control/TableView.html#DEFAULT_SORT_POLICY> > and > then add your total object back. > > Scott > > On Sun, Dec 20, 2020 at 4:50 PM Chuck Davis wrote: > >> Thanks guys for the link to the digest. >> >> I've looked through a couple of years and find nothing that addresses my >> interest. As background, I write financial applications and usually when >> a >> user selects something to display in a table it's because they're >> interested in the total amount. And it is easy to provide that >> information >> to them on the initial display. >> >> The rub comes when they select a column header or otherwise sort the >> table. I need, first of all, to eliminate the total object from the model >> (this is done easily by listening to the onSort property). Then, after >> the >> sort is complete I need to add the total object back to the model. If I >> don't eliminate the total object from the model the sort puts it in very >> strange places. What I need to know is when the sort is complete so >> that I can add the total object back into the model and get it displayed. >> >> I've been looking at the TableView source and find the following code near >> the start of the sort() method: >> SortEvent> sortEvent = new >> SortEvent<>(TableView.this, >> TableView.this); >> fireEvent(sortEvent); >> >> It seems to me it would be trivial to invent another event type >> SORT_COMPLETE and emit it at the end of the sort() method to notify the >> program that the sort has been completed. And that would certainly solve >> a >> major headache with showing a total amount for financial tables. What I >> don't know is whether the sort is done on another thread in which case a >> Future would probably be required to detect the sort completion. >> >> If this were implemented we programmers would be able to detect both the >> start and completion of a sort of the table and proceed accordingly. It >> would be VERY helpful. >> >> Thanks for reading. >> >
Re: list digest
Thanks guys for the link to the digest. I've looked through a couple of years and find nothing that addresses my interest. As background, I write financial applications and usually when a user selects something to display in a table it's because they're interested in the total amount. And it is easy to provide that information to them on the initial display. The rub comes when they select a column header or otherwise sort the table. I need, first of all, to eliminate the total object from the model (this is done easily by listening to the onSort property). Then, after the sort is complete I need to add the total object back to the model. If I don't eliminate the total object from the model the sort puts it in very strange places. What I need to know is when the sort is complete so that I can add the total object back into the model and get it displayed. I've been looking at the TableView source and find the following code near the start of the sort() method: SortEvent> sortEvent = new SortEvent<>(TableView.this, TableView.this); fireEvent(sortEvent); It seems to me it would be trivial to invent another event type SORT_COMPLETE and emit it at the end of the sort() method to notify the program that the sort has been completed. And that would certainly solve a major headache with showing a total amount for financial tables. What I don't know is whether the sort is done on another thread in which case a Future would probably be required to detect the sort completion. If this were implemented we programmers would be able to detect both the start and completion of a sort of the table and proceed accordingly. It would be VERY helpful. Thanks for reading.
Re: list digest
I just joined the list but I can't find a link to a digest of past activity. I'm specifically interested in discussions regarding TableView. Does anyone know where to find the list digest? Thanks.
