openjfx-dev Digest, Vol 86, Issue 7
Ramon Santiago
ramonjsantiago at gmail.com
Mon Jan 7 14:44:23 UTC 2019
I thank the community for their feedback.
To clarify my original comments, I would consider "core" UI Controls as
those at the
javafx.scene.control level but;
not javafx.scene.chart
nor javafx.scene.web, which is already in a separate module
etc...
I still believe that the charts should be put in their own module.
I understand that this opinion is not shared by others.
On Mon, Jan 7, 2019 at 7:00 AM <openjfx-dev-request at openjdk.java.net> wrote:
> Send openjfx-dev mailing list submissions to
> openjfx-dev at openjdk.java.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.openjdk.java.net/mailman/listinfo/openjfx-dev
> or, via email, send a message with subject or body 'help' to
> openjfx-dev-request at openjdk.java.net
>
> You can reach the person managing the list at
> openjfx-dev-owner at openjdk.java.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openjfx-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Has any consideration been made to move the Charts into s
> separate module? (Tom Eugelink)
> 2. Re: Has any consideration been made to move the Charts into s
> separate module? (John-Val Rose)
> 3. Re: JavaFX Content Rendering & Resizing and Font Bugs In
> Linux (Ty Young)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 6 Jan 2019 13:16:35 +0100
> From: Tom Eugelink <tbee at tbee.org>
> Cc: openjfx-dev at openjdk.java.net
> Subject: Re: Has any consideration been made to move the Charts into s
> separate module?
> Message-ID: <965fc039-fba7-f005-08b1-bc2257f41f3a at tbee.org>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> I'm responding to your "moving he charts to a separate JPMS? module". It
> would make sense to have a javafx.charts, but at least charts are not in
> javafx.graphics or lower. Javafx.controls is IMHO an okay-but-not-ideal
> JPMS module to have them in. But since they are now, it's not really worth
> a refactor. Given the typical size of a controls application, the charts
> classes won't make much of a difference.
>
> Whether charts belong in OpenJFX in the first place, and this what I think
> you mean with "core" (you have not established that concept either), is
> another topic. I would say no, the chart library of Gerrit illustates that.
> But someone at some point thought it was a good idea, just like half of
> Maven is/was in the JRE (a new HTTP client implementation???). So because
> of backward compatibility keeping in OpenJFX what was in Oracle's JRE makes
> sense. Call it historical debt or something. We just need a better
> alternative and then the classes can be removed at some point in the future.
>
>
> On 6-1-2019 10:43, John-Val Rose wrote:
> > So Tom are you saying that javafx.base and javafx.graphics are the only
> ?core? modules in JavaFX?
> >
> > Has that ever been officially stated or established?
> >
> > How can javafx.controls or javafx.fxml not be considered core modules?
> >
> > There?s not much you can do with JavaFX without controls and FXML
> (albeit optional) is a critical part of most JavaFX apps.
> >
> >> On 6 Jan 2019, at 20:27, Tom Eugelink <tbee at tbee.org> wrote:
> >>
> >> But (I assumed charts was in core as Ramon said) taking a look at the
> javadoc; charts are in the controls module, not in the core (javafx-base or
> javafx-graphics). So that seems quite ok.
> >>
> >> https://docs.oracle.com/javase/9/docs/api/javafx.controls-summary.html
> >>
> >>
> >>> On 6-1-2019 02:58, John-Val Rose wrote:
> >>> I doubt any JavaFX application would use ALL the features so couldn?t
> you make the same argument for ?detachment? about many other parts of
> JavaFX?
> >>>
> >>> And what are the ?core components?? That is probably a subjective
> question.
> >>>
> >>>> On 6 Jan 2019, at 00:56, Ramon Santiago <ramonjsantiago at gmail.com>
> wrote:
> >>>>
> >>>> Yes, I meant removing charts from the core of JavaFX and moving he
> charts to a separate JPMS module.
> >>>>
> >>>> Why? They are not really core components are they? They are dead
> weight in applications that never will use them.
> >>>>
> >>>>> On Sat, Jan 5, 2019 at 8:44 AM John-Val Rose <johnvalrose at gmail.com>
> wrote:
> >>>>> Hi Ramon,
> >>>>>
> >>>>> I personally have never seen or heard of any such discussion and I?m
> not entirely sure in which context you are using the word ?module?.
> >>>>>
> >>>>> Do you meaning simply removing charts from the core of JavaFX or do
> you mean creating the charts as an actual module within JPMS?
> >>>>>
> >>>>> Either way, can you tell us why you have thought of this idea?
> >>>>>
> >>>>> Graciously,
> >>>>>
> >>>>> John-Val
> >>>>>
> >>>>>> On 6 Jan 2019, at 00:33, Ramon Santiago <ramonjsantiago at gmail.com>
> wrote:
> >>>>>>
> >>>>>> --
> >>>>>> rjs
> >>>> --
> >>>> rjs
> >>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 7 Jan 2019 01:40:09 +1100
> From: John-Val Rose <johnvalrose at gmail.com>
> To: Tom Eugelink <tbee at tbee.org>
> Cc: openjfx-dev at openjdk.java.net
> Subject: Re: Has any consideration been made to move the Charts into s
> separate module?
> Message-ID: <1672B6A4-853E-42E1-AF71-16209674CB98 at gmail.com>
> Content-Type: text/plain; charset=utf-8
>
> I think we actually agree Tom.
>
> I have not established what is ?core? JavaFX simply because it has never
> crossed my mind that some modules are ?core? whereas others must (by
> inference) be ?peripheral?.
>
> I don?t see any value in refactoring charts into their own module given
> that, as I said, without controls there?s not much value in using JavaFX.
>
> There are lots of really good 3rd-party controls libraries such as those
> of Gerrit that you mentioned but there are numerous other 3rd-party JavaFX
> libraries that do not relate to controls at all.
>
> I guess I just don?t see any reason to strip JavaFX right down to the
> ?core? (whatever that is) by for example moving charts or any other
> specific type of control into separate JPMS modules.
>
> And does anyone have some actual real-world stats as to how frequently
> charts are used? I, for one, certainly do not view them as ?dead weight?.
>
> > On 6 Jan 2019, at 23:16, Tom Eugelink <tbee at tbee.org> wrote:
> >
> > I'm responding to your "moving he charts to a separate JPMS module". It
> would make sense to have a javafx.charts, but at least charts are not in
> javafx.graphics or lower. Javafx.controls is IMHO an okay-but-not-ideal
> JPMS module to have them in. But since they are now, it's not really worth
> a refactor. Given the typical size of a controls application, the charts
> classes won't make much of a difference.
> >
> > Whether charts belong in OpenJFX in the first place, and this what I
> think you mean with "core" (you have not established that concept either),
> is another topic. I would say no, the chart library of Gerrit illustates
> that. But someone at some point thought it was a good idea, just like half
> of Maven is/was in the JRE (a new HTTP client implementation???). So
> because of backward compatibility keeping in OpenJFX what was in Oracle's
> JRE makes sense. Call it historical debt or something. We just need a
> better alternative and then the classes can be removed at some point in the
> future.
> >
> >
> >> On 6-1-2019 10:43, John-Val Rose wrote:
> >> So Tom are you saying that javafx.base and javafx.graphics are the only
> ?core? modules in JavaFX?
> >>
> >> Has that ever been officially stated or established?
> >>
> >> How can javafx.controls or javafx.fxml not be considered core modules?
> >>
> >> There?s not much you can do with JavaFX without controls and FXML
> (albeit optional) is a critical part of most JavaFX apps.
> >>
> >>> On 6 Jan 2019, at 20:27, Tom Eugelink <tbee at tbee.org> wrote:
> >>>
> >>> But (I assumed charts was in core as Ramon said) taking a look at the
> javadoc; charts are in the controls module, not in the core (javafx-base or
> javafx-graphics). So that seems quite ok.
> >>>
> >>> https://docs.oracle.com/javase/9/docs/api/javafx.controls-summary.html
> >>>
> >>>
> >>>> On 6-1-2019 02:58, John-Val Rose wrote:
> >>>> I doubt any JavaFX application would use ALL the features so couldn?t
> you make the same argument for ?detachment? about many other parts of
> JavaFX?
> >>>>
> >>>> And what are the ?core components?? That is probably a subjective
> question.
> >>>>
> >>>>> On 6 Jan 2019, at 00:56, Ramon Santiago <ramonjsantiago at gmail.com>
> wrote:
> >>>>>
> >>>>> Yes, I meant removing charts from the core of JavaFX and moving he
> charts to a separate JPMS module.
> >>>>>
> >>>>> Why? They are not really core components are they? They are dead
> weight in applications that never will use them.
> >>>>>
> >>>>>> On Sat, Jan 5, 2019 at 8:44 AM John-Val Rose <johnvalrose at gmail.com>
> wrote:
> >>>>>> Hi Ramon,
> >>>>>>
> >>>>>> I personally have never seen or heard of any such discussion and
> I?m not entirely sure in which context you are using the word ?module?.
> >>>>>>
> >>>>>> Do you meaning simply removing charts from the core of JavaFX or do
> you mean creating the charts as an actual module within JPMS?
> >>>>>>
> >>>>>> Either way, can you tell us why you have thought of this idea?
> >>>>>>
> >>>>>> Graciously,
> >>>>>>
> >>>>>> John-Val
> >>>>>>
> >>>>>>> On 6 Jan 2019, at 00:33, Ramon Santiago <ramonjsantiago at gmail.com>
> wrote:
> >>>>>>>
> >>>>>>> --
> >>>>>>> rjs
> >>>>> --
> >>>>> rjs
> >>>
> >
>
>
> ------------------------------
>
> Message: 3
> Date: Sun, 6 Jan 2019 13:15:15 -0600
> From: Ty Young <youngty1997 at gmail.com>
> To: openjfx-dev at openjdk.java.net
> Subject: Re: JavaFX Content Rendering & Resizing and Font Bugs In
> Linux
> Message-ID: <29ef5775-9c0d-f9e5-74ad-4d1b7ccb4a39 at gmail.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
>
> On 1/6/19 5:06 AM, Siddhesh Rane wrote:
> > (An earlier version of this email turned out completely empty when
> delivered on the mailing list)
> >
> > I have used JavaFX on Linux since 8.0 and have never faced any serious
> issues.
> >
> > January 3, 2019 4:29 AM, "Ty Young" <youngty1997 at gmail.com> wrote:
> >
> >> In my attempt to write a more proper responsive JavaFX UI, I've created
> >> a new JavaFX project which extensively uses DoubleBindings to force the
> >> min/max width/height of various components to their parent containing
> >> objects(HBox and VBox mainly) so that 1440p and 4k displays could be
> >> more easily supported.
> > This is not how layout is supposed to be done. The parent container
> calculates its computed size based on its children which takes into account
> min/pref/max size of children. Min/pref/max are intrinsic properties of the
> child irrespective of the container it is in.
> > You are introducing a chicken and egg situation here by having both
> dimensions depend on each other. You'll get undefined behaviour.
> >
> > If you want children to occupy full width and height of parent, set VBox
> to "fill width" with Vgrow ALWAYS on children and Hbox to "fill height" and
> hgrow always in scene builder.
>
>
> I'm well aware of how the parents size is calculated. However, the more
> level top level UI components are percentage based of the entire window
> so that, for example, the left button is 15% of the total window width
> and the ScrollPane is 85% of the total window width. Content within the
> ScrollPane is also reduced to 85% of the ScrollPane's width.
>
>
> This percentage based UI scaling has been done in website for years.
> There isn't anything particularly different here. Content should
> theoretically be resized in a top down fashion on any resize event after
> first creation. If this causes unnecessary resizing events then why
> exactly does the DoubleBinding API even exist to begin with? This is
> always going to be an issue when you use it.
>
>
> >
> >> While it does allow for easier 1440p and 4k
> >> scaling, JavaFX itself seems to have /extremely/ horrible content
> >> rendering & resizing bugs to the point where the application becomes
> >> usable.
> > If you are taking about buttons being extremely small on high definition
> screens on Linux, you can set root font size in your css to >1.0em.
> Alternatively you can set default font size with -
> Dcom.sun.javafx.fontSize=18 where default is 12. You can try it for any
> javafx application by setting _JAVA_OPTIONS=-Dcom.sun.javafx.fontSize=18 on
> the command line.
>
>
> As far as I'm aware JavaFX uses the system default font size unless told
> otherwise. As such, font should scale perfectly on native displays.
> Problem is, this is not true when using xrandr to scale the viewport nor
> does it affect padding or spacing between UI elements so while it'll
> supposedly look fine using a more responsive application design like
> i've been doing it will be less 1:1 scaling. Extra handling is required
> for above 1080p scaling sadly.
>
>
> Default font size is 13 according to Font.getDefault().getSize().
> According to Gnome Tweaks it's supposed to be 11. Which one is right?
> Who knows. Maybe using Font.getDefault().getSize() isn't a reliable way
> of getting system font size but I can't immediately think of a better
> way to get the actual system font size.
>
>
> >
> >> Multiple of the bugs can be observed by simply resizing the JavaFX
> >> window. When doing so, content will seemingly struggle to keep up with
> >> resizing events. As a result, white(or sometimes black) glitching can be
> >> seen wherever the window is being expanded and UI components will "jump"
> >> around.
> > White or black bars on window expansion are not specific to javafx. I've
> seen that on Windows file explorer and Chrome with Gmail tab. It seems to
> me that the window resizing happens asynchronously so it doesn't wait for
> the application to have calculated layout and painted the new area. For any
> complex UI, the layout computation cannot keep up with window resize.
>
>
> In complete honestly I've never really payed much attention to window
> resizing behavior until now as I usually just keep applications
> maximized. Opening various applications and resizing them shows that
> while there are far more applications with glitchy and low FPS resizing,
> there are also examples of applications that have no trouble resizing UI
> components.
>
>
> Non glitchy:
>
>
> Gnome Settings(My app design is roughly based on this. It too uses
> percentage based UI sizing without issue.)
>
> Gnome Disks
>
> QT5 Settings
>
> GNU Octage
>
> Only Office
>
> Vid Cutter
>
>
> Glitchy:
>
>
> JavaFX apps
>
> Netbeans
>
> WPS Office
>
> Steam(game client)
>
>
> Given that some applications with fairly complex UI work fine I don't
> really buy the "UI is just too complex!" theory/defense/excuse. Not only
> does the app use bog standard JavaFX UI components but there aren't that
> many on the screen at any given time. Going by behavior of ScrollPane's
> glitchy horizontal bar, JavaFX doesn't even resize UI content that isn't
> in a user's view anyway so the amount of UI components that needs to be
> resized is fairly small(maybe 40 including TableView's subcomponents?).
>
>
> >
> >> Thinking that this might be problems caused by extensive use of
> >> DoubleBinding, I launched SceneBuilder 10 which uses Oracle JDK 10. It
> >> has all of the same UI glitching that I've encountered in my JavaFX
> >> application at a lesser scale besides TableView since it doesn't use
> >> TableView.
> > Scene Builder is a complex application. Above point applies.
>
>
> SceneBuilder's complexity is always a constant so it would stand to
> reason that the glitchy resizing would also be a constant. It isn't.
> Again, the glitchy behavior is seemingly dependent on the 3 things that
> I mentioned.
>
>
> >> Another problem is a font bug revolving around making text bold. When
> >> attempting to make a label bold, the boldness is seemingly not being
> >> applied to some Label text. It might work on a few Labels in a certain
> >> part of the UI but completely refuse in other parts. Making things
> >> weirder is the disappearing boldness of Labels after setting a new Pane
> >> in the ScrollPane and switching back to a that specific pane.
> > Without relevant code, we cannot comment.
>
>
> <Label>.setFont(Font.font(Font.getDefault().getFamily(),
> FontWeight.EXTRA_BOLD, Font.getDefault().getSize());
>
>
> Just a typical setFont() call.
>
> >
> > Regards
> > Siddhesh Rane
>
>
> End of openjfx-dev Digest, Vol 86, Issue 7
> ******************************************
>
--
rjs
More information about the openjfx-dev
mailing list