Re: CFV: New OpenJFX Committer: Johan Vos
Vote: yes Best regards, Alexander Kouznetsov (408) 276-0387 On 21 дек 2015 11:45, David Hill wrote: I hereby nominate Johan Vos to OpenJFX Committer. Johan Vos (jvos) has been active in the OpenJFX community, and instrumental in the maturity of Monocle, the owner of the Android and IOS ports and is an OpenJFX Author. A list of Johan's commits is also available by the following links http://hg.openjdk.java.net/openjfx/9-dev/rt/log?rev=jvos http://hg.openjdk.java.net/openjfx/9-dev/rt/log?rev=johanvos Votes are due by January 5th, 2016. Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Nomination to a project Committer is described in [3]. [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus [3] http://openjdk.java.net/projects#project-committer Thanks, Dave
Re: JavaFX on Raspberry Pi
I believe Gluon has support for camera. Not sure what platforms are supported, though. Best regards, Alexander Kouznetsov (408) 276-0387 On 5 дек 2015 20:37, Scott Palmer wrote: Thanks, that worked. Now I have to see how easily I can get he Device I/O stuff working. If I'm lucky, I might even get the camera writing into a WritableImage. Cheers, Scott On Dec 5, 2015, at 10:00 PM, Jonathan Giles <jonathan.gi...@oracle.com> wrote: I've not tested myself, but this might help: http://gluonhq.com/gluon-supports-javafx-embedded-binary-builds-now-available/ -- Jonathan Sent from a touch device. Please excuse my brevity. On 6 December 2015 15:29:27 GMT+13:00, Scott Palmer <swpal...@gmail.com> wrote: I seem to recall that the Arm builds of Java 8 no longer include JavaFX. I just installed 8u65 on my Raspberry Pi and that does in fact appear to be the case. The web page https://wiki.openjdk.java.net/display/OpenJFX/OpenJFX+on+the+Raspberry+Pi was last updated in June and it implies that JavaFX is included in the Java 8 Arm build. Where do I find the current instructions for getting JavaFX onto a Raspberry Pi? Is there anything pre-built available, or am I forced to build it myself with the instructions here: https://wiki.openjdk.java.net/display/OpenJFX/Cross+Building+for+ARM+Hard+Float ? I’m using a Mac, and the instructions say that mainly Linux is used to cross-build for Arm, so hopefully I won’t get stuck in build hell :-) I also noticed that JavaME builds include the Device I/O API (http://docs.oracle.com/javame/8.0/api/dio/api/index.html) Is it possible to use these APIs and JavaFX on a Raspberry Pi at the same time? Can the Device I/O libraries (.jar and .so) simply be copied over from a JavaME install to a JavaSE install? Do Java 9 modules help with any of that? Regards, Scott
Re: Pausing Quantum Renderer
Shouldn't this be an equivalent of minimizing the window? Best regards, Alexander Kouznetsov (408) 276-0387 On 18 ноя 2015 12:45, Johan Vos wrote: Hi, On Android, a JavaFX Application might transfer control to another app (and become invisible) and enter the foreground later. In that case, the GLSurface we are rendering on becomes invalid. In order to avoid problems and save battery, we want to pause the renderer thread, but this turns out to be more difficult than I expected. When our app transfers control, we get a callback from Android. We intercept this in javafxports, and we set the Screen width/height to 0/0 as we don't want to render on the (invalid) surface while we lost control. When we regain control, we resize the Screen and the app renders again. The reason we set the width/height to 0/0 is because the PresentingPainter will call SceneState.isValid() and this returns false in case getWidth() or getHeight() are 0. However, SceneState extends PresentableState and it overrides the update method. It will call PresentatbleState.update() which will set the viewWidth to the width of the new Screen (hence, 0) , but after that it overwrites the viewWidth with camera.getViewWidth(). The latter still contains the old value. A quick inspection shows that camera.setViewWidth() is called when validate(...) is called on NGDefaultCamera, which is called by ES2Context.updateRenderTarget() which happens during rendering, hence *after* the PresentingPainter checks if the width is 0. So immediately after we set the width of the Screen to 0 (on the FX App Thread), a Pulse happens, and this one still things the screen is the original size. While the pulse is happening, the android system destroys our context, and the rendering fails. Moreover, the EGL system is in a unpredictable state (recreating the surface fails). A very dirty workaround for this is to wait for 1 pulse (with the new pulselistener API this should be possible) before we return from the callback method called by Android when the surface is about to be destroyed. That way, we will have 1 bogus rendering on an existing (but about-to-be-destroyed) surface. But it would be better if there is some way to tell the quantum renderer to immediately stop rendering. Existing pulses are no problem, as the renderLock guarantuees that we set the size to 0 only when no other thread (quantum renderer) has a lock on the renderLock. - Johan
Re: [9] Review request for 8140503: JavaFX "Pair" Hash Code Collisions
Moreover, the following two sentences: "However, this is an incorrect way to compute a hash code of two values." "This can lead to hard-to-find bugs anywhere that instances of Pair are used in a data structure like a HashSet or HashTable." seem to indicate misunderstanding of what hashcode is and how it is to be used. Best regards, Alexander Kouznetsov (408) 276-0387 On 3 ноя 2015 13:42, Alexander Kouznetsov wrote: After the fix, you should expect another incident report of Objects.hash(1, 0) == Objects.hash(0, 31) always true :-) I'd rather file another bug on key == null causing NPE and closing this one as incomplete or not an issue. Best regards, Alexander Kouznetsov (408) 276-0387 On 3 ноя 2015 12:07, Vadim Pakhnushev wrote: Hmm, yeah, the actual difference is in the prime number only (that is changing the algorithm only doesn't improve anything), so the only remaining reason to fix this is that Objects.hash guards against null values (and I forgot to mention it in the review). The key in Pair could actually be null and in this case hashCode will throw NPE. Vadim On 03.11.2015 23:01, Vadim Pakhnushev wrote: Well, not exactly... Previously it was 13*hash(a) + hash(b) and now it's 31*(31 + hash(a)) + hash(b). And apparently it improves the quality somehow. I did a test with 100^4 combinations and collision probability dropped by the factor of 3 from 0.065% to 0.022%. Not really impressive, but still, and it uses well-defined utility method. Yeah, I know it's not really a bug since you don't want to rely on the hashCode at all... Thanks, Vadim On 03.11.2015 22:35, Jim Graham wrote: All this does is change the prime constant used to produce the hash value. Objects.hash(a, b) uses 31*hash(a) + hash(b) instead of the 13*hash(a) + hash(b) that the embedded implementation uses. I don't really think this is a bug. The fact that Integer objects make it easy to reverse engineer and compute collisions of any reasonable hash combination computation don't mean that the technique has a bug, it just means that the submitter can read the code and think of a counter-example. If there are practical problems being caused for some particular and popular use case by the use of this particular constant "13", then we need to understand those issues and come up with a more comprehensive solution than to simply hand off to another mechanism which uses the same procedure with a different prime constant... ...jim On 11/3/15 3:06 AM, Vadim Pakhnushev wrote: Hi Chien, Could you please review the fix: https://bugs.openjdk.java.net/browse/JDK-8140503 http://cr.openjdk.java.net/~vadim/8140503/webrev.00/ Thanks, Vadim
Re: [9] Review request for 8140503: JavaFX "Pair" Hash Code Collisions
After the fix, you should expect another incident report of Objects.hash(1, 0) == Objects.hash(0, 31) always true :-) I'd rather file another bug on key == null causing NPE and closing this one as incomplete or not an issue. Best regards, Alexander Kouznetsov (408) 276-0387 On 3 ноя 2015 12:07, Vadim Pakhnushev wrote: Hmm, yeah, the actual difference is in the prime number only (that is changing the algorithm only doesn't improve anything), so the only remaining reason to fix this is that Objects.hash guards against null values (and I forgot to mention it in the review). The key in Pair could actually be null and in this case hashCode will throw NPE. Vadim On 03.11.2015 23:01, Vadim Pakhnushev wrote: Well, not exactly... Previously it was 13*hash(a) + hash(b) and now it's 31*(31 + hash(a)) + hash(b). And apparently it improves the quality somehow. I did a test with 100^4 combinations and collision probability dropped by the factor of 3 from 0.065% to 0.022%. Not really impressive, but still, and it uses well-defined utility method. Yeah, I know it's not really a bug since you don't want to rely on the hashCode at all... Thanks, Vadim On 03.11.2015 22:35, Jim Graham wrote: All this does is change the prime constant used to produce the hash value. Objects.hash(a, b) uses 31*hash(a) + hash(b) instead of the 13*hash(a) + hash(b) that the embedded implementation uses. I don't really think this is a bug. The fact that Integer objects make it easy to reverse engineer and compute collisions of any reasonable hash combination computation don't mean that the technique has a bug, it just means that the submitter can read the code and think of a counter-example. If there are practical problems being caused for some particular and popular use case by the use of this particular constant "13", then we need to understand those issues and come up with a more comprehensive solution than to simply hand off to another mechanism which uses the same procedure with a different prime constant... ...jim On 11/3/15 3:06 AM, Vadim Pakhnushev wrote: Hi Chien, Could you please review the fix: https://bugs.openjdk.java.net/browse/JDK-8140503 http://cr.openjdk.java.net/~vadim/8140503/webrev.00/ Thanks, Vadim
Re: Windows Hi-DPI
Have you tried running it with -Dprism.verbose=true flag? It should provide some debug output. Best regards, Alexander Kouznetsov (408) 276-0387 On 30 окт 2015 3:55, Felix Bembrick wrote: The NVIDIA Control Panel allowed me to disable SLI completely and I even rebooted. I also upgraded to Java 8u72. Sadly JavaFX still performs like a one-legged dog dragging a cannon ball on a chain. All other 3D apps, games etc. perform blindingly fast as I would expect. So, if it's not an SLI or driver problem, what is going on here (or not going on)? Felix On 30 Oct 2015, at 19:47, Felix Bembrick <felix.bembr...@gmail.com> wrote: That's curious. SLI is designed specifically with gamers in mind! I'll investigating running without SLI and report back. Felix On 30 Oct 2015, at 19:44, Chris Nahr <chris.n...@gmail.com> wrote: If it's slower on an SLI machine than on an ordinary one then yes, I suspect JavaFX just can't handle SLI properly. Among gamers I've often heard that it's a notoriously problematic configuration. Can you switch your card to non-SLI mode and retest performance? --Chris On 2015-10-30 09:19, Felix Bembrick wrote: I am using Java 8u66 and performance is really poor. I suspected a driver issue but I have the latest driver for my Titan X card (4 in SLI mode) and running the 4K monitor tests in 3DMark says my machine is in the top 1% fastest computers ever to run the tests. It looks to me that JavaFX just can't deliver acceptable performance on 4K monitors, even with the most powerful graphics cards on the planet. Or maybe it doesn't support SLI? It could be Windows 10 related but I don't think so. And I am definitely getting hardware acceleration according to the output so I suspect JavaFX has trouble moving so many pixels around on these hi-res monitors. All other 3D apps and games run blindingly fast but JavaFX actually runs slower on this beast than on my wife's little i5 powered Dell machine with a low range graphics card, also running Windows 10. Any ideas? Felix On 30 Oct 2015, at 17:33, Chris Nahr<chris.n...@gmail.com> wrote: Hi-DPI is supported on Windows, assuming you have 8u60 or later (better 8u66 or later so a ComboBox doesn't freeze the application!). On my Dell XPS-15 with Windows 10 and 4K displays JavaFX also uses hardware acceleration, in this case with the Intel 4600 integrated GPU. However, this causes frequent Intel display driver crashes and restarts because the Windows 10 drivers are still so immature. Same happens in WPF applications, so it's not specific to JavaFX. I've grabbed my driver directly from the Intel website. Possibly your system runs an older driver that causes JavaFX not to use HA. Given how unstable it currently is on Windows 10, that might not be a bad idea. But of course you could try manually updating and see what happens to JavaFX performance. Cheers, Chris On 2015-10-28 17:24:38, Felix Bembrick <felix.bembr...@gmail.com> wrote: I just installed JavaFX on my new Windows 10 machine which is extremely powerful but has two 4K monitors and while everything looks great and the right "size", the performance is very sluggish to say the least. Is this because Hi-DPI is not yet supported in JavaFX on Windows? Thanks, Fix
Re: Fx questions
Hi Michael, Could you please file a bug on this? Best regards, Alexander Kouznetsov (408) 276-0387 On 30 окт 2015 3:21, Dr. Michael Paus wrote: This is good to know but I just gave it a try on my MacBookPro Retina and it failed. I opened the youtube start page and there was an add at the top (from Porsche :-)) which indeed played a video. Cool! But when I then clicked on the link to close the add java crashed completely. # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00014946489e, pid=4440, tid=87311 # # JRE version: Java(TM) SE Runtime Environment (8.0_72-b05) (build 1.8.0_72-ea-b05) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.72-b05 mixed mode bsd-amd64 compressed oops) # Problematic frame: # C [libjfxmedia_avf.dylib+0x789e] _ZN18AVFKernelComponent18ProcessBufferListsERjRK15AudioBufferListRS1_j+0x22 # Obviously I'm having sticky fingers or so because I always catch all bugs which are lurking arround. Frustrating. Am 30.10.15 um 10:37 schrieb John Maton: JDK 8u72 (1.8.0_72-ea) makes a big difference here. Using 8u66 I was not able to see any HTML5 videos on youtube, they all reverted to Flash. 8u72 makes it all work, last time I checked I was unable to find a video on youtube which did not work. You can download 8u72 at https://jdk8.java.net/download.html Best regards, John Maton On Fri, Oct 30, 2015 at 9:14 AM, Dr. Michael Paus <m...@jugs.org <mailto:m...@jugs.org>> wrote: Am 29.10.15 um 22:58 schrieb Brian Harris: - when embedding html5 pages into fx apps, should we expect it to render/behave similar to popular browsers like chrome? I'm wondering if we can expect this to just work or if things may be a bit wonky. In theory it is just Webkit and as such it should behave like any popular browser and in many cases it does. However, I have stumbled over several pages where this is not the case and sometimes it even depends on the system you are running your application on. It may work on Windows but fail on a Mac Retina. Your best bet is to just give it a try with the pages that are important for you and see how it behaves. Here are a few pages where I have problems with. https://www.google.com/maps - (enters "Lite-Mode" because of unsupported features.) https://www.youtube.com - (I am not able to watch any video there. Same on vimeo.) https://www.windyty.com - (No wind trails on MacBook Pro Retina.) (Tested with JDK 8u66-b17)
Re: Converting from svg format to javafx css svg
For JavaFX 8, please refer to http://download.java.net/jdk8/jfxdocs/javafx/scene/doc-files/cssref.html You can use -fx-min-width, -fx-pref-width, -fx-max-width and corresponding height properties to set region size. Best regards, Alexander Kouznetsov (408) 276-0387 On 15 дек 2013 11:17, Pedro Duque Vieira wrote: I think it is an interesting use of CSS - sizing stuff.. I think its the only way that currently exists, i.e. using padding. P.s.: what happened to the width and height property that was discussed in this mailing list? On Dec 15, 2013 7:11 AM, Gerrit Grunwald han.s...@muenster.de wrote: Hi Pedro, If you set -fx-scale-shape: true; you just have to know the aspect ratio of your svg path and can control the size of the Region in Java code (either in the skin or in the region class). To be honest I never tried to size a shape by using only padding in css. Cheers, Gerrit Am 15.12.2013 um 07:37 schrieb Pedro Duque Vieira pedro.duquevie...@gmail.com: Hi Gerrit, Yeah, thanks putting -fx-scale-shape: false does make the svg shape the original size as seen in Illustrator. I'm still left with a doubt though, you say you resize the region to make the svg the way you want to, how do you do that? programmatically, through java? How about doing it through CSS? That's why I was using padding, but I don't want to disrupt the aspect ratio.. Thanks, best regards, On Sat, Dec 14, 2013 at 11:47 PM, Gerrit Grunwald han.s...@muenster.dewrote: Hi Pedro, If I got you right you have scaling problems with the -fx-shape in css right? So if you use -fx-scale-shape: false; the svg path should be exactly the same size as the original path from Illustrator and if you would like to scale the shape to the size of the Region you just set it to true and set the size if the Region to the size you need the svg path. If your svg path has a certain aspect-ratio you should take care about it by resizing the Region correctly. That is the way I use it everywhere and it works really nicely. I usually don't use the padding for the svg path in css to resize it. Just my 0.02€... Cheers, Gerrit Am 14.12.2013 um 22:00 schrieb Pedro Duque Vieira pedro.duquevie...@gmail.com: Hi, While working in JMetro (Metro like controls for javafx) I have the following process for creating svg graphics using javafx css: 1- I create the vector graphics in Adobe Illustrator 2- save the file in svg format 3- get the svg path notation from the svg file and use it with javafx -fx-shape css property The thing that I haven't still mastered is how does the size of the vector graphics in Illustrastor translate to the size I have to input in the -fx-padding css property. I know I have to enter half the value of width for the left and right and half the value of the height for the top and bottom but still that doesn't seem to work. It's still more of a process of trial and error for me. Thanks in advance. -- Pedro Duque Vieira -- Pedro Duque Vieira
Re: Progress Bar into Combo Box is not working properly
You shouldn't mix ComboBox data items and JavaFX nodes. So change ComboBoxVBox to ComboBoxMyData. Next, you can set ProgressBars as ListCell graphics as you already do. And make sure that each cell has its own ProgressBar node. Nodes cannot be present several times in the scenegraph. That's why there is the following situation: selected node cannot appear in the list of nodes at the same time: Your example also has some code to hide combobox which is confusing as it is not related to the question. Best regards, Alexander Kouznetsov (408) 276-0387 On 16 дек 2013 18:18, Peter Penzov wrote: Hi All, I want to implement Progress Bar into Combo Box. I pasted the code here: http://stackoverflow.com/questions/20518329/combobox-with-progress-bars-is-not-working-properly When I run the code the progress bar is empty. There is no selected Progress Bar which is displayed by default. And also after a time the progress bar is not responsible. I tested the code with Java 8b119. Maybe this is a bug. Can you please assist me to fix this issue? Regards, Peter
Re: Font.font() says it is point size but it looks like it are pixels
Tom,
Could you please file a bug on this?
Best regards,
Alexander Kouznetsov
(408) 276-0387
On 23 дек 2013 15:31, Tom Schindl wrote:
Hi,
The JavaDoc of Font.font says:
-8-
size - The point size of the font. This can be a fractional value, but
must not be negative. If the size is 0 the default size will be used.
-8-
I highly doubt this is correct (see attached picture from Linux where
you see native, qt and javafx) and a sample FX-Code using setFont and
using CSS (see at the end of this mail)
The result is correct if CSS is used and looking up the code in the CSS
shows that values are calculated back to pixels when passed to the
Font-factory method (FontConverter.convert!).
I guess one can not fix this Font.font API to really work with points
(which would be the natural expectation at least to me) but the JavaDoc
has to be fixed!
Another thing I came across is that the DPI calculation is fixed to 96
DPI - which i don't fully understand why it is fixed because the DPI can
vary between devices and monitors. Is this because of multi-monitors and
you are applying a transformation based on the screen the text is
rendered on?
Tom
---
HBox h = new HBox();
{
Text t = new Text(Hello World);
t.setFont(Font.font(50));
h.getChildren().add(t);
}
{
Text t = new Text(Hello World);
t.setStyle(-fx-font-size: 50pt;);
h.getChildren().add(t);
}
primaryStage.setScene(new Scene(h,300,300));
primaryStage.show();
Re: How I do connect two panes?
Try using Line node. It has bindable coordinates. Best regards, Alexander Kouznetsov (408) 276-0387 On 7 янв 2014 1:30, Amine Tengilimoglu wrote: I want to connect two panes. panes are dragable so: I need dinamic line... Which API should I look at? ı am waiting for answers...thanx
Re: Launching JavaFX apps
Here is the link to file a bug on NetBeans: http://netbeans.org/bugzilla/enter_bug.cgi Best regards, Alexander Kouznetsov (408) 276-0387 On 8 янв 2014 18:45, Kevin Rushforth wrote: So yes, it does seem that Netbeans should modify the wording of their javadoc comment for the main() method of a JavaFX application.
Re: Launching JavaFX apps
Scott, I didn't get that. Are you saying that main() method javadoc is correct? Best regards, Alexander Kouznetsov (408) 276-0387 On 15 янв 2014 16:40, Scott Palmer wrote: Thanks. I'm participating in NetCat 8.0 so I'm well aware of that link :-). But this doesn't appear to be a NetBeans issue. Inclusion of metadata into the launcher stub is not implemented in the javafxpackager command line tool or ant task as far as I can tell. (I'm using the gradle plugin mainly at this point, but it just delegates to the ant task as far as I can tell.) Cheers, Scott On Wed, Jan 15, 2014 at 6:45 AM, Alexander Kouznetsov alexander.kouznet...@oracle.com mailto:alexander.kouznet...@oracle.com wrote: Here is the link to file a bug on NetBeans: http://netbeans.org/bugzilla/enter_bug.cgi Best regards, Alexander Kouznetsov (408) 276-0387 tel:%28408%29%20276-0387 On 8 янв 2014 18:45, Kevin Rushforth wrote: So yes, it does seem that Netbeans should modify the wording of their javadoc comment for the main() method of a JavaFX application.
Re: [8u] Post-commit review: RT-35237, When a Bidirectional binding fails, old value restoration may cause an exception hiding the real cause
The link doesn't work for me. Best regards, Alexander Kouznetsov (408) 276-0387 On 13 янв 2014 16:33, Martin Sladecek wrote: Hello, here's a changeset for RT-35237 (When a Bidirectional binding fails, old value restoration may cause an exception hiding the real cause), if anybody's interested. http://hg.openjdk.java.net/openjfx/8u-dev/graphics/rt/rev/f487abfe1990 Thanks, -Martin
Re: Post commit review: [Re: hg: openjfx/8u-dev/rt: RT-35147: [Android, Ensemble8] App should react to hardware buttons on Android]
Hi Steve, In general it looks good but I want to correct some parts of it. How should I proceed in this case? Best regards, Alexander Kouznetsov (408) 276-0387 On 3 янв 2014 21:44, Stephen F Northover wrote: Hi Alex, Samples were changed to support Android. Apparently, hitting escape twice should exit an application and this behavior was coded into EnsembleApp. I'm not an Android guy but if this is standard Android behavior, it should be part of JFX, not the example code. Anyhow, I'll let Stefan or Johan comment on this and they can enter a follow on JIRA. Steve On 2014-01-03 12:32 PM, hang...@oracle.com wrote: Changeset: 6f0901527ad0 Author:snorthov Date: 2014-01-03 12:23 -0500 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/6f0901527ad0 RT-35147: [Android, Ensemble8] App should react to hardware buttons on Android Reviewed-by: snorthov Contributed-by: Stefan Fuchs snfu...@gmx.de ! apps/samples/Ensemble8/src/app/java/ensemble/EnsembleApp.java ! apps/samples/Ensemble8/src/app/java/ensemble/PlatformFeatures.java ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/Description.java ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/SamplePageContent.java ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/SourceTab.java ! apps/samples/Ensemble8/src/app/java/ensemble/util/FeatureChecker.java ! modules/base/src/main/java/com/sun/javafx/PlatformUtil.java
Re: Post commit review: [Re: hg: openjfx/8u-dev/rt: RT-35147: [Android, Ensemble8] App should react to hardware buttons on Android]
Hi Stefan, Thank you for this summary. As an android user I would say that #2 is not a good options for Ensemble. #3 is better than #1. However, it usually responds to the second key press only within a short period of time. About the time a notice message is shown. Best regards, Alexander Kouznetsov (408) 276-0387 On 3 янв 2014 23:43, Stefan Fuchs wrote: Hi, well, the back button is always used to go back one dialog level, until the start screen has be reached. (Dialogs are canceled, browsers go to previous website, etc...) If you press the back button on the start screen of the app, I found three different strategies to handle the back button: 1. Exit the app on first button press (examples: WhatsApp, Google Maps) 2. Hide the app on first button press and let the system kill the application, if system memory is exhausted. (examples: FireFox, Chrome) 3. Exit the app on second button press (note that most apps using this strategy print a notice message, after the first key press, which is currently not implemented for Ensemble8) (examples: Samsungs App Store) Stefan Stephen F Northover wrote: Hi Alex, Samples were changed to support Android. Apparently, hitting escape twice should exit an application and this behavior was coded into EnsembleApp. I'm not an Android guy but if this is standard Android behavior, it should be part of JFX, not the example code. Anyhow, I'll let Stefan or Johan comment on this and they can enter a follow on JIRA. Steve On 2014-01-03 12:32 PM, hang...@oracle.com wrote: Changeset: 6f0901527ad0 Author:snorthov Date: 2014-01-03 12:23 -0500 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/6f0901527ad0 RT-35147: [Android, Ensemble8] App should react to hardware buttons on Android Reviewed-by: snorthov Contributed-by: Stefan Fuchs snfu...@gmx.de ! apps/samples/Ensemble8/src/app/java/ensemble/EnsembleApp.java ! apps/samples/Ensemble8/src/app/java/ensemble/PlatformFeatures.java ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/Description.java ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/SamplePageContent.java ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/SourceTab.java ! apps/samples/Ensemble8/src/app/java/ensemble/util/FeatureChecker.java ! modules/base/src/main/java/com/sun/javafx/PlatformUtil.java
Re: please review RT-31668
Looks good to me if NetBeans 7.3.1 is happy as well. Thank you! Best regards, Alexander Kouznetsov (408) 276-0387 On 5 дек 2013 14:16, David Hill wrote: https://javafx-jira.kenai.com/browse/RT-31668 Kevin, Alexander, please review: http://cr.openjdk.java.net/~ddhill/RT-31668/ http://cr.openjdk.java.net/%7Eddhill/RT-31668/
