Re: Review Request: RT-39975 - AppCDS support for packager

[Chris Bensen]

+1

On Mar 30, 2015, at 3:11 PM, Danno Ferrin  wrote:

> Kevin, Chris, please review
> 
> jira: https://javafx-jira.kenai.com/browse/RT-39975
> webrev: http://cr.openjdk.java.net/~shemnon/RT-39975/webrev.00/

Review Request: RT-39975 - AppCDS support for packager

[Danno Ferrin]

Kevin, Chris, please review

jira: https://javafx-jira.kenai.com/browse/RT-39975
webrev: http://cr.openjdk.java.net/~shemnon/RT-39975/webrev.00/

9-dev and 8u-dev unlocked + reminder about pushing changesets

[Kevin Rushforth]

The 9-dev and 8u-dev repos are unlocked. As a reminder, please note the 
following.


All changesets that were pushed to 8u-dev prior to 1am this morning are 
already in 9-dev.


Starting now, bug fixes go into 9-dev first and then to 8u-dev -- or 
else pushed at the same time if they are safe, simple fixes. 
Enhancements / features go into 9-dev only unless there is an explicit 
exception approved to backport them to 8u60 (note that API changes for 9 
still require approval). See the following Wiki pages:


https://wiki.openjdk.java.net/display/OpenJFX/8u60
https://wiki.openjdk.java.net/display/OpenJFX/9

Let me know if there are any questions about this.

-- Kevin

Re: Canvas performance on Mac OS

[Jim Graham]

On 3/30/15 12:04 PM, Jim Graham wrote:

drawPolygon() is a very complex operation that involves things like:

- dealing with only rendering common points of intersection once


An example of the distinction here - try a test case where you execute 
the exact same diagonal line primitive 1,000 times on top of itself 
(identical coordinates for all of them).


Then change the example to use a Polygon that goes from point A to point 
B and back, over itself 1,000 times.


The result of all of those lines will have jagged edges even though the 
lines themselves are antialiased because the partially filled pixels 
along the edges slowly accumulate opacity until their carefully blended 
edges get lost in the accumulated error.


The result of the polygon will be identical to just drawing an 
antialiased line from point A to point B because it is turned into a 
single coverage result by the software rasterizer.


Another similar example - set an opacity of 0.1 on all of those 
rendering calls.  The (multi-)drawLine example will look like an opaque 
line of 1.0 opacity, but the polygon will still look like it has an 
opacity of 0.1 because the coverages are accumulated across the entire 
polygon before any rendering occurs and so each pixel is only blended 
once...


...jim

Re: Packaging a JFX app in a gradle build system

[Danno Ferrin]

Yes, bitbucket is the main repo, github is a mirror (currently out of date).

(sorry for the late response, just got back from a long spring break).

> On Mar 28, 2015, at 9:30 AM, Scott Palmer  wrote:
> 
> I believe the bitbucket repo is the main page. At least the bintray page 
> points to it.
> 
> Scott
> 
> On Mar 28, 2015, at 11:10 AM, Robert Krüger  > wrote:
> 
>> Which repository is the master? Bitbucket or github? I just saw a posting by 
>> someone mentioning that it is also on github.
>> 
>> On Fri, Mar 27, 2015 at 7:27 AM, Robert Krüger > > wrote:
>> On Fri, Mar 27, 2015 at 12:16 AM, Scott Palmer > > wrote:
>> I am successfully using the javafx gradle plugin to produce a packaged app 
>> on Windows and Linux. (Thanks Danno!)
>> I haven't tried much with Mac yet, but I believe it will make an application 
>> bundle.
>> 
>> 
>> That sounds great. I will give it a try on OSX then.
>>  
>> Oracle should be making this part of your day job, Danno.  Who do I need to 
>> bribe? :-)
>> 
>> 
>> Absolutely! Easy packaging (i.e. well integrated into a build process), 
>> especially if it's cross-platform, is a big thing to make JavaFX more 
>> attractive to developers. 
>> 
>> 
>> 
>> -- 
>> Robert Krüger
>> Managing Partner
>> Lesspain GmbH & Co. KG
>> 
>> www.lesspain-software.com 

Re: Canvas performance on Mac OS

[Jim Graham]

Hi Chris,

drawLine() is a very simple primitive that can be optimized with a GPU 
shader.  It either looks like a (potentially rotated) rectangle or a 
rounded rect - and we have optimized shaders for both cases.  A large 
number of drawLine() calls turns into simply accumulating a large vertex 
list and uploading it to the GPU with an appropriate shader which is 
very fast.


drawPolygon() is a very complex operation that involves things like:

- dealing with line joins between segments that don't exist for drawLine()
- dealing with only rendering common points of intersection once

To handle all of that complexity we have to involve a rasterizer that 
takes the entire collection of lines, analyzes the stroke attributes and 
interactions and computes a coverage mask for each pixel in the region. 
 We do that in software currently for all pipelines.


For the ES2 pipeline Line.v.Poly is dominated by pure GPU vs CPU path 
rasterization.


For the SW pipeline, drawLine is a simplified case of drawPolygon and so 
the overhead of lots of calls to drawLine() dominates its performance.


I would expect ES2 to blow the SW pipeline out of the water with 
drawLine() performance (as long as there are no additional rendering 
primitives interspersed in the set of lines).


But, both should be on the same footing for the drawPolygon case.  Does 
the ES2 pipeline compare similarly (hopefully better than) the SW 
pipeline for the polygon case?


One thing I noticed is that we have no optimized case for drawLine() on 
the SW pipeline.  It generates a path containing a single MOVETO and 
LINETO and feeds it to the generalized path rasterizer when it could 
instead compute the rounded/square rectangle and render it more 
directly.  If we added that support then I'd expect the SW pipeline to 
perform the set of drawLine calls faster than drawPolygon as well...


...jim

On 3/28/15 3:22 AM, Chris Newland wrote:

Hi Robert,

I've not filed a Jira yet as I was hoping to find time to investigate
thoroughly but when I saw your question I thought I'd better add my
findings.

I believe the issue is in the ES2Pipeline as if I run with
-Dprism.order=sw then strokePolygon outperforms the series of strokeLine
commands as expected:

java -cp target/DemoFX.jar -Dprism.order=sw
com.chrisnewland.demofx.DemoFXApplication -c 500 -m line
Result: 44fps

java -cp target/DemoFX.jar -Dprism.order=sw
com.chrisnewland.demofx.DemoFXApplication -c 500 -m poly
Result: 60fps

Will see if I can find the root cause as I've got plenty more examples
where ES2Pipeline performs horribly on my Mac which should have no problem
throwing around a few thousand polys.

I realise there's a *lot* of indirection involved in making JavaFX support
such a wide range of underlying graphics systems but I do think there's a
bug here.

Will file a Jira if I can contribute a bit more than "feels slow" ;)

Cheers,

Chris

On Sat, March 28, 2015 10:06, Robert Krüger wrote:

This is consistent with what I am observing. Is this something that
Oracle
is aware of? Looking at Jira, I don't see that anyone is working on this:

https://javafx-jira.kenai.com/issues/?jql=status%20in%20(Open%2C%20%22In%
20Progress%22%2C%20Reopened)%20AND%20labels%20in%20(macosx)%20%20AND%20la
bels%20in%20(performance)

Given that one of the One of the main reasons to use JFX for me is to be
able to develop with one code base for at least OSX and Windows and the
official statement what JavaFX is for, i.e.

"JavaFX is a set of graphics and media packages that enables developers
to design, create, test, debug, and deploy rich client applications that
operate consistently across diverse platforms"

and the fact that this is clearly not the case currently (8u40) as soon
as I do something else than simple forms, I run into performance/quality
problems on the Mac, I am a bit unsure what to make of all that. Is Mac
OSX
a second-class citizen as far as dev resources are concerned?

Tobi and Chris, have you filed Jira Issues on Mac graphics performance
that can be tracked?

I will file an issue with a simple test case and hope for the best.





On Fri, Mar 27, 2015 at 11:08 PM, Chris Newland

wrote:



Possibly related:


I can reproduce a massive (90%) performance drop on OSX between drawing
a wireframe polygon on a Canvas using a series of gc.strokeLine(double
x1, double y1, double x2, double y2) commands versus using a single
gc.strokePolygon(double[] xPoints, double[] yPoints, int count)
command.

Creating the polygons manually with strokeLine() is significantly
faster using the ES2Pipeline on OSX.

This is reproducible in a little GitHub JavaFX benchmarking project
I've
created: https://github.com/chriswhocodes/DemoFX


Build with ant


Run with:


# use strokeLine
./run.sh -c 5000 -m line
result: 60 (sixty) fps


# use strokePolygon
./run.sh -c 5000 -m poly
result: 6 (six) fps


System is 2011 iMac 27" / Mavericks / 3.4GHz Core i7 / 20GB RAM /
Radeon
6970M 1024MB


Looking at the code p

Re: Questions/possible bugs about JDK 1.8.0 + OpenJFK on the PI 2

[David Hill]

On 3/26/15, 7:03 PM, Fabrizio Giudici wrote:

On Thu, 26 Mar 2015 19:40:41 +0100, Fabrizio Giudici 
 wrote:


The mouse is ok, it was probably a connection fault. The keyboard navigation of 
buttons is still not working - still investigating.


The keyboard is definitely not working with my app, even with a simple 
TextField. It does work with Ensemble8 and the same jre. My app works fine in 
Mac OS X. Sounds tricky...

Is there any logging option I can activate to investigate whether keystrokes 
are just not received, or they get lost somewhere?


Are you getting anything on the console ? Because monocle uses udev, you need 
to run as root or change some permissions stuff around.

Dave

--
David Hill
Java Embedded Development

"A man's feet should be planted in his country, but his eyes should survey the 
world."
-- George Santayana (1863 - 1952)

Re: Unit testing recommendations for JavaFX

[ngalarneau]

TestFX is nice.

Another option is QF-Test.


Neil



From:   Benjamin Gudehus 
To: Tom Eugelink , 
Cc: "openjfx-dev@openjdk.java.net" 
Date:   03/30/2015 08:29 AM
Subject:Re: Unit testing recommendations for JavaFX
Sent by:"openjfx-dev" 



There are also Automaton, which is similar to TestFX and supports Swing as
well, and MavinFX, which is especially useful to assert Properties.

TestFX allows simple and clean testing without much boiler-plate code. 
When
we took JavaFX into consideration for a migration of our geographical
information system to Swing to first thing we looked for was a testing
framework. With a background with the FEST-Swing testing framework TestFX
convinced us, because even testing new dialogs looked a lot easier than
with FEST.

I can't say much about Squish. It seems that it follows an approach with a
recorder for user interactions which I guess won't allow creation of
test-cases before the actual production code is written.

--Benjamin




On Sat, Mar 28, 2015 at 8:45 PM, Tom Eugelink  wrote:

> JFXtras uses TestFX (3), very pleasant, highly recommended.
>
>
>
> On 28-3-2015 09:13, Adam Granger wrote:
>
>> Following migration to JavaFX I've been looking into a unit testing...
>> Possible solutions
>>
>>   - "home brew" - just code up a few basic methods like "find a node 
with
>> given selector within given timeout", then build tests using those 
using
>> JUnit / Mockito. Also used @Rule approach from
>> http://stackoverflow.com/a/18988752/898289 for simple tests which 
didn't
>> require any asynchronous behaviour. I was previously using this 
approach
>> until discovered TestFX
>>
>>   -  Jemmy - seems well documented. Last release 4 years ago - no 
updates
>> since JavaFX 2.2? Is this because its so good, or does anyone know
>> whether it has been scrapped? Any plans to update for JavaFX 8?
>> https://jemmy.java.net/
>>
>>   - TestFX - just started dabbling with this - seems a lot better
>> maintained that Jemmy, however the new release 4 is still alpha and
>> documentation is a little sparse - https://github.com/TestFX/TestFX
>>
>>   - Squish by FrogLogic - commercial product, but only seems suitable 
for
>> integration level testing. -
>> 
http://doc.froglogic.com/squish/5.1/tutorial-getting-started-java_fx.html
>>
>> I'm interested in any recommendations this group might have or 
experiences
>> of solutions I've mentioned...  What solution do OpenJFX / other large 
FX
>> developments use for unit testing?
>>
>> Many thanks,
>>
>> Adam.
>>
>>
>



 
NOTICE from Ab Initio: This email (including any attachments) may contain 
information that is subject to confidentiality obligations or is legally 
privileged, and sender does not waive confidentiality or privilege. If 
received in error, please notify the sender, delete this email, and make 
no further use, disclosure, or distribution. 

Re: Unit testing recommendations for JavaFX

[Benjamin Gudehus]

There are also Automaton, which is similar to TestFX and supports Swing as
well, and MavinFX, which is especially useful to assert Properties.

TestFX allows simple and clean testing without much boiler-plate code. When
we took JavaFX into consideration for a migration of our geographical
information system to Swing to first thing we looked for was a testing
framework. With a background with the FEST-Swing testing framework TestFX
convinced us, because even testing new dialogs looked a lot easier than
with FEST.

I can't say much about Squish. It seems that it follows an approach with a
recorder for user interactions which I guess won't allow creation of
test-cases before the actual production code is written.

--Benjamin




On Sat, Mar 28, 2015 at 8:45 PM, Tom Eugelink  wrote:

> JFXtras uses TestFX (3), very pleasant, highly recommended.
>
>
>
> On 28-3-2015 09:13, Adam Granger wrote:
>
>> Following migration to JavaFX I've been looking into a unit testing...
>> Possible solutions
>>
>>   - "home brew" - just code up a few basic methods like "find a node with
>> given selector within given timeout", then build tests using those using
>> JUnit / Mockito. Also used @Rule approach from
>> http://stackoverflow.com/a/18988752/898289 for simple tests which didn't
>> require any asynchronous behaviour. I was previously using this approach
>> until discovered TestFX
>>
>>   -  Jemmy - seems well documented. Last release 4 years ago - no updates
>> since JavaFX 2.2? Is this because its so good, or does anyone know
>> whether it has been scrapped? Any plans to update for JavaFX 8?
>> https://jemmy.java.net/
>>
>>   - TestFX - just started dabbling with this - seems a lot better
>> maintained that Jemmy, however the new release 4 is still alpha and
>> documentation is a little sparse - https://github.com/TestFX/TestFX
>>
>>   - Squish by FrogLogic - commercial product, but only seems suitable for
>> integration level testing. -
>> http://doc.froglogic.com/squish/5.1/tutorial-getting-started-java_fx.html
>>
>> I'm interested in any recommendations this group might have or experiences
>> of solutions I've mentioned...  What solution do OpenJFX / other large FX
>> developments use for unit testing?
>>
>> Many thanks,
>>
>> Adam.
>>
>>
>

Re: Doubts on KeyCode

[Tom Schindl]

Hi,

I think I'll start to understand, when I type ] on a german keyboard I
have to use a modifier key (on OS-X ALT) but the keycode without
modifier is the one for the +.

Tom

On 30.03.15 13:56, Benjamin Gudehus wrote:
> Hi,
> 
>>What I can not explain is why the keyboard "+" (ascii-code 43) maps to
> "]" (ascii-code 93) from a native-keyevent to KeyCode happens in
> Glass-Layer.
> 
> Hmm, the "+" key on a german keyboard layout [1] is actually "]" on the
> us keyboard layout [2].
> 
> But when I type "+" on my german keyboard with german layout activated
> on Windows it outputs "+" as unicode string and "PLUS" for the KeyCode.
> With this code:
> 
> textField.setOnKeyPressed((event) -> {
> System.out.println(event.getText());
> System.out.println(event.getCode());
> });
> 
> [1]
> http://upload.wikimedia.org/wikipedia/commons/thumb/3/36/KB_Germany.svg/800px-KB_Germany.svg.png
> [2]
> http://upload.wikimedia.org/wikipedia/commons/thumb/5/51/KB_United_States-NoAltGr.svg/800px-KB_United_States-NoAltGr.svg.png
> 
> On Mon, Mar 30, 2015 at 1:19 PM, Scott Palmer  > wrote:
> 
> If I recall correctly there is one keycode named PLUS and another
> named ADD. One of them refers to the numeric keypad.
> 
> Scott
> 
> > On Mar 30, 2015, at 6:58 AM, Tom Schindl
> mailto:tom.schi...@bestsolution.at>>
> wrote:
> >
> > hi,
> >
> > suppose you have the following code:
> >
> >> package application;
> >>
> >> import javafx.application.Application;
> >> import javafx.scene.Scene;
> >> import javafx.scene.control.TextField;
> >> import javafx.scene.layout.BorderPane;
> >> import javafx.stage.Stage;
> >>
> >> public class Main extends Application {
> >>@Override
> >>public void start(Stage primaryStage) {
> >>try {
> >>BorderPane root = new BorderPane();
> >>Scene scene = new Scene(root, 400, 400);
> >>
> >>TextField f = new TextField();
> >>f.setOnKeyReleased( e -> {
> >>System.err.println(e.getCode());
> >>});
> >>root.setCenter(f);
> >>
> >>primaryStage.setScene(scene);
> >>primaryStage.show();
> >>} catch (Exception e) {
> >>e.printStackTrace();
> >>}
> >>}
> >>
> >>public static void main(String[] args) {
> >>launch(args);
> >>}
> >> }
> >
> > For default ASCII-Chars like a, b, c, ... I get the correct
> KeyCode but
> > e.g. for +, -, ... the information is totally bogus. Please note I get
> > the correct keyCode when pressing the NumPad char but e.g.
> CLOSE_BRACKET
> > when pressing "+" on my keyboard.
> >
> > If I'm not completely mistaken the KeyCode defintion for the current +
> > is the one for the keypad "+" and the one for the ordinary + is
> missing?
> >
> > This means that the definition:
> >
> > PLUS(0x0209, "Plus")
> >
> > has to be
> >
> > PLUS(0x0209, "Plus", KeyCodeClass.KEYPAD)
> >
> > What I can not explain is why the keyboard "+" (ascii-code 43) maps to
> > "]" (ascii-code 93) from a native-keyevent to KeyCode happens in
> > Glass-Layer.
> >
> > Tom
> >
> > --
> > 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
> 
> 


-- 
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: Doubts on KeyCode

[Tom Schindl]

Hi,

Yes there is an ADD and a PLUS but both of them claim that they are NOT
NUMPAD keyCodes.

ADD(0x6B, "Add"),
PLUS(0x0209, "Plus"),

>From the location I think ADD should be the a keypad type, when I type +
on my keypad I get ADD.

Tom

On 30.03.15 13:19, Scott Palmer wrote:
> If I recall correctly there is one keycode named PLUS and another named ADD. 
> One of them refers to the numeric keypad.
> 
> Scott
> 
>> On Mar 30, 2015, at 6:58 AM, Tom Schindl  wrote:
>>
>> hi,
>>
>> suppose you have the following code:
>>
>>> package application;
>>>
>>> import javafx.application.Application;
>>> import javafx.scene.Scene;
>>> import javafx.scene.control.TextField;
>>> import javafx.scene.layout.BorderPane;
>>> import javafx.stage.Stage;
>>>
>>> public class Main extends Application {
>>>@Override
>>>public void start(Stage primaryStage) {
>>>try {
>>>BorderPane root = new BorderPane();
>>>Scene scene = new Scene(root, 400, 400);
>>>
>>>TextField f = new TextField();
>>>f.setOnKeyReleased( e -> {
>>>System.err.println(e.getCode());
>>>});
>>>root.setCenter(f);
>>>
>>>primaryStage.setScene(scene);
>>>primaryStage.show();
>>>} catch (Exception e) {
>>>e.printStackTrace();
>>>}
>>>}
>>>
>>>public static void main(String[] args) {
>>>launch(args);
>>>}
>>> }
>>
>> For default ASCII-Chars like a, b, c, ... I get the correct KeyCode but
>> e.g. for +, -, ... the information is totally bogus. Please note I get
>> the correct keyCode when pressing the NumPad char but e.g. CLOSE_BRACKET
>> when pressing "+" on my keyboard.
>>
>> If I'm not completely mistaken the KeyCode defintion for the current +
>> is the one for the keypad "+" and the one for the ordinary + is missing?
>>
>> This means that the definition:
>>
>> PLUS(0x0209, "Plus")
>>
>> has to be
>>
>> PLUS(0x0209, "Plus", KeyCodeClass.KEYPAD)
>>
>> What I can not explain is why the keyboard "+" (ascii-code 43) maps to
>> "]" (ascii-code 93) from a native-keyevent to KeyCode happens in
>> Glass-Layer.
>>
>> Tom
>>
>> -- 
>> 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


-- 
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: Doubts on KeyCode

[Benjamin Gudehus]

Hi,

>What I can not explain is why the keyboard "+" (ascii-code 43) maps to
"]" (ascii-code 93) from a native-keyevent to KeyCode happens in
Glass-Layer.

Hmm, the "+" key on a german keyboard layout [1] is actually "]" on the us
keyboard layout [2].

But when I type "+" on my german keyboard with german layout activated on
Windows it outputs "+" as unicode string and "PLUS" for the KeyCode. With
this code:

textField.setOnKeyPressed((event) -> {
System.out.println(event.getText());
System.out.println(event.getCode());
});

[1]
http://upload.wikimedia.org/wikipedia/commons/thumb/3/36/KB_Germany.svg/800px-KB_Germany.svg.png
[2]
http://upload.wikimedia.org/wikipedia/commons/thumb/5/51/KB_United_States-NoAltGr.svg/800px-KB_United_States-NoAltGr.svg.png

On Mon, Mar 30, 2015 at 1:19 PM, Scott Palmer  wrote:

> If I recall correctly there is one keycode named PLUS and another named
> ADD. One of them refers to the numeric keypad.
>
> Scott
>
> > On Mar 30, 2015, at 6:58 AM, Tom Schindl 
> wrote:
> >
> > hi,
> >
> > suppose you have the following code:
> >
> >> package application;
> >>
> >> import javafx.application.Application;
> >> import javafx.scene.Scene;
> >> import javafx.scene.control.TextField;
> >> import javafx.scene.layout.BorderPane;
> >> import javafx.stage.Stage;
> >>
> >> public class Main extends Application {
> >>@Override
> >>public void start(Stage primaryStage) {
> >>try {
> >>BorderPane root = new BorderPane();
> >>Scene scene = new Scene(root, 400, 400);
> >>
> >>TextField f = new TextField();
> >>f.setOnKeyReleased( e -> {
> >>System.err.println(e.getCode());
> >>});
> >>root.setCenter(f);
> >>
> >>primaryStage.setScene(scene);
> >>primaryStage.show();
> >>} catch (Exception e) {
> >>e.printStackTrace();
> >>}
> >>}
> >>
> >>public static void main(String[] args) {
> >>launch(args);
> >>}
> >> }
> >
> > For default ASCII-Chars like a, b, c, ... I get the correct KeyCode but
> > e.g. for +, -, ... the information is totally bogus. Please note I get
> > the correct keyCode when pressing the NumPad char but e.g. CLOSE_BRACKET
> > when pressing "+" on my keyboard.
> >
> > If I'm not completely mistaken the KeyCode defintion for the current +
> > is the one for the keypad "+" and the one for the ordinary + is missing?
> >
> > This means that the definition:
> >
> > PLUS(0x0209, "Plus")
> >
> > has to be
> >
> > PLUS(0x0209, "Plus", KeyCodeClass.KEYPAD)
> >
> > What I can not explain is why the keyboard "+" (ascii-code 43) maps to
> > "]" (ascii-code 93) from a native-keyevent to KeyCode happens in
> > Glass-Layer.
> >
> > Tom
> >
> > --
> > 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: Doubts on KeyCode

[Scott Palmer]

If I recall correctly there is one keycode named PLUS and another named ADD. 
One of them refers to the numeric keypad.

Scott

> On Mar 30, 2015, at 6:58 AM, Tom Schindl  wrote:
> 
> hi,
> 
> suppose you have the following code:
> 
>> package application;
>> 
>> import javafx.application.Application;
>> import javafx.scene.Scene;
>> import javafx.scene.control.TextField;
>> import javafx.scene.layout.BorderPane;
>> import javafx.stage.Stage;
>> 
>> public class Main extends Application {
>>@Override
>>public void start(Stage primaryStage) {
>>try {
>>BorderPane root = new BorderPane();
>>Scene scene = new Scene(root, 400, 400);
>>
>>TextField f = new TextField();
>>f.setOnKeyReleased( e -> {
>>System.err.println(e.getCode());
>>});
>>root.setCenter(f);
>>
>>primaryStage.setScene(scene);
>>primaryStage.show();
>>} catch (Exception e) {
>>e.printStackTrace();
>>}
>>}
>>
>>public static void main(String[] args) {
>>launch(args);
>>}
>> }
> 
> For default ASCII-Chars like a, b, c, ... I get the correct KeyCode but
> e.g. for +, -, ... the information is totally bogus. Please note I get
> the correct keyCode when pressing the NumPad char but e.g. CLOSE_BRACKET
> when pressing "+" on my keyboard.
> 
> If I'm not completely mistaken the KeyCode defintion for the current +
> is the one for the keypad "+" and the one for the ordinary + is missing?
> 
> This means that the definition:
> 
> PLUS(0x0209, "Plus")
> 
> has to be
> 
> PLUS(0x0209, "Plus", KeyCodeClass.KEYPAD)
> 
> What I can not explain is why the keyboard "+" (ascii-code 43) maps to
> "]" (ascii-code 93) from a native-keyevent to KeyCode happens in
> Glass-Layer.
> 
> Tom
> 
> -- 
> 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

Doubts on KeyCode

[Tom Schindl]

hi,

suppose you have the following code:

> package application;
> 
> import javafx.application.Application;
> import javafx.scene.Scene;
> import javafx.scene.control.TextField;
> import javafx.scene.layout.BorderPane;
> import javafx.stage.Stage;
> 
> public class Main extends Application {
>   @Override
>   public void start(Stage primaryStage) {
>   try {
>   BorderPane root = new BorderPane();
>   Scene scene = new Scene(root, 400, 400);
>   
>   TextField f = new TextField();
>   f.setOnKeyReleased( e -> {
>   System.err.println(e.getCode());
>   });
>   root.setCenter(f);
>   
>   primaryStage.setScene(scene);
>   primaryStage.show();
>   } catch (Exception e) {
>   e.printStackTrace();
>   }
>   }
>   
>   public static void main(String[] args) {
>   launch(args);
>   }
> }

For default ASCII-Chars like a, b, c, ... I get the correct KeyCode but
e.g. for +, -, ... the information is totally bogus. Please note I get
the correct keyCode when pressing the NumPad char but e.g. CLOSE_BRACKET
when pressing "+" on my keyboard.

If I'm not completely mistaken the KeyCode defintion for the current +
is the one for the keypad "+" and the one for the ordinary + is missing?

This means that the definition:

PLUS(0x0209, "Plus")

has to be

PLUS(0x0209, "Plus", KeyCodeClass.KEYPAD)

What I can not explain is why the keyboard "+" (ascii-code 43) maps to
"]" (ascii-code 93) from a native-keyevent to KeyCode happens in
Glass-Layer.

Tom

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