great, many thanks, is it a correct assumption that if running javafx on 
embedded platform using monocle and framebuffer platforms (i.e no x11)  if we 
run pmap on our Java process then we shouldn't see any linking to X related 
libraries?

On 8 Dec 2015 19:55, openjfx-dev-requ...@openjdk.java.net wrote:
>
> Send openjfx-dev mailing list submissions to
>         openjfx-dev@openjdk.java.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev
> or, via email, send a message with subject or body 'help' to
>         openjfx-dev-requ...@openjdk.java.net
>
> You can reach the person managing the list at
>         openjfx-dev-ow...@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. OpenJFX armv6hf libjavafx_font_freetype.so x11 (Dell Green)
>    2. [9] Review request for JDK-8144789: Incorrect assertion fails
>       in the    GlassCursor.m (Morris Meyer)
>    3. Re: OpenJFX armv6hf libjavafx_font_freetype.so x11 (David Hill)
>    4. Re: Why there is no WebWorker like mechanism for JavaFX
>       (Tom Schindl)
>    5. Re: Future of JavaFX (Mike Hearn)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 8 Dec 2015 14:25:07 +0000


Dell Green
R&D Software Manager
t: (+44)203 668 9870

> From: Dell Green <dell.gr...@ideaworks.co.uk>
> To: "openjfx-dev@openjdk.java.net" <openjfx-dev@openjdk.java.net>
> Subject: OpenJFX armv6hf libjavafx_font_freetype.so x11
> Message-ID: <9d740561-a52c-42d7-bf3b-716a431aa...@ideaworks.co.uk>
> Content-Type: text/plain; charset="utf-8"
>
>
>
> Hi Guys,
>
> Is it correct that  ?libjavafx_font_freetype.so?  be linked against X 
> libraries? as our embedded guys who are running without X were surprised to 
> see this as they are running without X using monocle and frame buffer 
> platforms on raspberry pi and MX6? Do we meet to install X11 if running in 
> frame buffer modes?
>
>
> libjavafx_font_freetype.so:
>         libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb6f68000)
>         libgtk-x11-2.0.so.0 => 
> /usr/lib/arm-linux-gnueabihf/libgtk-x11-2.0.so.0 (0xb6bc0000)
>         libgdk-x11-2.0.so.0 => 
> /usr/lib/arm-linux-gnueabihf/libgdk-x11-2.0.so.0 (0xb6b24000)
>         libatk-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libatk-1.0.so.0 
> (0xb6b00000)
>         libgio-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgio-2.0.so.0 
> (0xb69c0000)
>         libpangoft2-1.0.so.0 => 
> /usr/lib/arm-linux-gnueabihf/libpangoft2-1.0.so.0 (0xb69a4000)
>         libpangocairo-1.0.so.0 => 
> /usr/lib/arm-linux-gnueabihf/libpangocairo-1.0.so.0 (0xb6990000)
>         libgdk_pixbuf-2.0.so.0 => 
> /usr/lib/arm-linux-gnueabihf/libgdk_pixbuf-2.0.so.0 (0xb696c000)
>         libcairo.so.2 => /usr/lib/arm-linux-gnueabihf/libcairo.so.2 
> (0xb6890000)
>         libpango-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libpango-1.0.so.0 
> (0xb6844000)
>         libfreetype.so.6 => /usr/lib/arm-linux-gnueabihf/libfreetype.so.6 
> (0xb67b8000)
>         libfontconfig.so.1 => /usr/lib/arm-linux-gnueabihf/libfontconfig.so.1 
> (0xb6780000)
>         libgobject-2.0.so.0 => 
> /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0 (0xb6730000)
>         libgthread-2.0.so.0 => 
> /usr/lib/arm-linux-gnueabihf/libgthread-2.0.so.0 (0xb6724000)
>         librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xb6714000)
>         libglib-2.0.so.0 => /lib/arm-linux-gnueabihf/libglib-2.0.so.0 
> (0xb6620000)
>         libXtst.so.6 => /usr/lib/arm-linux-gnueabihf/libXtst.so.6 (0xb6614000)
>         libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 
> (0xb6540000)
>         libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb64cc000)
>         libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb64a4000)
>         libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 
> (0xb6484000)
>         libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6354000)
>         /lib/ld-linux-armhf.so.3 (0xb6f94000)
>         libX11.so.6 => /usr/lib/arm-linux-gnueabihf/libX11.so.6 (0xb6240000)
>         libXcomposite.so.1 => /usr/lib/arm-linux-gnueabihf/libXcomposite.so.1 
> (0xb6234000)
>         libXdamage.so.1 => /usr/lib/arm-linux-gnueabihf/libXdamage.so.1 
> (0xb6228000)
>         libXfixes.so.3 => /usr/lib/arm-linux-gnueabihf/libXfixes.so.3 
> (0xb6218000)
>         libXext.so.6 => /usr/lib/arm-linux-gnueabihf/libXext.so.6 (0xb6200000)
>         libXrender.so.1 => /usr/lib/arm-linux-gnueabihf/libXrender.so.1 
> (0xb61f0000)
>         libXinerama.so.1 => /usr/lib/arm-linux-gnueabihf/libXinerama.so.1 
> (0xb61e4000)
>         libXi.so.6 => /usr/lib/arm-linux-gnueabihf/libXi.so.6 (0xb61d0000)
>         libXrandr.so.2 => /usr/lib/arm-linux-gnueabihf/libXrandr.so.2 
> (0xb61c0000)
>         libXcursor.so.1 => /usr/lib/arm-linux-gnueabihf/libXcursor.so.1 
> (0xb61b0000)
>         libgmodule-2.0.so.0 => 
> /usr/lib/arm-linux-gnueabihf/libgmodule-2.0.so.0 (0xb61a4000)
>         libz.so.1 => /lib/arm-linux-gnueabihf/libz.so.1 (0xb6184000)
>         libselinux.so.1 => /lib/arm-linux-gnueabihf/libselinux.so.1 
> (0xb6160000)
>         libresolv.so.2 => /lib/arm-linux-gnueabihf/libresolv.so.2 (0xb614c000)
>         libharfbuzz.so.0 => /usr/lib/arm-linux-gnueabihf/libharfbuzz.so.0 
> (0xb60f4000)
>         libpng12.so.0 => /lib/arm-linux-gnueabihf/libpng12.so.0 (0xb60cc000)
>         libpixman-1.so.0 => /usr/lib/arm-linux-gnueabihf/libpixman-1.so.0 
> (0xb6040000)
>         libxcb-shm.so.0 => /usr/lib/arm-linux-gnueabihf/libxcb-shm.so.0 
> (0xb6034000)
>         libxcb-render.so.0 => /usr/lib/arm-linux-gnueabihf/libxcb-render.so.0 
> (0xb6024000)
>         libxcb.so.1 => /usr/lib/arm-linux-gnueabihf/libxcb.so.1 (0xb6004000)
>         libthai.so.0 => /usr/lib/arm-linux-gnueabihf/libthai.so.0 (0xb5ff4000)
>         libexpat.so.1 => /lib/arm-linux-gnueabihf/libexpat.so.1 (0xb5fc8000)
>         libffi.so.5 => /usr/lib/arm-linux-gnueabihf/libffi.so.5 (0xb5fb4000)
>         libpcre.so.3 => /lib/arm-linux-gnueabihf/libpcre.so.3 (0xb5f70000)
>         libgraphite2.so.2.0.0 => /usr/lib/libgraphite2.so.2.0.0 (0xb5f54000)
>         libXau.so.6 => /usr/lib/arm-linux-gnueabihf/libXau.so.6 (0xb5f48000)
>         libXdmcp.so.6 => /usr/lib/arm-linux-gnueabihf/libXdmcp.so.6 
> (0xb5f3c000)
>         libdatrie.so.1 => /usr/lib/arm-linux-gnueabihf/libdatrie.so.1 
> (0xb5f2c000)
>
> Dell Green
> R&D Software Manager
> t: (+44)203 668 9870
>
>
>
>
> 206 Great Portland Street
> London W1W 5QJ
>
> This email and any files transmitted with it are confidential and intended 
> solely for the use of the individual or entity to whom they are addressed. If 
> you are not the intended recipient or the person responsible for delivering 
> the email to the intended recipient, be advised that you have received this 
> email in error and that any use, dissemination, forwarding, printing, or 
> copying of this email is strictly prohibited. Any views or opinions presented 
> are solely those of the author and do not necessarily represent those of 
> Ideaworks Limited. Ideaworks (London) Limited, 206 Great Portland Street, 
> London, W1W 5QJ. Company Registration No. 3943726
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 8 Dec 2015 12:03:10 -0500
> From: Morris Meyer <morris.me...@oracle.com>
> To: vadim.pakhnus...@oracle.com, Kevin Rushforth
>         <kevin.rushfo...@oracle.com>,   "openjfx-dev@openjdk.java.net"
>         <openjfx-dev@openjdk.java.net>
> Subject: [9] Review request for JDK-8144789: Incorrect assertion fails
>         in the  GlassCursor.m
> Message-ID: <56670d4e.6080...@oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Vadim and Kevin,
>
> Please review this fix for the GlassCursor.m assertion failure.
>
> Thanks,
>
>          --morris
>
> WEBREV - http://cr.openjdk.java.net/~morris/JDK-8144780.01a
> BUG - https://bugs.openjdk.java.net/browse/JDK-8144780
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 08 Dec 2015 12:26:08 -0500
> From: David Hill <david.h...@oracle.com>
> To: openjfx-dev@openjdk.java.net
> Subject: Re: OpenJFX armv6hf libjavafx_font_freetype.so x11
> Message-ID: <566712b0.4020...@oracle.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 12/8/15, 9:25 AM, Dell Green wrote:
> >
> > Hi Guys,
> >
> > Is it correct that  ?libjavafx_font_freetype.so?  be linked against X 
> > libraries? as our embedded guys who are running without X were surprised to 
> > see this as they are running without X using monocle and frame buffer 
> > platforms on raspberry pi and MX6? Do we meet to install X11 if running in 
> > frame buffer modes?
>
> This is a false dependency that appears to have crept back in, and I did not 
> notice because I have both X11 and framebuffer setup for testing. The 
> pkg_config files for a number of these libs we use pack a few extra libs to 
> be "helpful"
>
> This will take me a day or so to resolve. I filed 
> https://bugs.openjdk.java.net/browse/JDK-8144942 against it.
>
> Dave
>
> >
> >
> > libjavafx_font_freetype.so:
> >        libdl.so.2 =>  /lib/arm-linux-gnueabihf/libdl.so.2 (0xb6f68000)
> >        libgtk-x11-2.0.so.0 =>  
> >/usr/lib/arm-linux-gnueabihf/libgtk-x11-2.0.so.0 (0xb6bc0000)
> >        libgdk-x11-2.0.so.0 =>  
> >/usr/lib/arm-linux-gnueabihf/libgdk-x11-2.0.so.0 (0xb6b24000)
> >        libatk-1.0.so.0 =>  /usr/lib/arm-linux-gnueabihf/libatk-1.0.so.0 
> >(0xb6b00000)
> >        libgio-2.0.so.0 =>  /usr/lib/arm-linux-gnueabihf/libgio-2.0.so.0 
> >(0xb69c0000)
> >        libpangoft2-1.0.so.0 =>  
> >/usr/lib/arm-linux-gnueabihf/libpangoft2-1.0.so.0 (0xb69a4000)
> >        libpangocairo-1.0.so.0 =>  
> >/usr/lib/arm-linux-gnueabihf/libpangocairo-1.0.so.0 (0xb6990000)
> >        libgdk_pixbuf-2.0.so.0 =>  
> >/usr/lib/arm-linux-gnueabihf/libgdk_pixbuf-2.0.so.0 (0xb696c000)
> >        libcairo.so.2 =>  /usr/lib/arm-linux-gnueabihf/libcairo.so.2 
> >(0xb6890000)
> >        libpango-1.0.so.0 =>  /usr/lib/arm-linux-gnueabihf/libpango-1.0.so.0 
> >(0xb6844000)
> >        libfreetype.so.6 =>  /usr/lib/arm-linux-gnueabihf/libfreetype.so.6 
> >(0xb67b8000)
> >        libfontconfig.so.1 =>  
> >/usr/lib/arm-linux-gnueabihf/libfontconfig.so.1 (0xb6780000)
> >        libgobject-2.0.so.0 =>  
> >/usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0 (0xb6730000)
> >        libgthread-2.0.so.0 =>  
> >/usr/lib/arm-linux-gnueabihf/libgthread-2.0.so.0 (0xb6724000)
> >        librt.so.1 =>  /lib/arm-linux-gnueabihf/librt.so.1 (0xb6714000)
> >        libglib-2.0.so.0 =>  /lib/arm-linux-gnueabihf/libglib-2.0.so.0 
> >(0xb6620000)
> >        libXtst.so.6 =>  /usr/lib/arm-linux-gnueabihf/libXtst.so.6 
> >(0xb6614000)
> >        libstdc++.so.6 =>  /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 
> >(0xb6540000)
> >        libm.so.6 =>  /lib/arm-linux-gnueabihf/libm.so.6 (0xb64cc000)
> >        libgcc_s.so.1 =>  /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb64a4000)
> >        libpthread.so.0 =>  /lib/arm-linux-gnueabihf/libpthread.so.0 
> >(0xb6484000)
> >        libc.so.6 =>  /lib/arm-linux-gnueabihf/libc.so.6 (0xb6354000)
> >        /lib/ld-linux-armhf.so.3 (0xb6f94000)
> >        libX11.so.6 =>  /usr/lib/arm-linux-gnueabihf/libX11.so.6 (0xb6240000)
> >        libXcomposite.so.1 =>  
> >/usr/lib/arm-linux-gnueabihf/libXcomposite.so.1 (0xb6234000)
> >        libXdamage.so.1 =>  /usr/lib/arm-linux-gnueabihf/libXdamage.so.1 
> >(0xb6228000)
> >        libXfixes.so.3 =>  /usr/lib/arm-linux-gnueabihf/libXfixes.so.3 
> >(0xb6218000)
> >        libXext.so.6 =>  /usr/lib/arm-linux-gnueabihf/libXext.so.6 
> >(0xb6200000)
> >        libXrender.so.1 =>  /usr/lib/arm-linux-gnueabihf/libXrender.so.1 
> >(0xb61f0000)
> >        libXinerama.so.1 =>  /usr/lib/arm-linux-gnueabihf/libXinerama.so.1 
> >(0xb61e4000)
> >        libXi.so.6 =>  /usr/lib/arm-linux-gnueabihf/libXi.so.6 (0xb61d0000)
> >        libXrandr.so.2 =>  /usr/lib/arm-linux-gnueabihf/libXrandr.so.2 
> >(0xb61c0000)
> >        libXcursor.so.1 =>  /usr/lib/arm-linux-gnueabihf/libXcursor.so.1 
> >(0xb61b0000)
> >        libgmodule-2.0.so.0 =>  
> >/usr/lib/arm-linux-gnueabihf/libgmodule-2.0.so.0 (0xb61a4000)
> >        libz.so.1 =>  /lib/arm-linux-gnueabihf/libz.so.1 (0xb6184000)
> >        libselinux.so.1 =>  /lib/arm-linux-gnueabihf/libselinux.so.1 
> >(0xb6160000)
> >        libresolv.so.2 =>  /lib/arm-linux-gnueabihf/libresolv.so.2 
> >(0xb614c000)
> >        libharfbuzz.so.0 =>  /usr/lib/arm-linux-gnueabihf/libharfbuzz.so.0 
> >(0xb60f4000)
> >        libpng12.so.0 =>  /lib/arm-linux-gnueabihf/libpng12.so.0 (0xb60cc000)
> >        libpixman-1.so.0 =>  /usr/lib/arm-linux-gnueabihf/libpixman-1.so.0 
> >(0xb6040000)
> >        libxcb-shm.so.0 =>  /usr/lib/arm-linux-gnueabihf/libxcb-shm.so.0 
> >(0xb6034000)
> >        libxcb-render.so.0 =>  
> >/usr/lib/arm-linux-gnueabihf/libxcb-render.so.0 (0xb6024000)
> >        libxcb.so.1 =>  /usr/lib/arm-linux-gnueabihf/libxcb.so.1 (0xb6004000)
> >        libthai.so.0 =>  /usr/lib/arm-linux-gnueabihf/libthai.so.0 
> >(0xb5ff4000)
> >        libexpat.so.1 =>  /lib/arm-linux-gnueabihf/libexpat.so.1 (0xb5fc8000)
> >        libffi.so.5 =>  /usr/lib/arm-linux-gnueabihf/libffi.so.5 (0xb5fb4000)
> >        libpcre.so.3 =>  /lib/arm-linux-gnueabihf/libpcre.so.3 (0xb5f70000)
> >        libgraphite2.so.2.0.0 =>  /usr/lib/libgraphite2.so.2.0.0 (0xb5f54000)
> >        libXau.so.6 =>  /usr/lib/arm-linux-gnueabihf/libXau.so.6 (0xb5f48000)
> >        libXdmcp.so.6 =>  /usr/lib/arm-linux-gnueabihf/libXdmcp.so.6 
> >(0xb5f3c000)
> >        libdatrie.so.1 =>  /usr/lib/arm-linux-gnueabihf/libdatrie.so.1 
> >(0xb5f2c000)
> >
> > Dell Green
> > R&D Software Manager
> > t: (+44)203 668 9870
> >
> >
> >
> >
> > 206 Great Portland Street
> > London W1W 5QJ
> >
> > This email and any files transmitted with it are confidential and intended 
> > solely for the use of the individual or entity to whom they are addressed. 
> > If you are not the intended recipient or the person responsible for 
> > delivering the email to the intended recipient, be advised that you have 
> > received this email in error and that any use, dissemination, forwarding, 
> > printing, or copying of this email is strictly prohibited. Any views or 
> > opinions presented are solely those of the author and do not necessarily 
> > represent those of Ideaworks Limited. Ideaworks (London) Limited, 206 Great 
> > Portland Street, London, W1W 5QJ. Company Registration No. 3943726
>
>
> -- 
> David Hill<david.h...@oracle.com>
> Java Embedded Development
>
> "A man's feet should be planted in his country, but his eyes should survey 
> the world."
> -- George Santayana (1863 - 1952)
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 8 Dec 2015 18:37:45 +0100
> From: Tom Schindl <tom.schi...@bestsolution.at>
> To: Rahman USTA <rahman.usta...@gmail.com>,
>         "openjfx-dev@openjdk.java.net" <openjfx-dev@openjdk.java.net>
> Subject: Re: Why there is no WebWorker like mechanism for JavaFX
> Message-ID: <56671569.3050...@bestsolution.at>
> Content-Type: text/plain; charset=windows-1252
>
> Let's bring this back on the list - i once more accidentally replied
> just to you.
>
> IMHO if you want to execute javascript which is not related to a
> browser/html you should run that in a javascript vm like nashorn, ...
> and not through the WebView.
>
> Tom
>
> On 08.12.15 15:39, Rahman USTA wrote:
> > I handled the issue by using WebWorker in WebView, my main suggestion is
> > about JavaFX's threading model, not for a workaround.
> > 
> > I can try j2v8 if it supports Java Scripting API
> > 
> > Thanks.
> > 
> > 2015-12-08 16:24 GMT+02:00 Tom Schindl <tom.schi...@bestsolution.at
> > <mailto:tom.schi...@bestsolution.at>>:
> > 
> >     Use j2v8 - it is insanely fast as long as you don't do a lot
> >     java->js->java calls which you don't
> >     https://github.com/eclipsesource/j2v8
> > 
> >     Tom
> > 
> >     Von meinem iPhone gesendet
> > 
> >     > Am 08.12.2015 um 14:17 schrieb Rahman USTA
> >     <rahman.usta...@gmail.com <mailto:rahman.usta...@gmail.com>>:
> >     >
> >     > Yes your suggestion is OK in theory but in practice, Nashorn is
> >     too slow
> >     > without Warmup. I can say Nashorn is 5x to 10x slower than
> >     embedded webkit
> >     > to run script.
> >     >
> >     > 2015-12-08 15:09 GMT+02:00 Benjamin Gudehus <hasteb...@gmail.com
> >     <mailto:hasteb...@gmail.com>>:
> >     >
> >     >> The JavaFX API offers Worker class for long running tasks.
> >     >>
> >     >> If you want to execute JavaScript code without DOM and JavaFX you
> >     can use
> >     >> the Nashorn JS Virtual machine, which is included in Java 8. I
> >     guess the
> >     >> Nashorn documentation also has examples how it's used with the Java
> >     >> scripting API.
> >     >>> On Dec 8, 2015 1:50 PM, "Rahman USTA" <rahman.usta...@gmail.com
> >     <mailto:rahman.usta...@gmail.com>> wrote:
> >     >>>
> >     >>> I'm really enjoying developing apps in JavaFX, but I think there
> >     is a
> >     >>> limitation point;
> >     >>>
> >     >>> When we think HTML5, there is WebWorker to run long-running tasks in
> >     >>> another process. So, we know WebWorker has no DOM access, it is
> >     generally
> >     >>> used computational needs.
> >     >>>
> >     >>> Ok, We can run long-running tasks in JavaFX with many threading
> >     services,
> >     >>> but there is one exception;
> >     >>>
> >     >>> There are a lot of JavaScript libraries, and executing them in
> >     WebView
> >     >>> needs JavaFX Application Thread. But, what if your JS code takes
> >     long time
> >     >>> to execute ? Your UI will hang. Is it required to execute JS code in
> >     >>> WebView if it is not accessing DOM API?
> >     >>>
> >     >>> Thanks.
> >     >>>
> >     >>> --
> >     >>> Rahman USTA
> >     >>> Istanbul JUG
> >     >>> https://github.com/rahmanusta <http://www.kodcu.com/>
> >     >
> >     >
> >     > --
> >     > Rahman USTA
> >     > Istanbul JUG
> >     > https://github.com/rahmanusta <http://www.kodcu.com/>
> > 
> > 
> > 
> > 
> > -- 
> > Rahman USTA
> > Istanbul JUG
> > https://github.com/rahmanusta <http://www.kodcu.com/>
>
>
> -- 
> Thomas Schindl, CTO
> BestSolution.at EDV Systemhaus GmbH
> Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
> http://www.bestsolution.at/
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 8 Dec 2015 20:54:52 +0100
> From: Mike Hearn <m...@plan99.net>
> To: Markus KARG <mar...@headcrashing.eu>
> Cc: "openjfx-dev@openjdk.java.net" <openjfx-dev@openjdk.java.net>
> Subject: Re: Future of JavaFX
> Message-ID:
>         <CANEZrP0if=ter_N5ZC3z=qwNOdSLRSZh057S=_nm4+pmadl...@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> I'm pretty surprised by this thread.
>
> Guys, JavaFX is a widget toolkit. That's it, that's all it is. GUIs haven't
> changed that much in their general design and capabilities for decades now,
> probably the last major 'innovations' being things like the MS Office
> Ribbon.
>
> JFX has all the capabilities I'd hope for in a widget toolkit, plus a lot
> more. As a bonus it's open source and cross platform, with a full time team
> of developers. Just take a moment to appreciate that for a second! What's
> the competition? Qt and that's about it, right?
>
> Software can always be better, but this hysteria over "zomg oracle is
> abandoning us!" doesn't seem justified. Even if all Oracle did from now on
> was fix bugs and keep it working as the underlying platforms evolve, OK,
> it's an open source library with people paid to fix bugs. That's still
> better than many of the open source libraries I depend on!
>
> But they aren't just fixing bugs, they're also making enhancements. Yes,
> Java 9 is going to be boring because Jigsaw is forcing Team FX to go pay
> off some technical debt by making previously private-but-used APIs public.
> OK, fine, that amounts to new features for all 3 of you that weren't
> cheating previously ;)
>
> Beyond that, the fact that "draggable tabs" is the most user visible
> feature planned says to me what I already felt  - JavaFX is pretty mature.
> It'd be nice if Scene Builder was being officially distributed again, and I
> find the decision not do so baffling (perhaps they're assuming IDE makers
> will take it off their hands), but the app is still out there and still
> works. I suspect once the Jigsaw changes are finished off further
> enhancements will be things like better performance, maybe some new
> effects, etc. Nice to haves but not essentials.
>
> IMO the biggest pain-point now isn't even GUI related stuff, it's the lack
> of a modern replacement for Java Web Start. I made UpdateFX to try and fill
> this hole but it's not as good as something that a skilled full time dev
> with 6 months on hand would make.
>
>
> On Sat, Dec 5, 2015 at 9:56 AM, Markus KARG <mar...@headcrashing.eu> wrote:
>
> > JavaFX support for multi-resolution images is really a killer feature, as
> > it simply is ridiculous how small images render on HiDPI that are scaled
> > for LowDPI.
> >
> > For JDK 10, I'd kindly ask to review the list of essentials that I sent
> > you some months back by personal mail.
> >
> > -Markus
> >
> > -----Original Message-----
> > From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf
> > Of Kevin Rushforth
> > Sent: Mittwoch, 2. Dezember 2015 01:29
> > To: openjfx-dev@openjdk.java.net
> > Subject: Re: Future of JavaFX
> >
> > Just to chime in on a couple of points that have been raised in this
> > discussion...
> >
> > * We are interested in working with the OpenJFX community to improve
> > JavaFX. In particular: if you find a bug, file it (via bugs.java.com if
> > you don't have a JBS account); if you want to contribute a patch to fix the
> > bug, we'd love to review it; if you have an idea for an improvement, file
> > it as an RFE (enhancement) and start up a thread on the mailing list.
> > Larger features need a JEP, but smaller improvements do not.
> >
> > Please be aware that as part of the OpenJDK community, we are bound by the
> > processes of the OpenJDK, including the need for a signed OCA in order to
> > contribute, and before you can get a JBS account. If you are dissatisfied
> > with those processes and policies, then I invite you to discuss it on the
> > disc...@openjdk.java.net alias, and not here.
> >
> >
> > * While we aren't planning a huge number of features in JDK 9, we are
> > delivering some interesting improvements. Jigsaw is the big release driver
> > and most of our effort on JavaFX is to align with that. For those of you
> > who weren't at JavaOne, here is a list of things that are currently planned
> > for JDK 9:
> >
> > - A modularized JavaFX (into 6 core modules + deploy, swing interop, swt
> > interop)
> >
> > - JEP 253 -- Control Skins & additional CSS APIs (proper support for
> > third-party controls)
> >
> > - High DPI enhancements (full support on Windows; add support for Linux)
> >
> > - Public API for commonly used methods from internal packages:
> >     * Nested Event Loop
> >     * Pulse Listener
> >     * Platform Startup
> >     * Text API (HitTest, etc)
> >     * Static utility functions (under investigation)
> >
> > - New versions of WebKit and GStreamer
> >
> > And here is an incomplete list of things we are thinking about for after
> > JDK 9, possibly in an update release. In fact, the recently proposed JDK
> > 9 slip [1] makes it possible to consider pulling a few of them into JDK 9,
> > so let us know which ones you consider most important:
> >
> > - Provide a JavaFX equivalent for JEP 272 / AWT ?Desktop? API
> >
> > - Make UI Control Behaviors public
> >
> > - UI Control Actions API
> >
> > - Public Focus Traversal API
> >
> > - JavaFX support for multi-resolution images
> >
> > - Draggable tabs
> >
> > - Image IO
> >
> >
> > -- Kevin
> >
> > [1]
> > http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-December/003149.html
> >
> >
> >
>
>
> End of openjfx-dev Digest, Vol 49, Issue 17
> *******************************************



206 Great Portland Street
London W1W 5QJ

This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you are not the intended recipient or the person responsible for delivering the 
email to the intended recipient, be advised that you have received this email 
in error and that any use, dissemination, forwarding, printing, or copying of 
this email is strictly prohibited. Any views or opinions presented are solely 
those of the author and do not necessarily represent those of Ideaworks 
Limited. Ideaworks (London) Limited, 206 Great Portland Street, London, W1W 
5QJ. Company Registration No. 3943726

Reply via email to