V-up texture coordinate support
My JavaFX 3D model importers convert geometric data to the JavaFX 3D coordinate sytem to support the default camera model (viewing into the screen along the +Z-axis). A Y-up right-handed coordinate system (e.g. COLLADA-, OBJ-, X3D-exports from modelling tools) is mapped as follows: +Y - -Y, +X - +X, +Z - -Z. This includes the adjustment of all transforms and also the v-flipping of the texture coordinates: v - 1 - v. In this case I prefer converted texture coordinates stored in the TriangelMesh instead of converting them 'backstage'. Alternatively, I consider providing an ImportOption to omit this conversions if someone wants to simulate a Y-up right-handed coordinate system in JavaFX. This would result in TriangelMesh points and texture coordinates consistent with the imported file. Now an internal v-flipping is needed to avoid upside-down textures because the corresponding texture coordinates are typically v-up oriented. Right? Simulating a Y-up right-handed coordinate system in JavaFX is discussed in Getting Started with JavaFX 3D Graphics/Camera/Y-down versus Y-up (http://docs.oracle.com/javafx/8/3d_graphics/camera.htm#CJAHFAHB). Doesn't this approach require an immediate availability of a v-flipping feature? August Am Donnerstag, den 17.10.2013, 15:08 +0200 schrieb Chien Yang chien.y...@oracle.com: Hi all, Java images are defined such that (0, 0) references the top left most pixel of the image. In JavaFX, the texture coordinate system for 3D objects is defined with its U axis increasing from left to right and the V axis increasing from top to bottom. Hence a texture coordinate of (0, 0) references pixel (0, 0), which is the top left corner of the texture, and a texture coordinate of (1, 1) references the bottom right corner of the texture. This system matches the layout of the image, which is stored such that the top-most row of pixels ends up in memory in row 0. It also matches with the default 3D coordinate system used in JavaFX where the X axis increases from left to right and the Y axis increases from top to bottom. We understand that this V-down coordinate system maybe confusing or hard to work with for some 3D content developers when using models that are defined with Y-up. We could add a V-up option (as a boolean property of Shape3D). If set, we would flip the texture coordinates when rendering, such that: V' = 1 - V. However it is very late in this release to consider any more changes, so our plan is to add this option in a post FX 8 release if it turns out to be needed. Please let us know right away if there is a compelling need for V-up support in the FX 8 release. - Kevin and Chien
Re: JavaFX on iOS and Android - are we there yet?
1) Look and Feel: IMO it’s enough to build „native looking“ css based skins! That could be very quickly without complex technologies like CALayer etc. 2) After starting RoboVM JavaFX needs round about 10 seconds to start the simple list example on iPhone4. So it’s too long. I tried to use the preloaded class via property „-Djavafx.preloader“ but it doesn’t work, my preloaded class is not instantiated… Tobi Am 21.10.2013 um 21:48 schrieb Richard Bair richard.b...@oracle.com: 1. Can you provide me with a detailed summary of where the iOS/Android ports are currently? This includes the platform specific stuff to make either RoboVM or an Oracle JVM work? I would say, it is in a good prototype stage. It hasn't had heavy testing, so the biggest risk is the unknown. Luckily, on iOS at least there are only a very few devices so it should be relatively easy for an app developer to feel confident it works for their app. But for the OpenJFX project, to test and certify a whole variety of APIs, will be quite a challenge. We have a huge pile of tests, we just need: 1) To have a way to run our unit tests on the actual devices 2) Have a way to run graphical tests on devices (basically a port of Jemmy??) I haven't scoped either of these efforts, but both are ripe areas for collaboration with anybody in the community. If it were heavily tested, I'd say most of the remaining work is actually in the graphics / performance side. Path rendering performance is fairly bad (though I've seen similar complaints for Cocoa path rendering performance, so it may be we're not that bad relatively speaking, but it is still horrendous IMO and needs to be looked at). The code is all there for the integration layer -- anybody with familiarity with Objective-C and Cocoa, I'd say, go read the glass code! This is a huge opportunity for community initial community involvement because: 1) There is a ton of existing documentation and code in the Apple universe describing all the sorts of things we need to do in Glass 2) Glass is pretty decoupled from the rest of the platform, so you can easily understand what is going on there without having to understand everything else Contributing on the Graphics side is more work and requires more specialized skills. The fortunate thing here is that the graphics code is shared with embedded (and desktop Mac and Linux) so there is a lot of overlap. So those would be the main things from my perspective: performance testing, functional / unit testing, native platform integration, and graphics. Another thing we've designed for from the beginning, but never validated, is the ability to use a native control as the skin. The iOS prototype hot swaps a native text field in when a TextInputControl gets focus, but this is kinda funky (and there are lots of bugs here). The right thing to do here would be to have a set of native skins for controls, and the ability to create multiple core layers. So if you have a scene graph where on the bottom you draw stuff, then have a native control, then draw more stuff over the native control, then what you would want is, on the Prism side, use 3 hardware layers (one for below the native, one for the native, and one for above the native). I don't know: 1) How well this would work in practice with input events (but one could imagine putting a native 'glass pane' on the top to intercept all events and vector them through FX, forwarding to native controls as necessary as part of the normal FX event dispatch) 2) How many layers you could have before things would explode. Alternatively, using image skinning to get the look right, and only do the funky native control swap in for text input, like we're doing today. 2. Are the iOS and Android ports at roughly the same level of completeness/viability? I think so, David / Tomas, can you guys add some insight as to where we're at from your perspective? 3. Exactly what is left in making these ports viable? Here the word viable is defined in my 6 Degrees of Separation post here http://justmy2bits.com/2013/09/30/javafx-on-ios-and-android-six-degrees-of-separation 1. Their look and feel is indistinguishable from native apps As described above, there is work to be done here either by beefing up the emulation, or adding the ability to intersperse native controls. The latter approach I expect to be significant work, although technically feasible. Also, I expect people will want to add more iOS specific controls (like breadcrumb bars) to make this easier to do (rather than everybody styling their own). 2. They must load as quickly as a native apps I've heard RoboVM starts up very quickly. Also you will package your app with a splash screen. Also I believe the Preloader APIs work now with iOS (I haven't tested on RoboVM but try it out and let me know if it works! You will probably need
Re: JavaFX on iOS and Android - are we there yet?
+1 re: Native LF. IMO also there is nothing sacred about the exactness of Apple's ui. They 'll be changing it up a lot a also. Being someone who prefers custom looks to bland native looks anyway, I never did get the sacredness of repeating mirror-lookalike grey :). Just my opinion, I'm sure there are those who disagree. David Sent from my iPhone On Oct 22, 2013, at 7:17 AM, Tobias Bley t...@ultramixer.com wrote: 1) Look and Feel: IMO it’s enough to build „native looking“ css based skins! That could be very quickly without complex technologies like CALayer etc. 2) After starting RoboVM JavaFX needs round about 10 seconds to start the simple list example on iPhone4. So it’s too long. I tried to use the preloaded class via property „-Djavafx.preloader“ but it doesn’t work, my preloaded class is not instantiated… Tobi Am 21.10.2013 um 21:48 schrieb Richard Bair richard.b...@oracle.com: 1. Can you provide me with a detailed summary of where the iOS/Android ports are currently? This includes the platform specific stuff to make either RoboVM or an Oracle JVM work? I would say, it is in a good prototype stage. It hasn't had heavy testing, so the biggest risk is the unknown. Luckily, on iOS at least there are only a very few devices so it should be relatively easy for an app developer to feel confident it works for their app. But for the OpenJFX project, to test and certify a whole variety of APIs, will be quite a challenge. We have a huge pile of tests, we just need: 1) To have a way to run our unit tests on the actual devices 2) Have a way to run graphical tests on devices (basically a port of Jemmy??) I haven't scoped either of these efforts, but both are ripe areas for collaboration with anybody in the community. If it were heavily tested, I'd say most of the remaining work is actually in the graphics / performance side. Path rendering performance is fairly bad (though I've seen similar complaints for Cocoa path rendering performance, so it may be we're not that bad relatively speaking, but it is still horrendous IMO and needs to be looked at). The code is all there for the integration layer -- anybody with familiarity with Objective-C and Cocoa, I'd say, go read the glass code! This is a huge opportunity for community initial community involvement because: 1) There is a ton of existing documentation and code in the Apple universe describing all the sorts of things we need to do in Glass 2) Glass is pretty decoupled from the rest of the platform, so you can easily understand what is going on there without having to understand everything else Contributing on the Graphics side is more work and requires more specialized skills. The fortunate thing here is that the graphics code is shared with embedded (and desktop Mac and Linux) so there is a lot of overlap. So those would be the main things from my perspective: performance testing, functional / unit testing, native platform integration, and graphics. Another thing we've designed for from the beginning, but never validated, is the ability to use a native control as the skin. The iOS prototype hot swaps a native text field in when a TextInputControl gets focus, but this is kinda funky (and there are lots of bugs here). The right thing to do here would be to have a set of native skins for controls, and the ability to create multiple core layers. So if you have a scene graph where on the bottom you draw stuff, then have a native control, then draw more stuff over the native control, then what you would want is, on the Prism side, use 3 hardware layers (one for below the native, one for the native, and one for above the native). I don't know: 1) How well this would work in practice with input events (but one could imagine putting a native 'glass pane' on the top to intercept all events and vector them through FX, forwarding to native controls as necessary as part of the normal FX event dispatch) 2) How many layers you could have before things would explode. Alternatively, using image skinning to get the look right, and only do the funky native control swap in for text input, like we're doing today. 2. Are the iOS and Android ports at roughly the same level of completeness/viability? I think so, David / Tomas, can you guys add some insight as to where we're at from your perspective? 3. Exactly what is left in making these ports viable? Here the word viable is defined in my 6 Degrees of Separation post here http://justmy2bits.com/2013/09/30/javafx-on-ios-and-android-six-degrees-of-separation 1. Their look and feel is indistinguishable from native apps As described above, there is work to be done here either by beefing up the emulation, or adding the ability to intersperse native controls. The latter approach I expect to be significant work, although technically feasible. Also, I expect people
Re: JavaFX on iOS and Android - are we there yet?
Another approach which would be a *lot* easier to implement would be to add a Layer public API that would allow the app developer to specify what layers there are, and where they are (this has a lot of other benefits related to performance on embedded and mobile devices). Then, don't solve the heavyweight / lightweight issue, but allow heavyweight native controls to be added wherever. Then you just be careful not to have any lightweights on the same layer as a heavyweight if they might overlap above the heavyweight. Of course, you have this API already today in the form of SubScene! I haven't tried it in this context though. Richard On Oct 22, 2013, at 6:21 AM, David Ray cognitionmiss...@gmail.com wrote: +1 re: Native LF. IMO also there is nothing sacred about the exactness of Apple's ui. They 'll be changing it up a lot a also. Being someone who prefers custom looks to bland native looks anyway, I never did get the sacredness of repeating mirror-lookalike grey :). Just my opinion, I'm sure there are those who disagree. David Sent from my iPhone On Oct 22, 2013, at 7:17 AM, Tobias Bley t...@ultramixer.com wrote: 1) Look and Feel: IMO it’s enough to build „native looking“ css based skins! That could be very quickly without complex technologies like CALayer etc. 2) After starting RoboVM JavaFX needs round about 10 seconds to start the simple list example on iPhone4. So it’s too long. I tried to use the preloaded class via property „-Djavafx.preloader“ but it doesn’t work, my preloaded class is not instantiated… Tobi Am 21.10.2013 um 21:48 schrieb Richard Bair richard.b...@oracle.com: 1. Can you provide me with a detailed summary of where the iOS/Android ports are currently? This includes the platform specific stuff to make either RoboVM or an Oracle JVM work? I would say, it is in a good prototype stage. It hasn't had heavy testing, so the biggest risk is the unknown. Luckily, on iOS at least there are only a very few devices so it should be relatively easy for an app developer to feel confident it works for their app. But for the OpenJFX project, to test and certify a whole variety of APIs, will be quite a challenge. We have a huge pile of tests, we just need: 1) To have a way to run our unit tests on the actual devices 2) Have a way to run graphical tests on devices (basically a port of Jemmy??) I haven't scoped either of these efforts, but both are ripe areas for collaboration with anybody in the community. If it were heavily tested, I'd say most of the remaining work is actually in the graphics / performance side. Path rendering performance is fairly bad (though I've seen similar complaints for Cocoa path rendering performance, so it may be we're not that bad relatively speaking, but it is still horrendous IMO and needs to be looked at). The code is all there for the integration layer -- anybody with familiarity with Objective-C and Cocoa, I'd say, go read the glass code! This is a huge opportunity for community initial community involvement because: 1) There is a ton of existing documentation and code in the Apple universe describing all the sorts of things we need to do in Glass 2) Glass is pretty decoupled from the rest of the platform, so you can easily understand what is going on there without having to understand everything else Contributing on the Graphics side is more work and requires more specialized skills. The fortunate thing here is that the graphics code is shared with embedded (and desktop Mac and Linux) so there is a lot of overlap. So those would be the main things from my perspective: performance testing, functional / unit testing, native platform integration, and graphics. Another thing we've designed for from the beginning, but never validated, is the ability to use a native control as the skin. The iOS prototype hot swaps a native text field in when a TextInputControl gets focus, but this is kinda funky (and there are lots of bugs here). The right thing to do here would be to have a set of native skins for controls, and the ability to create multiple core layers. So if you have a scene graph where on the bottom you draw stuff, then have a native control, then draw more stuff over the native control, then what you would want is, on the Prism side, use 3 hardware layers (one for below the native, one for the native, and one for above the native). I don't know: 1) How well this would work in practice with input events (but one could imagine putting a native 'glass pane' on the top to intercept all events and vector them through FX, forwarding to native controls as necessary as part of the normal FX event dispatch) 2) How many layers you could have before things would explode. Alternatively, using image skinning to get the look right, and only do the funky native control swap in for text input, like we're doing today. 2.
Re: JavaFX on iOS and Android - are we there yet?
1) Look and Feel: IMO it’s enough to build „native looking“ css based skins! That could be very quickly without complex technologies like CALayer etc. Generally this should be very easy for somebody to do. There is a ui kit already out there that designers use for mocking up UI designs for both the new iOS7 look and the previous looks. Should be straight forward to take and turn into an image based CSS theme. 2) After starting RoboVM JavaFX needs round about 10 seconds to start the simple list example on iPhone4. So it’s too long. I tried to use the preloaded class via property „-Djavafx.preloader“ but it doesn’t work, my preloaded class is not instantiated… What is the state of the jfx78 back port, and how often is it updated? I'm wondering what the time is for getting a fix put in before it shows up in the back port. Richard
hg: openjfx/8/graphics/rt: RT-21206: add applyCss to Node public API
Changeset: db9a779eeb38 Author:David Grievedavid.gri...@oracle.com Date: 2013-10-22 10:27 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/db9a779eeb38 RT-21206: add applyCss to Node public API Reviewed by: steve, phil, kevin, martin ! modules/graphics/src/main/java/com/sun/javafx/scene/CssFlags.java ! modules/graphics/src/main/java/javafx/scene/Node.java
Re: JavaFX on iOS and Android - are we there yet?
I would avoid image based CSS files… we should create pure CSS based skins using pure css styles and SVG paths… That would definitely be (a lot) more work, but if you're going to be scaling up the controls you will appreciate them being normal background fills paths. Richard
Re: JavaFX on iOS and Android - are we there yet?
javafx, like for instance: a toggle button (a control that looks like a flip switch) These have are just styled CheckBoxes (or Toggle buttons, or Radio Buttons). We've done this for example for DukePad. , comboboxes where you change the value through a wheel, etc.. Yes, need this kind of integration. and in having controls that have the necessary properties so that they can be touchable. Should already work. Richard
hg: openjfx/8/graphics/rt: 3 new changesets
Changeset: 5980afe89a4c Author:mickf Date: 2013-10-22 17:17 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5980afe89a4c RT-33713 : MenuBar sample seems to be leaking through F10 accelerator, reviewed by David ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/MenuBarSkin.java Changeset: 87a605e50354 Author:mickf Date: 2013-10-22 17:20 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/87a605e50354 RT-27898 : [Touch] ScrollBars disappear too quickly, reviewed by David ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: fbccbf6e7e8a Author:mickf Date: 2013-10-22 17:23 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/fbccbf6e7e8a RT-27897 : [Touch] ScrollBars should stay visible when users touch the screen, reviewed by David ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java
hg: openjfx/8/graphics/rt: 5 new changesets
Changeset: ceed8d426c0c Author:mhowe Date: 2013-10-20 19:27 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ceed8d426c0c update build.properties ! build.properties Changeset: 98accc42134c Author:mhowe Date: 2013-10-20 19:35 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/98accc42134c update build.properties ! build.properties Changeset: b5b14c01d4d6 Author:mhowe Date: 2013-10-21 12:37 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b5b14c01d4d6 RT-33666: [packager] javafxpackager loads AWT unconditionally [krushforth] ! modules/fxpackager/src/main/java/com/javafx/main/Main.java ! modules/fxpackager/src/main/java/com/javafx/main/NoJavaFXFallback.java Changeset: 5e2ca3c5b155 Author:mhowe Date: 2013-10-21 15:18 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5e2ca3c5b155 Merge Changeset: 50cde3719e4d Author:jgodinez Date: 2013-10-22 09:41 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/50cde3719e4d Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - modules/controls/src/main/java/com/sun/javafx/scene/control/skin/PasswordFieldSkin.java - modules/fxml/src/test/java/javafx/fxml/FXMLLoader_events.java - modules/fxml/src/test/java/javafx/fxml/RT_18046Test.java - modules/fxml/src/test/resources/javafx/fxml/rt_18046.fxml - obsolete/apps/build-defs.xml - obsolete/apps/build-tasks.xml - obsolete/apps/build.xml - obsolete/apps/experiments/3DViewer/3D Viewer.iml - obsolete/apps/experiments/3DViewer/build.xml - obsolete/apps/experiments/3DViewer/session.properties - obsolete/apps/experiments/ConferenceScheduleApp/build.xml - obsolete/apps/experiments/Modena/Modena.iml - obsolete/apps/experiments/Modena/build.xml - obsolete/apps/experiments/ModenaTest/build.xml - obsolete/apps/experiments/build.xml - obsolete/apps/samples/Ensemble8/Ensemble8.iml - obsolete/apps/samples/Ensemble8/build.xml - obsolete/apps/samples/build.xml - obsolete/base.properties - obsolete/build-decora.xml - obsolete/build-defs.xml - obsolete/build.xml - obsolete/common.properties - obsolete/decora-compiler/build-closed.xml - obsolete/decora-compiler/build-common.xml - obsolete/decora-compiler/build.xml - obsolete/decora-compiler/nbproject/project.xml - obsolete/decora-compiler/project.properties - obsolete/decora-d3d/build-closed.xml - obsolete/decora-d3d/build-common.xml - obsolete/decora-d3d/build.xml - obsolete/decora-d3d/decora-d3d.iml - obsolete/decora-d3d/nbproject/project.xml - obsolete/decora-d3d/project.properties - obsolete/decora-es2/build-closed.xml - obsolete/decora-es2/build-common.xml - obsolete/decora-es2/build.xml - obsolete/decora-es2/decora-es2.iml - obsolete/decora-es2/nbproject/project.xml - obsolete/decora-es2/project.properties - obsolete/decora-jsw/build-closed.xml - obsolete/decora-jsw/build-common.xml - obsolete/decora-jsw/build.xml - obsolete/decora-jsw/decora-jsw.iml - obsolete/decora-jsw/nbproject/project.xml - obsolete/decora-jsw/project.properties - obsolete/decora-prism-ps/build-closed.xml - obsolete/decora-prism-ps/build-common.xml - obsolete/decora-prism-ps/build.xml - obsolete/decora-prism-ps/decora-prism-ps.iml - obsolete/decora-prism-ps/nbproject/project.xml - obsolete/decora-prism-ps/project.properties - obsolete/decora-prism-sw/build-closed.xml - obsolete/decora-prism-sw/build-common.xml - obsolete/decora-prism-sw/build.xml - obsolete/decora-prism-sw/decora-prism-sw.iml - obsolete/decora-prism-sw/nbproject/project.xml - obsolete/decora-prism-sw/project.properties - obsolete/decora-prism/build-closed.xml - obsolete/decora-prism/build-common.xml - obsolete/decora-prism/build.xml - obsolete/decora-prism/decora-prism.iml - obsolete/decora-prism/nbproject/project.xml - obsolete/decora-prism/project.properties - obsolete/decora-runtime/build-closed.xml - obsolete/decora-runtime/build-common.xml - obsolete/decora-runtime/build.xml - obsolete/decora-runtime/decora-runtime.iml - obsolete/decora-runtime/nbproject/project.xml - obsolete/decora-runtime/project.properties - obsolete/decora-sse-native/Makefile - obsolete/decora-sse-native/nbproject/Makefile-Debug.mk - obsolete/decora-sse-native/nbproject/Makefile-Release.mk - obsolete/decora-sse-native/nbproject/Makefile-impl.mk - obsolete/decora-sse-native/nbproject/configurations.xml - obsolete/decora-sse-native/nbproject/project.xml - obsolete/decora-sse/build-closed.xml - obsolete/decora-sse/build-common.xml - obsolete/decora-sse/build-macosx.xml - obsolete/decora-sse/build-windows.xml - obsolete/decora-sse/build.xml - obsolete/decora-sse/decora-sse.iml - obsolete/decora-sse/nbproject/project.xml - obsolete/decora-sse/project.properties - obsolete/deploy/build.xml - obsolete/deploy/javafx-launcher/build.xml - obsolete/deploy/javafx-launcher/manifest.mf - obsolete/deploy/javafx-launcher/nbproject/build-impl.xml - obsolete/deploy/javafx-launcher/nbproject/genfiles.properties -
Change requiring b112 just pushed [was: hg: openjfx/8/graphics/rt: 5 new changesets]
During integration testing, we just pushed a change that makes JDK 8-b112 the minimum JDK needed. It really isn't need to build openjfx (there were some deploy UI interface changes that motivated this), you can just manually set this back to b111 and continue building. I expected that b112 would have been uploaded to java.net by now. Sorry for the inconvenience -- Kevin hang...@oracle.com wrote: Changeset: ceed8d426c0c Author:mhowe Date: 2013-10-20 19:27 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ceed8d426c0c update build.properties ! build.properties Changeset: 98accc42134c Author:mhowe Date: 2013-10-20 19:35 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/98accc42134c update build.properties ! build.properties Changeset: b5b14c01d4d6 Author:mhowe Date: 2013-10-21 12:37 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b5b14c01d4d6 RT-33666: [packager] javafxpackager loads AWT unconditionally [krushforth] ! modules/fxpackager/src/main/java/com/javafx/main/Main.java ! modules/fxpackager/src/main/java/com/javafx/main/NoJavaFXFallback.java Changeset: 5e2ca3c5b155 Author:mhowe Date: 2013-10-21 15:18 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5e2ca3c5b155 Merge Changeset: 50cde3719e4d Author:jgodinez Date: 2013-10-22 09:41 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/50cde3719e4d Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - modules/controls/src/main/java/com/sun/javafx/scene/control/skin/PasswordFieldSkin.java - modules/fxml/src/test/java/javafx/fxml/FXMLLoader_events.java - modules/fxml/src/test/java/javafx/fxml/RT_18046Test.java - modules/fxml/src/test/resources/javafx/fxml/rt_18046.fxml - obsolete/apps/build-defs.xml - obsolete/apps/build-tasks.xml - obsolete/apps/build.xml - obsolete/apps/experiments/3DViewer/3D Viewer.iml - obsolete/apps/experiments/3DViewer/build.xml - obsolete/apps/experiments/3DViewer/session.properties - obsolete/apps/experiments/ConferenceScheduleApp/build.xml - obsolete/apps/experiments/Modena/Modena.iml - obsolete/apps/experiments/Modena/build.xml - obsolete/apps/experiments/ModenaTest/build.xml - obsolete/apps/experiments/build.xml - obsolete/apps/samples/Ensemble8/Ensemble8.iml - obsolete/apps/samples/Ensemble8/build.xml - obsolete/apps/samples/build.xml - obsolete/base.properties - obsolete/build-decora.xml - obsolete/build-defs.xml - obsolete/build.xml - obsolete/common.properties - obsolete/decora-compiler/build-closed.xml - obsolete/decora-compiler/build-common.xml - obsolete/decora-compiler/build.xml - obsolete/decora-compiler/nbproject/project.xml - obsolete/decora-compiler/project.properties - obsolete/decora-d3d/build-closed.xml - obsolete/decora-d3d/build-common.xml - obsolete/decora-d3d/build.xml - obsolete/decora-d3d/decora-d3d.iml - obsolete/decora-d3d/nbproject/project.xml - obsolete/decora-d3d/project.properties - obsolete/decora-es2/build-closed.xml - obsolete/decora-es2/build-common.xml - obsolete/decora-es2/build.xml - obsolete/decora-es2/decora-es2.iml - obsolete/decora-es2/nbproject/project.xml - obsolete/decora-es2/project.properties - obsolete/decora-jsw/build-closed.xml - obsolete/decora-jsw/build-common.xml - obsolete/decora-jsw/build.xml - obsolete/decora-jsw/decora-jsw.iml - obsolete/decora-jsw/nbproject/project.xml - obsolete/decora-jsw/project.properties - obsolete/decora-prism-ps/build-closed.xml - obsolete/decora-prism-ps/build-common.xml - obsolete/decora-prism-ps/build.xml - obsolete/decora-prism-ps/decora-prism-ps.iml - obsolete/decora-prism-ps/nbproject/project.xml - obsolete/decora-prism-ps/project.properties - obsolete/decora-prism-sw/build-closed.xml - obsolete/decora-prism-sw/build-common.xml - obsolete/decora-prism-sw/build.xml - obsolete/decora-prism-sw/decora-prism-sw.iml - obsolete/decora-prism-sw/nbproject/project.xml - obsolete/decora-prism-sw/project.properties - obsolete/decora-prism/build-closed.xml - obsolete/decora-prism/build-common.xml - obsolete/decora-prism/build.xml - obsolete/decora-prism/decora-prism.iml - obsolete/decora-prism/nbproject/project.xml - obsolete/decora-prism/project.properties - obsolete/decora-runtime/build-closed.xml - obsolete/decora-runtime/build-common.xml - obsolete/decora-runtime/build.xml - obsolete/decora-runtime/decora-runtime.iml - obsolete/decora-runtime/nbproject/project.xml - obsolete/decora-runtime/project.properties - obsolete/decora-sse-native/Makefile - obsolete/decora-sse-native/nbproject/Makefile-Debug.mk - obsolete/decora-sse-native/nbproject/Makefile-Release.mk - obsolete/decora-sse-native/nbproject/Makefile-impl.mk - obsolete/decora-sse-native/nbproject/configurations.xml - obsolete/decora-sse-native/nbproject/project.xml - obsolete/decora-sse/build-closed.xml - obsolete/decora-sse/build-common.xml - obsolete/decora-sse/build-macosx.xml -
Re: Change requiring b112 just pushed [was: hg: openjfx/8/graphics/rt: 5 new changesets]
Btw, the file you will need to edit is build.properties, making the following change until b112 is available on java.net: diff --git a/build.properties b/build.properties --- a/build.properties +++ b/build.properties @@ -53,4 +53,4 @@ jfx.build.jdk.version=1.8.0 jfx.build.jdk.buildnum=112 -jfx.build.jdk.buildnum.min=112 +jfx.build.jdk.buildnum.min=111 -- Kevin Kevin Rushforth wrote: During integration testing, we just pushed a change that makes JDK 8-b112 the minimum JDK needed. It really isn't need to build openjfx (there were some deploy UI interface changes that motivated this), you can just manually set this back to b111 and continue building. I expected that b112 would have been uploaded to java.net by now. Sorry for the inconvenience -- Kevin hang...@oracle.com wrote: Changeset: ceed8d426c0c Author:mhowe Date: 2013-10-20 19:27 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ceed8d426c0c update build.properties ! build.properties Changeset: 98accc42134c Author:mhowe Date: 2013-10-20 19:35 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/98accc42134c update build.properties ! build.properties Changeset: b5b14c01d4d6 Author:mhowe Date: 2013-10-21 12:37 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b5b14c01d4d6 RT-33666: [packager] javafxpackager loads AWT unconditionally [krushforth] ! modules/fxpackager/src/main/java/com/javafx/main/Main.java ! modules/fxpackager/src/main/java/com/javafx/main/NoJavaFXFallback.java Changeset: 5e2ca3c5b155 Author:mhowe Date: 2013-10-21 15:18 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5e2ca3c5b155 Merge Changeset: 50cde3719e4d Author:jgodinez Date: 2013-10-22 09:41 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/50cde3719e4d Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - modules/controls/src/main/java/com/sun/javafx/scene/control/skin/PasswordFieldSkin.java - modules/fxml/src/test/java/javafx/fxml/FXMLLoader_events.java - modules/fxml/src/test/java/javafx/fxml/RT_18046Test.java - modules/fxml/src/test/resources/javafx/fxml/rt_18046.fxml - obsolete/apps/build-defs.xml - obsolete/apps/build-tasks.xml - obsolete/apps/build.xml - obsolete/apps/experiments/3DViewer/3D Viewer.iml - obsolete/apps/experiments/3DViewer/build.xml - obsolete/apps/experiments/3DViewer/session.properties - obsolete/apps/experiments/ConferenceScheduleApp/build.xml - obsolete/apps/experiments/Modena/Modena.iml - obsolete/apps/experiments/Modena/build.xml - obsolete/apps/experiments/ModenaTest/build.xml - obsolete/apps/experiments/build.xml - obsolete/apps/samples/Ensemble8/Ensemble8.iml - obsolete/apps/samples/Ensemble8/build.xml - obsolete/apps/samples/build.xml - obsolete/base.properties - obsolete/build-decora.xml - obsolete/build-defs.xml - obsolete/build.xml - obsolete/common.properties - obsolete/decora-compiler/build-closed.xml - obsolete/decora-compiler/build-common.xml - obsolete/decora-compiler/build.xml - obsolete/decora-compiler/nbproject/project.xml - obsolete/decora-compiler/project.properties - obsolete/decora-d3d/build-closed.xml - obsolete/decora-d3d/build-common.xml - obsolete/decora-d3d/build.xml - obsolete/decora-d3d/decora-d3d.iml - obsolete/decora-d3d/nbproject/project.xml - obsolete/decora-d3d/project.properties - obsolete/decora-es2/build-closed.xml - obsolete/decora-es2/build-common.xml - obsolete/decora-es2/build.xml - obsolete/decora-es2/decora-es2.iml - obsolete/decora-es2/nbproject/project.xml - obsolete/decora-es2/project.properties - obsolete/decora-jsw/build-closed.xml - obsolete/decora-jsw/build-common.xml - obsolete/decora-jsw/build.xml - obsolete/decora-jsw/decora-jsw.iml - obsolete/decora-jsw/nbproject/project.xml - obsolete/decora-jsw/project.properties - obsolete/decora-prism-ps/build-closed.xml - obsolete/decora-prism-ps/build-common.xml - obsolete/decora-prism-ps/build.xml - obsolete/decora-prism-ps/decora-prism-ps.iml - obsolete/decora-prism-ps/nbproject/project.xml - obsolete/decora-prism-ps/project.properties - obsolete/decora-prism-sw/build-closed.xml - obsolete/decora-prism-sw/build-common.xml - obsolete/decora-prism-sw/build.xml - obsolete/decora-prism-sw/decora-prism-sw.iml - obsolete/decora-prism-sw/nbproject/project.xml - obsolete/decora-prism-sw/project.properties - obsolete/decora-prism/build-closed.xml - obsolete/decora-prism/build-common.xml - obsolete/decora-prism/build.xml - obsolete/decora-prism/decora-prism.iml - obsolete/decora-prism/nbproject/project.xml - obsolete/decora-prism/project.properties - obsolete/decora-runtime/build-closed.xml - obsolete/decora-runtime/build-common.xml - obsolete/decora-runtime/build.xml - obsolete/decora-runtime/decora-runtime.iml - obsolete/decora-runtime/nbproject/project.xml - obsolete/decora-runtime/project.properties - obsolete/decora-sse-native/Makefile -
Re: V-up texture coordinate support
Hi Remi, Thanks for the feedback. Since we have decided to go with a Y-down 3D coordinate system it is natural, and for internal consistency, that we stick with a V-down texture. Yes, we have considered both (1-v) coordinates flip and image flip. Our preference is to do the coordinates flip in the shader if possible. - Chien On 10/21/2013 3:56 PM, Arnaud, Remi wrote: Hi Kevin and Chien, Most 3D data formats/files are using the 'openGL' convention (right handed, and V-up textures). A lot are using y-up, but this does not matter that much in regards to the texture V-up issue. Of course there is also the 'directX' convention (left handed, V-down textures). I think you have to decide which one of those two systems you want to use, and take ALL the conversions from one or the other system. There is no point creating yet another set of conventions. If you stick with a V-down texture, it would be nice to have a way to let the rendering engine take care of this. In all modern graphics API it is very simple to add (1-v) math to the vertex shader for instance. Without direct access to the shader, I would think a flag to set the V-up or V-down for a model would be a simple addition to the API. It is not hard to calculate new UV coordinates at load time, but it is prone to errors in case some other calculations depend on the UV coordinate system. Makes the code non portable. Alternatively, you may want to adopt the same help method used by WebGL (OpenGL convention) that has to live in a web browser, where Canvas 2D images are the other direction by default. In this case, the shader is not changed, but the image loader is loading the image upside down, keep 2 copies of the image in memory… see: gl.pixelStorei(gl.UNPACK_FLIP_Y_WEBGL, true); Regards -- Remi From: Chien Yang chien.y...@oracle.commailto:chien.y...@oracle.com Date: Thu, Oct 17, 2013 at 3:08 PM Subject: V-up texture coordinate support To: OpenJFX openjfx-dev@openjdk.java.netmailto:openjfx-dev@openjdk.java.net Hi all, Java images are defined such that (0, 0) references the top left most pixel of the image. In JavaFX, the texture coordinate system for 3D objects is defined with its U axis increasing from left to right and the V axis increasing from top to bottom. Hence a texture coordinate of (0, 0) references pixel (0, 0), which is the top left corner of the texture, and a texture coordinate of (1, 1) references the bottom right corner of the texture. This system matches the layout of the image, which is stored such that the top-most row of pixels ends up in memory in row 0. It also matches with the default 3D coordinate system used in JavaFX where the X axis increases from left to right and the Y axis increases from top to bottom. We understand that this V-down coordinate system maybe confusing or hard to work with for some 3D content developers when using models that are defined with Y-up. We could add a V-up option (as a boolean property of Shape3D). If set, we would flip the texture coordinates when rendering, such that: V' = 1 - V. However it is very late in this release to consider any more changes, so our plan is to add this option in a post FX 8 release if it turns out to be needed. Please let us know right away if there is a compelling need for V-up support in the FX 8 release. - Kevin and Chien
Re: JavaFX on iOS and Android - are we there yet?
I think you may be facing an absolute requirement which is placing demands on you to replicate the exact look and feel of one or both mobile environments? I'm not sure?? Even the most fab skins or CSS is not going to get us away from the need to integrate JavaFX controls with true native controls. As has been pointed out, there are some native controls on both iOS and Android for which there is no JavaFX equivalent and this will always be the case. Even if someone were to develop near identical lightweight controls in JavaFX, they would need to behave slightly differently on iOS than they do on Android and vice versa. I do not see the problem with the above? Yes, the controls in question would maybe act differently than their native counterparts and Yes there may not be the exact complement of controls each native platform has, but my reaction to that is… so what? The fact is, these controls are born of a different gui toolkit. This only is a problem if one has it stuck in their head that JavaFX has to behave em exactly /em like the native platform - I don't see why this is necessary, especially when the variations are minor behavioral aspects anyway? The CSS skinning in my opinion is to most closely approximate the native look and feel IMO. I just don't see why it is necessary to reproduce the iOS toolkit or the Android toolkit in JavaFX? This to me is a way to ensure rigidity and lack of movement. As long as what *does* exist is rock-solid, dependable and very close looking - then I say good enough. Otherwise, why not just use Objective-C or Android?? It is way better to have vertical movement and obvious progress, IMO. I did find the link to your 6 - degrees… publication - and I vow to read it in case my opinion comes down on the misguided side of things, but I just don't see the need for such a tight constraint??? Regards, David On Oct 22, 2013, at 3:26 PM, Felix Bembrick felix.bembr...@gmail.com wrote: Even the most fab skins or CSS is not going to get us away from the need to integrate JavaFX controls with true native controls. As has been pointed out, there are some native controls on both iOS and Android for which there is no JavaFX equivalent and this will always be the case. Even if someone were to develop near identical lightweight controls in JavaFX, they would need to behave slightly differently on iOS than they do on Android and vice versa. Then there's the issue that every time the OS changes and the behaviour or appearance of those native controls changes, the author of those JavaFX controls has to react accordingly. The issue of keyboard type and layouts is mentioned in my 6 Degrees of Separation post and is critical. There's just no way we are going to get away with any kind of text control that does not support all the native features of entering text on mobiles and tablets. Whether we place a borderless native text box inside a JavaFX shape or just integrate the native control itself, this is one of the most important features for a JavaFX app and one where it would fail spectacularly if this native support was not in place. I know some excellent work has been done on OS skins like AquaFX but appearance is only half the challenge. As I said, it's the behaviour that will kill us. To attempt to emulate all native control behaviour in lightweight controls is not only nearly impossible but in my view it's a massive waste of effort if it is somehow possible to integrate the actual native control itself. I am hopeful that the layering paradigm will gives us this. Another issue though is that native controls are unlikely to be as skinnable as JavaFX controls and are probably more limited in the scope of the customisation of their appearance. Integrating native controls may then impose limitations on the richness of the interface as it mandate an LCD approach so that the native controls don't look out of place. To me, the ideal solution would be to just extract/integrate the non-visual aspects of native controls (such as the auto-complete, keyboard customisations, other behaviour etc.) and then render them with the JavaFX API/scenegraph. On 23 October 2013 05:22, Stefan Fuchs snfu...@gmx.de wrote: Hi Richard, I currently try to release updates of the jfx78 back port in 1-3 days after https://bitbucket.org/**openjfxmirrors/openjfx-8-**master-rthttps://bitbucket.org/openjfxmirrors/openjfx-8-master-rt(from whereever this comes from) has been updated (usually every Friday). This obviously depends on the number of changes required and my available time. Stefan 2) After starting RoboVM JavaFX needs round about 10 seconds to start the simple list example on iPhone4. So it’s too long. I tried to use the preloaded class via property „-Djavafx.preloader“ but it doesn’t work, my preloaded class is not instantiated… What is the state of the jfx78 back port, and how often is
Re: JavaFX on iOS and Android - are we there yet?
Ok, I have read your 6 Degrees… publication, and I have to say I agree wholeheartedly with points 2 - 6. I just don't see why 90% of the common set of gui widgets, rock solid dependability and performance isn't good enough? Maybe others disagree I don't know… but if it comes down to being an engineering nightmare or so complex that the dependability or upgradeability is not there, then I just don't see it as important enough to warrant the abandonment of the effort? Regards, David On Oct 22, 2013, at 3:51 PM, David Ray cognitionmiss...@gmail.com wrote: I think you may be facing an absolute requirement which is placing demands on you to replicate the exact look and feel of one or both mobile environments? I'm not sure?? Even the most fab skins or CSS is not going to get us away from the need to integrate JavaFX controls with true native controls. As has been pointed out, there are some native controls on both iOS and Android for which there is no JavaFX equivalent and this will always be the case. Even if someone were to develop near identical lightweight controls in JavaFX, they would need to behave slightly differently on iOS than they do on Android and vice versa. I do not see the problem with the above? Yes, the controls in question would maybe act differently than their native counterparts and Yes there may not be the exact complement of controls each native platform has, but my reaction to that is… so what? The fact is, these controls are born of a different gui toolkit. This only is a problem if one has it stuck in their head that JavaFX has to behave em exactly /em like the native platform - I don't see why this is necessary, especially when the variations are minor behavioral aspects anyway? The CSS skinning in my opinion is to most closely approximate the native look and feel IMO. I just don't see why it is necessary to reproduce the iOS toolkit or the Android toolkit in JavaFX? This to me is a way to ensure rigidity and lack of movement. As long as what *does* exist is rock-solid, dependable and very close looking - then I say good enough. Otherwise, why not just use Objective-C or Android?? It is way better to have vertical movement and obvious progress, IMO. I did find the link to your 6 - degrees… publication - and I vow to read it in case my opinion comes down on the misguided side of things, but I just don't see the need for such a tight constraint??? Regards, David On Oct 22, 2013, at 3:26 PM, Felix Bembrick felix.bembr...@gmail.com wrote: Even the most fab skins or CSS is not going to get us away from the need to integrate JavaFX controls with true native controls. As has been pointed out, there are some native controls on both iOS and Android for which there is no JavaFX equivalent and this will always be the case. Even if someone were to develop near identical lightweight controls in JavaFX, they would need to behave slightly differently on iOS than they do on Android and vice versa. Then there's the issue that every time the OS changes and the behaviour or appearance of those native controls changes, the author of those JavaFX controls has to react accordingly. The issue of keyboard type and layouts is mentioned in my 6 Degrees of Separation post and is critical. There's just no way we are going to get away with any kind of text control that does not support all the native features of entering text on mobiles and tablets. Whether we place a borderless native text box inside a JavaFX shape or just integrate the native control itself, this is one of the most important features for a JavaFX app and one where it would fail spectacularly if this native support was not in place. I know some excellent work has been done on OS skins like AquaFX but appearance is only half the challenge. As I said, it's the behaviour that will kill us. To attempt to emulate all native control behaviour in lightweight controls is not only nearly impossible but in my view it's a massive waste of effort if it is somehow possible to integrate the actual native control itself. I am hopeful that the layering paradigm will gives us this. Another issue though is that native controls are unlikely to be as skinnable as JavaFX controls and are probably more limited in the scope of the customisation of their appearance. Integrating native controls may then impose limitations on the richness of the interface as it mandate an LCD approach so that the native controls don't look out of place. To me, the ideal solution would be to just extract/integrate the non-visual aspects of native controls (such as the auto-complete, keyboard customisations, other behaviour etc.) and then render them with the JavaFX API/scenegraph. On 23 October 2013 05:22, Stefan Fuchs snfu...@gmx.de wrote: Hi Richard, I currently try to release updates of the jfx78 back port in 1-3 days after
Re: JavaFX on iOS and Android - are we there yet?
Well I guess I am in the once bitten, a thousand times shy category after my experiences with Swing over the years. As I have mentioned in my blog posts, I believe the native look-and-feels for Swing were a monumental mistake. The first version of the Swing Windows look-and-feel for example left most people a bit gun shy because it was just so blatantly obviously different from the native OS and even now I don't feel that this look-and-feel is something I would ever want to use in an application I sold commercially. The problem is that is eerily similar to the native UI but sufficiently different to give the user a very uneasy feeling. It still makes a Swing application look like an imposter. One of the most notable issues was when Windows Vista arrived. Prior to then it was fairly easy to render a Windows progress bar in Swing but with Vista came an animated green progress bar that was never properly implemented in Swing. The problems across all controls worsened with Windows 7 and are now at their peak with Windows 8. The fact that Swing supports pluggable look and feels (PLAFs) is absolutely awesome and was quite revolutionary but to extrapolate that concept into making a native look and feel one of those was a huge mistake. The cross-platform PLAFs like Nimbus and even more so Substance that did not at all try to resemble any native UI were by far the best PLAFS to use. So I don't want to see all this repeated with JavaFX. Trust me, mobile/tablet users *will* spot the differences between a native app and a JavaFX app and they *will* be affected by this (especially Apple users). Steve Jobs would never have allowed this to happen and quite rightly so. So for mine, there are only two possible ways forward. 1. Use lightweight JavaFX controls exclusively. This is akin to Nimbus or Substance as a Swing PLAF. Then it's quite clear that the app is not trying to impersonate a native app and there is endless flexibility in the way the controls look and behave. The downside of course is that there can be no native controls used but it may still be possible to integrate the non-visual aspects of native controls like I mentioned earlier. 2. Implement the layering scheme where true native components are mixed with JavaFX controls. The advantage is that it will look and behave exactly like a native app with the added benefit that comes from the addition of lightweight controls. Option 1 is the most likely solution and is much easier to implement than option 2. Option 1 is limited in that it wouldn't be possible to utilise any native control rendering which would limit the types of native controls that could be used (iAds for example would be a no go). Option 2 is limited in that the native controls would be rendered by the OS and then the entire solution is limited by the range of transformations supported by the OS and also the degree of visual customisation available. I would really hope we can make Option 2 happen but Option 1 would be a perfectly acceptable way forward as well. FYI, here's my 6 Degrees post: http://justmy2bits.com/2013/09/30/javafx-on-ios-and-android-six-degrees-of-separation/ Felix On 23 October 2013 07:51, David Ray cognitionmiss...@gmail.com wrote: I think you may be facing an absolute requirement which is placing demands on you to replicate the exact look and feel of one or both mobile environments? I'm not sure?? Even the most fab skins or CSS is not going to get us away from the need to integrate JavaFX controls with true native controls. As has been pointed out, there are some native controls on both iOS and Android for which there is no JavaFX equivalent and this will always be the case. Even if someone were to develop near identical lightweight controls in JavaFX, they would need to behave slightly differently on iOS than they do on Android and vice versa. I do not see the problem with the above? Yes, the controls in question would maybe act differently than their native counterparts and Yes there may not be the exact complement of controls each native platform has, but my reaction to that is… so what? The fact is, these controls are born of a different gui toolkit. This only is a problem if one has it stuck in their head that JavaFX has to behave em exactly /em like the native platform - I don't see why this is necessary, especially when the variations are minor behavioral aspects anyway? The CSS skinning in my opinion is to most closely approximate the native look and feel IMO. I just don't see why it is necessary to reproduce the iOS toolkit or the Android toolkit in JavaFX? This to me is a way to ensure rigidity and lack of movement. As long as what *does* exist is rock-solid, dependable and very close looking - then I say good enough. Otherwise, why not just use Objective-C or Android?? It is way better to have vertical movement and obvious progress, IMO. I did find the link to your 6 -
Re: JavaFX on iOS and Android - are we there yet?
Yeah, the Swing file dialog is quite embarrassing... I accept that you can ship commercial software using the Swing Windows look and feel but only to certain types of customers and certain market niches. I do not believe you could compete with native applications in a more generic market sector though so I do not feel it is viable for most software houses. And that's what I am talking about here. Sure, we can get JavaFX for iOS and Android out the door and sure we can build pretty nice apps. But I want to be able to compete with the big boys and sell *serious, high-quality commercial software*. My dream is that JavaFX will enable me to do that. On 23 October 2013 08:44, Scott Palmer swpal...@gmail.com wrote: +1 for native keyboard support. Unless you want to emulate the dictation feature in iOS and all that kind of stuff, you pretty much have to use the native keyboard. But I think native widgets in general could be postponed, so long as JNI could be used to implement settings and the sort of thing that would be expected to have a lot of standard controls. Often in the main part of the app on iOS the UI is very customized anyway. I do ship a commercial app with Swing and the Windows LnF and except for the file dialog, nobody cared. Scott On Tue, Oct 22, 2013 at 5:20 PM, Felix Bembrick felix.bembr...@gmail.com wrote: Well I guess I am in the once bitten, a thousand times shy category after my experiences with Swing over the years. As I have mentioned in my blog posts, I believe the native look-and-feels for Swing were a monumental mistake. The first version of the Swing Windows look-and-feel for example left most people a bit gun shy because it was just so blatantly obviously different from the native OS and even now I don't feel that this look-and-feel is something I would ever want to use in an application I sold commercially. The problem is that is eerily similar to the native UI but sufficiently different to give the user a very uneasy feeling. It still makes a Swing application look like an imposter. One of the most notable issues was when Windows Vista arrived. Prior to then it was fairly easy to render a Windows progress bar in Swing but with Vista came an animated green progress bar that was never properly implemented in Swing. The problems across all controls worsened with Windows 7 and are now at their peak with Windows 8. The fact that Swing supports pluggable look and feels (PLAFs) is absolutely awesome and was quite revolutionary but to extrapolate that concept into making a native look and feel one of those was a huge mistake. The cross-platform PLAFs like Nimbus and even more so Substance that did not at all try to resemble any native UI were by far the best PLAFS to use. So I don't want to see all this repeated with JavaFX. Trust me, mobile/tablet users *will* spot the differences between a native app and a JavaFX app and they *will* be affected by this (especially Apple users). Steve Jobs would never have allowed this to happen and quite rightly so. So for mine, there are only two possible ways forward. 1. Use lightweight JavaFX controls exclusively. This is akin to Nimbus or Substance as a Swing PLAF. Then it's quite clear that the app is not trying to impersonate a native app and there is endless flexibility in the way the controls look and behave. The downside of course is that there can be no native controls used but it may still be possible to integrate the non-visual aspects of native controls like I mentioned earlier. 2. Implement the layering scheme where true native components are mixed with JavaFX controls. The advantage is that it will look and behave exactly like a native app with the added benefit that comes from the addition of lightweight controls. Option 1 is the most likely solution and is much easier to implement than option 2. Option 1 is limited in that it wouldn't be possible to utilise any native control rendering which would limit the types of native controls that could be used (iAds for example would be a no go). Option 2 is limited in that the native controls would be rendered by the OS and then the entire solution is limited by the range of transformations supported by the OS and also the degree of visual customisation available. I would really hope we can make Option 2 happen but Option 1 would be a perfectly acceptable way forward as well. FYI, here's my 6 Degrees post: http://justmy2bits.com/2013/09/30/javafx-on-ios-and-android-six-degrees-of-separation/ Felix On 23 October 2013 07:51, David Ray cognitionmiss...@gmail.com wrote: I think you may be facing an absolute requirement which is placing demands on you to replicate the exact look and feel of one or both mobile environments? I'm not sure?? Even the most fab skins or CSS is not going to get us away
hg: openjfx/8/graphics/rt: 2 new changesets
Changeset: 670ff992ef78 Author:Alexander Matveev alexander.matv...@oracle.com Date: 2013-10-22 14:29 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/670ff992ef78 Fix for RT-33719 - State transition on OS X for MP4 are not always work properly ! modules/media/src/main/native/jfxmedia/platform/osx/QTKMediaPlayer.mm Changeset: b6f0445dbd07 Author:Alexander Matveev alexander.matv...@oracle.com Date: 2013-10-22 14:31 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b6f0445dbd07 Fix for RT-31622 - StopTimeUpdatePlayingTest fails ! modules/media/src/main/java/com/sun/media/jfxmediaimpl/NativeMediaPlayer.java
Re: JavaFX on iOS and Android - are we there yet?
Even the most fab skins or CSS is not going to get us away from the need to integrate JavaFX controls with true native controls. As has been pointed out, there are some native controls on both iOS and Android for which there is no JavaFX equivalent and this will always be the case. Even if someone were to develop near identical lightweight controls in JavaFX, they would need to behave slightly differently on iOS than they do on Android and vice versa. I don't think this is exactly this straight forward. Ideally you would want to have this kind of native behavior on every platform. But having this native behavior involves having a different version of your app for each OS you want to deploy in, which might not be what the developers want. Remember JavaFX is a cross platform development kit and the major reason a developer would choose JavaFX over doing native mobile development is that his app can run on a variety of mobile platforms: windows 8, ipad, android, iPhone, etc with the same code base and *MOST* importantly with much less development time than building an app for each platform. For the sake of development time an app that doesn't go against any of the different platforms UX but that has the least common denominator so that each user in each different platform understands the UI might be a better solution for the sake of development time. One such example is the back button that appears when you drill down a list on an ios app but doesn't appear in an android app because every android phone as a physical back button. I do agree with you that there are some places where a native looking control is ideal and doesn't involve any extra effort from the developer to customize it for the given platform like for instance comboboxs where a kind of wheel appears where the user can choose an option, or input controls where the native keyboard pops up. Thanks, best regards, -- Pedro Duque Vieira
Re: JavaFX on iOS and Android - are we there yet?
Rather than arguing this point, the correct answer is to provide both and let the application developer choose. Do you guys know how old this argument is? Hint: It predates Java. Steve On 2013-10-22 6:17 PM, Pedro Duque Vieira wrote: Even the most fab skins or CSS is not going to get us away from the need to integrate JavaFX controls with true native controls. As has been pointed out, there are some native controls on both iOS and Android for which there is no JavaFX equivalent and this will always be the case. Even if someone were to develop near identical lightweight controls in JavaFX, they would need to behave slightly differently on iOS than they do on Android and vice versa. I don't think this is exactly this straight forward. Ideally you would want to have this kind of native behavior on every platform. But having this native behavior involves having a different version of your app for each OS you want to deploy in, which might not be what the developers want. Remember JavaFX is a cross platform development kit and the major reason a developer would choose JavaFX over doing native mobile development is that his app can run on a variety of mobile platforms: windows 8, ipad, android, iPhone, etc with the same code base and *MOST* importantly with much less development time than building an app for each platform. For the sake of development time an app that doesn't go against any of the different platforms UX but that has the least common denominator so that each user in each different platform understands the UI might be a better solution for the sake of development time. One such example is the back button that appears when you drill down a list on an ios app but doesn't appear in an android app because every android phone as a physical back button. I do agree with you that there are some places where a native looking control is ideal and doesn't involve any extra effort from the developer to customize it for the given platform like for instance comboboxs where a kind of wheel appears where the user can choose an option, or input controls where the native keyboard pops up. Thanks, best regards,
Re: JavaFX on iOS and Android - are we there yet?
Yes, having viable implementations of both options would be ideal. How long till Oracle and/or the community gets to that point? ;-) On 23 October 2013 10:06, Stephen F Northover steve.x.northo...@oracle.comwrote: Rather than arguing this point, the correct answer is to provide both and let the application developer choose. Do you guys know how old this argument is? Hint: It predates Java. Steve On 2013-10-22 6:17 PM, Pedro Duque Vieira wrote: Even the most fab skins or CSS is not going to get us away from the need to integrate JavaFX controls with true native controls. As has been pointed out, there are some native controls on both iOS and Android for which there is no JavaFX equivalent and this will always be the case. Even if someone were to develop near identical lightweight controls in JavaFX, they would need to behave slightly differently on iOS than they do on Android and vice versa. I don't think this is exactly this straight forward. Ideally you would want to have this kind of native behavior on every platform. But having this native behavior involves having a different version of your app for each OS you want to deploy in, which might not be what the developers want. Remember JavaFX is a cross platform development kit and the major reason a developer would choose JavaFX over doing native mobile development is that his app can run on a variety of mobile platforms: windows 8, ipad, android, iPhone, etc with the same code base and *MOST* importantly with much less development time than building an app for each platform. For the sake of development time an app that doesn't go against any of the different platforms UX but that has the least common denominator so that each user in each different platform understands the UI might be a better solution for the sake of development time. One such example is the back button that appears when you drill down a list on an ios app but doesn't appear in an android app because every android phone as a physical back button. I do agree with you that there are some places where a native looking control is ideal and doesn't involve any extra effort from the developer to customize it for the given platform like for instance comboboxs where a kind of wheel appears where the user can choose an option, or input controls where the native keyboard pops up. Thanks, best regards,
Re: JavaFX on iOS and Android - are we there yet?
On Oct 22, 2013, at 9:38 AM, Pedro Duque Vieira pedro.duquevie...@gmail.com wrote: These have are just styled CheckBoxes (or Toggle buttons, or Radio Buttons). We've done this for example for DukePad. Yes that's right but I think that as it is used so much on Android, ios and windows 8 it should have a control representation. For instance the same can be said of checkbox, you can make one out of a styled toggle button but as it is used so much it merits being a control. This is true. From a class count perspective (and embedded) it probably would have been better for us not to do CheckBox and RadioButton, but just do ToggleButton with some static final ints for doing the styling. But then again, maybe not. and in having controls that have the necessary properties so that they can be touchable. I'm talking about having the appropriate size for instance for you to touch it. You can't use Modena straight out for a mobile app. Perhaps having a Modena spinoff that has touch in mind. This is something worth thinking about. I noticed the fonts weren't the right size, implying that the port on iOS isn't picking up the best font size, and all the UI controls are sized based on the font, so in theory this might be sufficient. But it is true a spin-off with bigger insets might be necessary (but it isn't clear to me at least that this will be needed). What about input controls that popup the ios keyboard for entering text. Is this already available? If not how can these be achieved. Also we should keep in mind that the keyboard has to change in accordance to what the user has to enter: address, number, email, etc.. Yes, we already show the native keyboard. One mechanism we've discussed for input methods is to have some attributes you can add to a TextInputControl's properties map, which can then be used to show the right keyboard UI. Richard
hg: openjfx/8/graphics/rt: 2 new changesets
Changeset: c8cdab5d10df Author:jgiles Date: 2013-10-23 11:55 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c8cdab5d10df RT-33243: Accordion renders a gap between panes ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/AccordionSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TitledPaneSkin.java Changeset: 36bd10082500 Author:jgiles Date: 2013-10-23 12:17 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/36bd10082500 RT-33636: Accordion: Background of content is visible after close the pane ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TitledPaneSkin.java
Re: JavaFX on iOS and Android - are we there yet?
This is something worth thinking about. I noticed the fonts weren't the right size, implying that the port on iOS isn't picking up the best font size, and all the UI controls are sized based on the font, so in theory this might be sufficient. But it is true a spin-off with bigger insets might be necessary (but it isn't clear to me at least that this will be needed). I don't think basing the controls size on the font used is the best solution, at least for embeded/mobile. The design guidelines for each platform mention a min size a control should have so that your finger is able to touch it and there is no way 2 controls side by side can be mistakenly touched. This differs from platform to platform as each as its own studies on the size a control should have for you to easily touch it with a finger. So this is based on studies which are in turn based on peoples finger sizes. Yes, we already show the native keyboard. One mechanism we've discussed for input methods is to have some attributes you can add to a TextInputControl's properties map, which can then be used to show the right keyboard UI. Cool!! That's kind of the way you do it in HTML5: you add an attribute saying which type of text is going to be entered on the input field. Thanks, best regards, On Wed, Oct 23, 2013 at 12:35 AM, Richard Bair richard.b...@oracle.comwrote: On Oct 22, 2013, at 9:38 AM, Pedro Duque Vieira pedro.duquevie...@gmail.com wrote: These have are just styled CheckBoxes (or Toggle buttons, or Radio Buttons). We've done this for example for DukePad. Yes that's right but I think that as it is used so much on Android, ios and windows 8 it should have a control representation. For instance the same can be said of checkbox, you can make one out of a styled toggle button but as it is used so much it merits being a control. This is true. From a class count perspective (and embedded) it probably would have been better for us not to do CheckBox and RadioButton, but just do ToggleButton with some static final ints for doing the styling. But then again, maybe not. and in having controls that have the necessary properties so that they can be touchable. I'm talking about having the appropriate size for instance for you to touch it. You can't use Modena straight out for a mobile app. Perhaps having a Modena spinoff that has touch in mind. This is something worth thinking about. I noticed the fonts weren't the right size, implying that the port on iOS isn't picking up the best font size, and all the UI controls are sized based on the font, so in theory this might be sufficient. But it is true a spin-off with bigger insets might be necessary (but it isn't clear to me at least that this will be needed). What about input controls that popup the ios keyboard for entering text. Is this already available? If not how can these be achieved. Also we should keep in mind that the keyboard has to change in accordance to what the user has to enter: address, number, email, etc.. Yes, we already show the native keyboard. One mechanism we've discussed for input methods is to have some attributes you can add to a TextInputControl's properties map, which can then be used to show the right keyboard UI. Richard -- Pedro Duque Vieira
