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 <[email protected]> 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 <[email protected]> wrote: >> >> Send openjfx-dev mailing list submissions to >> [email protected] >> >> 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 >> [email protected] >> >> You can reach the person managing the list at >> [email protected] >> >> 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 <[email protected]> >> Cc: [email protected] >> Subject: Re: Has any consideration been made to move the Charts into s >> separate module? >> Message-ID: <[email protected]> >> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >> 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 <[email protected]> >> wrote: >>>>>>>> >>>>>>>> -- >>>>>>>> rjs >>>>>> -- >>>>>> rjs >>>> >> >> >> >> ------------------------------ >> >> Message: 2 >> Date: Mon, 7 Jan 2019 01:40:09 +1100 >> From: John-Val Rose <[email protected]> >> To: Tom Eugelink <[email protected]> >> Cc: [email protected] >> Subject: Re: Has any consideration been made to move the Charts into s >> separate module? >> Message-ID: <[email protected]> >> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >> 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 <[email protected]> >> wrote: >>>>>>>>> >>>>>>>>> -- >>>>>>>>> rjs >>>>>>> -- >>>>>>> rjs >>>>> >>> >> >> >> ------------------------------ >> >> Message: 3 >> Date: Sun, 6 Jan 2019 13:15:15 -0600 >> From: Ty Young <[email protected]> >> To: [email protected] >> Subject: Re: JavaFX Content Rendering & Resizing and Font Bugs In >> Linux >> Message-ID: <[email protected]> >> 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" <[email protected]> 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
