openjfx-dev Digest, Vol 86, Issue 7
John-Val Rose
johnvalrose at gmail.com
Tue Jan 8 07:36:35 UTC 2019
Upon reflection Ramon, and not being fully aware of the existing modularisation of JavaFX, I now agree with your suggestion.
Graciously,
John-Val
> On 8 Jan 2019, at 01:44, Ramon Santiago <ramonjsantiago at gmail.com> wrote:
>
> 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