RE: [9] Review request for 8143894 : clipboard paste on outlook email body doesn't work for the first time

[Guru Hb]

Hi Arunprasad, Alexander and Kevin, 

JBS : https://bugs.openjdk.java.net/browse/JDK-8143894/
Webrev : http://cr.openjdk.java.net/~arapte/ghb/8143894/webrev.01/ 

(Due to permission bit corrupted to my g...@cr.openjdk.java.net account I am 
sending this patch from ~arapte account) 

Fix updated with regression test 

Thanks, 
Guru
-Original Message-
From: Guru Hb 
Sent: Tuesday, December 01, 2015 10:29 AM
To: Arunprasad Rajkumar; Alexander Zvegintsev; Kevin Rushforth
Cc: openjfx-dev@openjdk.java.net
Subject: [9] Review request for 8143894 : clipboard paste on outlook email body 
doesn't work for the first time

Hi Arunprasad, Alexander & Kevin, 

JBS : https://bugs.openjdk.java.net/browse/JDK-8143894/ 
Webrev : http://cr.openjdk.java.net/~ghb/8143894/webrev.00 

Tested on Windows and Linux (both 64 bit).

Thnaks, 
Guru

Why there is no WebWorker like mechanism for JavaFX

[Rahman USTA]

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 

Re: Why there is no WebWorker like mechanism for JavaFX

[Benjamin Gudehus]

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"  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 
>

Re: Why there is no WebWorker like mechanism for JavaFX

[Rahman USTA]

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 :

> 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"  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 
>>
>


-- 
Rahman USTA
Istanbul JUG
https://github.com/rahmanusta 

JDK-8090029: NullPointerException in DatePicker when a custom ButtonSkin is set - possible backport to JDK 8?

[Boström Kacper]

Hello,

Since the shutdown of the official JavaFX Jira one has been unable to 
comment/discus ongoing or resolved bugs. So I've turned to this mailing list in 
hope that I came to the right place and if not please do point me in the right 
direction.

I would like to request the backport of the fix for JDK-8090029. Since Java 9 
won't be here until 2017 it would be beneficial if the fix could be backported.

Regards,
Kacper

Re: JDK-8090029: NullPointerException in DatePicker when a custom ButtonSkin is set - possible backport to JDK 8?

[Kevin Rushforth]

In general, we will only backport to 8 fixes for critical bugs, 
regressions, and a few others with safe, simple fixes. This bug meets 
that criteria, so I have created a backport issue for it.


-- Kevin


Boström Kacper wrote:

Hello,

Since the shutdown of the official JavaFX Jira one has been unable to 
comment/discus ongoing or resolved bugs. So I've turned to this mailing list in 
hope that I came to the right place and if not please do point me in the right 
direction.

I would like to request the backport of the fix for JDK-8090029. Since Java 9 
won't be here until 2017 it would be beneficial if the fix could be backported.

Regards,
Kacper
  

OpenJFX armv6hf libjavafx_font_freetype.so x11

[Dell Green]

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 
(0xb6bc)
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 
(0xb6b0)
libgio-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgio-2.0.so.0 
(0xb69c)
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 (0xb699)
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 (0xb689)
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 
(0xb678)
libgobject-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0 
(0xb673)
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 
(0xb662)
libXtst.so.6 => /usr/lib/arm-linux-gnueabihf/libXtst.so.6 (0xb6614000)
libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 
(0xb654)
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 (0xb624)
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 (0xb620)
libXrender.so.1 => /usr/lib/arm-linux-gnueabihf/libXrender.so.1 
(0xb61f)
libXinerama.so.1 => /usr/lib/arm-linux-gnueabihf/libXinerama.so.1 
(0xb61e4000)
libXi.so.6 => /usr/lib/arm-linux-gnueabihf/libXi.so.6 (0xb61d)
libXrandr.so.2 => /usr/lib/arm-linux-gnueabihf/libXrandr.so.2 
(0xb61c)
libXcursor.so.1 => /usr/lib/arm-linux-gnueabihf/libXcursor.so.1 
(0xb61b)
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 (0xb616)
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 
(0xb604)
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 (0xb5f7)
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 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 

[9] Review request for 8144922: [packager] intermittent test failures

[Dmitry Cherepanov]

Chris,

Please review the following fix

https://bugs.openjdk.java.net/browse/JDK-8144922
http://cr.openjdk.java.net/~dcherepanov/8144922/webrev.v0/

Thanks,

Dmitry

[9] Review request for JDK-8144789: Incorrect assertion fails in the GlassCursor.m

[Morris Meyer]

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

Re: OpenJFX armv6hf libjavafx_font_freetype.so x11

[David Hill]

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 (0xb6bc)
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 
(0xb6b0)
libgio-2.0.so.0 =>  /usr/lib/arm-linux-gnueabihf/libgio-2.0.so.0 
(0xb69c)
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 (0xb699)
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 
(0xb689)
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 
(0xb678)
libgobject-2.0.so.0 =>  
/usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0 (0xb673)
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 
(0xb662)
libXtst.so.6 =>  /usr/lib/arm-linux-gnueabihf/libXtst.so.6 (0xb6614000)
libstdc++.so.6 =>  /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 
(0xb654)
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 (0xb624)
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 (0xb620)
libXrender.so.1 =>  /usr/lib/arm-linux-gnueabihf/libXrender.so.1 
(0xb61f)
libXinerama.so.1 =>  /usr/lib/arm-linux-gnueabihf/libXinerama.so.1 
(0xb61e4000)
libXi.so.6 =>  /usr/lib/arm-linux-gnueabihf/libXi.so.6 (0xb61d)
libXrandr.so.2 =>  /usr/lib/arm-linux-gnueabihf/libXrandr.so.2 
(0xb61c)
libXcursor.so.1 =>  /usr/lib/arm-linux-gnueabihf/libXcursor.so.1 
(0xb61b)
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 
(0xb616)
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 
(0xb604)
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 (0xb5f7)
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 =>  

Re: Why there is no WebWorker like mechanism for JavaFX

[Tom Schindl]

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  >:
> 
> 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
> >:
> >
> > 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  >:
> >
> >> 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"  > 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 
> >
> >
> > --
> > Rahman USTA
> > Istanbul JUG
> > https://github.com/rahmanusta 
> 
> 
> 
> 
> -- 
> Rahman USTA
> Istanbul JUG
> https://github.com/rahmanusta 


-- 
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

Re: Future of JavaFX

[Mike Hearn]

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  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
>
>
>

Re: OpenJFX armv6hf libjavafx_font_freetype.so x11

[Dell Green]

 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 +


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

> From: Dell Green 
> To: "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 (0xb6bc)
>     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 
> (0xb6b0)
>     libgio-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgio-2.0.so.0 
> (0xb69c)
>     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 (0xb699)
>     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 
> (0xb689)
>     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 
> (0xb678)
>     libgobject-2.0.so.0 => 
> /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0 (0xb673)
>     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 
> (0xb662)
>     libXtst.so.6 => /usr/lib/arm-linux-gnueabihf/libXtst.so.6 (0xb6614000)
>     libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 
> (0xb654)
>     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 (0xb624)
>     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 (0xb620)
>     libXrender.so.1 => /usr/lib/arm-linux-gnueabihf/libXrender.so.1 
> (0xb61f)
>     libXinerama.so.1 => /usr/lib/arm-linux-gnueabihf/libXinerama.so.1 
> (0xb61e4000)
>     libXi.so.6 => /usr/lib/arm-linux-gnueabihf/libXi.so.6 (0xb61d)
>     libXrandr.so.2 => /usr/lib/arm-linux-gnueabihf/libXrandr.so.2 
> (0xb61c)
>     libXcursor.so.1 => /usr/lib/arm-linux-gnueabihf/libXcursor.so.1 
> (0xb61b)
>    

Re: OpenJFX armv6hf libjavafx_font_freetype.so x11

[David Hill]

On 12/8/15, 3:15 PM, Dell Green wrote:




  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?

When my fix goes in and you use the right binaries - then yes. In framebuffer 
mode, the design was for no X11.

If you are building your own OpenJFX, then the gist of the fix is in 
https://bugs.openjdk.java.net/browse/JDK-8144942
I have to resurrect my Pi to double check the resulting image before I will 
commit it, so it may be a day or so.

This was caused by a cut and paste error when I simplified the build script a 
while back, taking out the use of pkg-config in a cross compile environment - 
pasting in the results instead of running the problematic script. Problem was I 
pasted the wrong variable name... :-o

Dave


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 theGlassCursor.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 +


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


From: Dell Green
To: "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 (0xb6bc)
 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 
(0xb6b0)
 libgio-2.0.so.0 =>  /usr/lib/arm-linux-gnueabihf/libgio-2.0.so.0 
(0xb69c)
 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 (0xb699)
 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 
(0xb689)
 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 
(0xb678)
 libgobject-2.0.so.0 =>  
/usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0 (0xb673)
 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 
(0xb662)
 libXtst.so.6 =>  /usr/lib/arm-linux-gnueabihf/libXtst.so.6 (0xb6614000)
 libstdc++.so.6 =>  /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 
(0xb654)
 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 (0xb624)
 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 =>  

Code Review Request For JDK-8091170: Compile-time warnings in prism-es2 code

[Chien Yang]

Hi Kevin,

Please review the proposed fix which was moved from JDK-8090866 as per 
our conversation:


JIRA: https://bugs.openjdk.java.net/browse/JDK-8091170
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8091170/webrev.00/

Thanks,
- Chien

Re: OpenJFX armv6hf libjavafx_font_freetype.so x11

[Dell Green]

OK great many thanks. I can wait a few days  until your happy with your changes 
and commit them. ☺

Dell Green
R 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

RE: [9] Review request for 8143894 : clipboard paste on outlook email body doesn't work for the first time

[Guru Hb]

Fixed Test failure on MAC 
Webrev : http://cr.openjdk.java.net/~ghb/8143894/webrev.02/ 
Tested on Windows , Linux and Mac 

Thanks, 
Guru

-Original Message-
From: Guru Hb 
Sent: Tuesday, December 08, 2015 4:08 PM
To: Arunprasad Rajkumar; Alexander Zvegintsev; Kevin Rushforth
Cc: openjfx-dev@openjdk.java.net; Ankit Srivastava; Murali Billa
Subject: RE: [9] Review request for 8143894 : clipboard paste on outlook email 
body doesn't work for the first time

Hi Arunprasad, Alexander and Kevin, 

JBS : https://bugs.openjdk.java.net/browse/JDK-8143894/
Webrev : http://cr.openjdk.java.net/~arapte/ghb/8143894/webrev.01/ 

(Due to permission bit corrupted to my g...@cr.openjdk.java.net account I am 
sending this patch from ~arapte account) 

Fix updated with regression test 

Thanks, 
Guru
-Original Message-
From: Guru Hb 
Sent: Tuesday, December 01, 2015 10:29 AM
To: Arunprasad Rajkumar; Alexander Zvegintsev; Kevin Rushforth
Cc: openjfx-dev@openjdk.java.net
Subject: [9] Review request for 8143894 : clipboard paste on outlook email body 
doesn't work for the first time

Hi Arunprasad, Alexander & Kevin, 

JBS : https://bugs.openjdk.java.net/browse/JDK-8143894/ 
Webrev : http://cr.openjdk.java.net/~ghb/8143894/webrev.00 

Tested on Windows and Linux (both 64 bit).

Thnaks, 
Guru