hg: openjfx/8/graphics/rt: RT-33183 [MenuButton, SplitMenuButton] minWidth is too large
Changeset: 288eb8869c9c Author:Martin Sladecek martin.slade...@oracle.com Date: 2013-10-23 09:51 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/288eb8869c9c RT-33183 [MenuButton, SplitMenuButton] minWidth is too large Reviewed-by : jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/MenuButtonSkinBase.java
Re: mouse vs. touch events on touch systems like iOS/Android/Dukepad
Matthias, Please look inline On 10/22/2013 07:33 PM, Richard Bair wrote: Hi Matthias, I think Assaf, one of the embedded engineers, is now on the mailing list and can help answer these questions. Thanks Richard On Oct 21, 2013, at 1:58 AM, Matthias Hänel hae...@ultramixer.com wrote: Hi, I believe my conceptual question on touch/mouse events has been missed because of the other questions in the JAVAFX on ANDROID thread. That's why I would like to start a new discussion about touch events. 1. The main question is how are touch and internal mouse events handled? Javafx controls seem to rely on mouse events. That's why I assume there must be some kind of an emulation layer. Are these emulated in Prism, Glass (Java-Glasses) or even lower? Where is it suppose to emulate the mouse events? What I've seen right now is that iOS-native glass does the mouse emulation by itself in GlassViewDelegate.m. Touch events and Mouse events are sent from the lowest layer. In Android there are only touch events passed to the lens implementation. On udev which I assume is the implementation that's used for Dukepad it does only pass touch events. Udev and Android are lens implementations so, they are using the same Java classes which do kind of mouse emulation for toch events. But it's not exactly the same as the iOS codes does. iOS: sends Touch, Mouse-Enter and Mouse-Down Lens (Android/Dukepad): sends Mouse-Enter and Touch The major differences in calling order and the missung mouse down leeds me to the assumption that the events are actually missing. Basically the Glass port resbonsible to simulate mouse events from touch events. On Windows, for example, its done automaticaly by the OS, in other implementations its emulated in the native layer, in Lens currently its done in several places and layers (the input driver, the window manger and the java glass code). There are currently several issues with the touch support in Lens implementaion that effects all the ports that are using it. You can track the work through the master bug RT-32802. https://javafx-jira.kenai.com/browse/RT-32802 I'm curently working on solving those issues, and one of the fixes is to make mouse simulation more unified. Please feal free to open more bugs for specific scenrios and link them to the master bug, so we can track it and solve it. 2. Is that mouse emulation supposed to be eliminated due to the latest lensWindow changes? I believe that must be handled in higher layers not in the input layer itself. What do you mean by 'latest lensWindow changes'? please clarify the question. 3. What is the input layer for the Dukepad? I think it's the udev implementation and this does pretty much the same as the current android implementation. I just want to have a stable reference to look at ;) The input driver, as we call it, is depend on the system you are running and not the application you are running. From Application prespective its all the same. So on embedded devices, like the Raspberry PI, it will be udevInput, on Windows it will be Window's Glass implementation (not Lens based), on Android it will be Android porting + Lens and so on. 4. Has anyone with a Dukepad the opportunity to test the ListView-Example? For me on Android, it doesn't scroll at all with any touches. With the automatic scrolling (from Richard sources) I get around 30fps on the Samsung Galaxy Tab 10.1. I didn't. Again if you find a problem or a bug please open a JIRA against so we will be able to track and fix it. Thanks, Assaf regards Matthias
Re: mouse vs. touch events on touch systems like iOS/Android/Dukepad
Hi Matthias, I have a small note to mouse emulation. Windows tablet was chosen as a reference for touch/mouse events emulation in JavaFX, because Windows on tablets had to deal with same sort of problems as JavaFX - i.e. support existing 'mouse-driven' applications on touch devices. When we implemented (multi)touch + mouse emulation for JavaFX on iOS we followed this model as close as possible. Regards, Oldrich Hi, I believe my conceptual question on touch/mouse events has been missed because of the other questions in the JAVAFX on ANDROID thread. That's why I would like to start a new discussion about touch events. 1. The main question is how are touch and internal mouse events handled? Javafx controls seem to rely on mouse events. That's why I assume there must be some kind of an emulation layer. Are these emulated in Prism, Glass (Java-Glasses) or even lower? Where is it suppose to emulate the mouse events? What I've seen right now is that iOS-native glass does the mouse emulation by itself in GlassViewDelegate.m. Touch events and Mouse events are sent from the lowest layer. In Android there are only touch events passed to the lens implementation. On udev which I assume is the implementation that's used for Dukepad it does only pass touch events. Udev and Android are lens implementations so, they are using the same Java classes which do kind of mouse emulation for toch events. But it's not exactly the same as the iOS codes does. iOS: sends Touch, Mouse-Enter and Mouse-Down Lens (Android/Dukepad): sends Mouse-Enter and Touch The major differences in calling order and the missung mouse down leeds me to the assumption that the events are actually missing. 2. Is that mouse emulation supposed to be eliminated due to the latest lensWindow changes? I believe that must be handled in higher layers not in the input layer itself. 3. What is the input layer for the Dukepad? I think it's the udev implementation and this does pretty much the same as the current android implementation. I just want to have a stable reference to look at ;) 4. Has anyone with a Dukepad the opportunity to test the ListView-Example? For me on Android, it doesn't scroll at all with any touches. With the automatic scrolling (from Richard sources) I get around 30fps on the Samsung Galaxy Tab 10.1. regards Matthias
hg: openjfx/8/graphics/rt: 2 new changesets
Changeset: 29ce5c785087 Author:Martin Sladecek martin.slade...@oracle.com Date: 2013-10-23 14:24 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/29ce5c785087 RT-29577 FXML support for 3D meshes, lights, and materials Reviewed-by: ekrejcir ! modules/fxml/src/main/java/com/sun/javafx/fxml/builder/TriangleMeshBuilder.java + modules/fxml/src/test/java/javafx/fxml/FXMLLoader_BuilderTest.java + modules/fxml/src/test/resources/javafx/fxml/builders_trianglemesh.fxml Changeset: 7446c9bf91dd Author:Martin Sladecek martin.slade...@oracle.com Date: 2013-10-23 14:26 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7446c9bf91dd [TESTS] improved trianglemesh builder tests ! modules/fxml/src/test/resources/javafx/fxml/builders_trianglemesh.fxml
hg: openjfx/8/graphics/rt: RT-33772 Remove glFlush from EGLFBGLDrawable.nSwapBuffers
Changeset: 42c2c77eb5bd Author:Daniel Blaukopf daniel.blauk...@oracle.com Date: 2013-10-23 16:52 +0300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/42c2c77eb5bd RT-33772 Remove glFlush from EGLFBGLDrawable.nSwapBuffers Reviewed-by: Lisa Selle ! modules/graphics/src/main/native-prism-es2/eglfb/EGLFBGLDrawable.c
Re: [API Review]: Make SubScene Resizable (RT-31377)
Richard?
On 18.9.2013 17:16, Pavel Safrata wrote:
Hi Richard,
do I understand correctly that you prefer replacing the existing
constructors by the following?
public SubScene(Parent root, double width, double height, boolean
resizable, boolean depthBuffer, boolean antiAliasing)
public SubScene(Parent root, double width, double height, boolean
resizable)
Thanks,
Pavel
On 18.9.2013 16:59, Richard Bair wrote:
I think it is better to be explicit in all cases.
On Sep 18, 2013, at 7:47 AM, Pavel Safrata pavel.safr...@oracle.com
wrote:
Thanks, guys. Let me stay focused on the SubScene for now. Looks
like #2 wins. After some more thinking it turns out the boolean
isResizable constructor argument is not ideal because giving size to
a resizable subscene doesn't make much sense (it is resized as soon
as it is placed in layout so the initial size is not really used).
So I think it would be better to add constructors without the size
and set the resizability implicitly according to the constructor
used. It might not be immediately clear but to me it still seems
better than requiring two useless arguments.
To make this more formal API review, I propose the following:
The existing constructors will stay the same and continue to create
a fixed-size subscene:
public SubScene(Parent root, double width, double height, boolean
depthBuffer, boolean antiAliasing)
public SubScene(Parent root, double width, double height)
Add new constructors creating a resizable subscene:
public SubScene(Parent root, boolean depthBuffer, boolean antiAliasing)
public SubScene(Parent root)
The resizable subscene will forward root's min/pref/max sizes, the
non-resizable subscene will continue to use the user-set
width/height property value.
Just for completness, the other option is to replace the long
constructor with
public SubScene(Parent root, double width, double height, boolean
resizable, boolean depthBuffer, boolean antiAliasing)
and document the width and height arguments to be of virtually no
use in the resizable case. Let me know if you'd prefer this option.
Thanks,
Pavel
On 17.9.2013 16:59, Richard Bair wrote:
Personally I wish that it were possible to use pattern #2 with
Rectangle, ImageView, and a bunch of others as well. Anything that
*could* be resizable should have an option to be resizable. Heck, I
wish it were possible to turn resizable on/off dynamically for
SubScene or the others, not just an immutable property.
But an immutable property with a constructor to set it is a good
first step (especially since we don't have time in this release to
do anything more comprehensive or radical).
Richard
On Sep 17, 2013, at 1:15 AM, Pavel Safrata
pavel.safr...@oracle.com wrote:
Hello,
we want to make SubScene resizable (reporting min/pref/max sizes
according to its root) for it to behave nicely when placed in
layout ( https://javafx-jira.kenai.com/browse/RT-31377 ). For the
main driver of SubScene's existence - 2D overlays over 3D content
- this makes perfect sense. However, there are use-cases where the
fixed size is needed. Mainly, every SubScene with 3D content
probably wants the fixed size as the content bounds are not really
meaningful after the perspective projection. So, we need to
support both resizable and non-resizable SubScene.
There are two basic options:
1. Follow the pattern used in layouts. As SubScene is not a layout
class (doesn't inherit from Region), this would mean adding the
six methods ( set{Min|Pref|Max}{Width|Height} ) and duplicating
the Region's USE_COMPUTED_SIZE constant.
+ consistent with layouts
- duplicated API
- user needs six calls to make sure the SubScene has fixed size
2. Add an isResizable constructor argument, then just make the
SubScene report root's min/pref/max sizes in the resizable case.
+ easy to use the SubScene in the fixed-size manner (and
resizable, too)
+ small API change
- probably an unfamiliar pattern we don't have elsewhere (but,
SubScene is a pretty unique node)
What do you think?
Thanks,
Pavel
Re: What is com.sun.glass.ui.Application.EventHandler used for?
Hi Richard, We're going to provide some sort of public API for all these events in a future release. Please see the following RFE for details: https://javafx-jira.kenai.com/browse/RT-18866 -- best regards, Anthony On 10/23/2013 04:54 AM, Richard Bair wrote: I'm looking at Glass Application.EventHandler. It appears to only be used by QuantumToolkit in one place. Although the interface defines 13 methods or so, only one appears to ever be implemented? What is the story behind this class, or should it mostly be nuked? Richard
hg: openjfx/8/graphics/rt: RT-33781 Ensemble8: Fix regressed bar color in AudioClip
Changeset: 864db17fb10d Author:dmasada Date: 2013-10-23 10:20 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/864db17fb10d RT-33781 Ensemble8: Fix regressed bar color in AudioClip ! apps/samples/Ensemble8/src/generated/java/ensemble/generated/Samples.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/media/alphamediaplayer/PlanetaryPlayerPane.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/media/audioclip/AudioClipApp.java
Re: JavaFX on iOS and Android - are we there yet?
Yes, definitely. On Oct 23, 2013, at 11:52 AM, Scott Palmer swpal...@gmail.com wrote: This is starting to sound like it may also partially address the issue in the desktop space of supplying a native surface (the heavyweight) to draw in that is part of the scene graph. It may not be the ideal solution, but could be useful for specific use cases, like a video preview overlay. Would that make any sense? Scott On Tue, Oct 22, 2013 at 7:59 PM, Richard Bair richard.b...@oracle.com wrote: To do this we need to either solve the auto-layer problem in the NG nodes / Glass / Quantum, or we need to ask the app developer to use SubScene and put all the native stuff in a single SubScene, and all lightweight content above and below it. For the short term, we could use the SubScene approach (Just be careful and don't draw lightweight on top of heavyweights unless you layer an entire sub scene above them) which is probably a perfectly workable solution in the short term. Then somebody just needs to write a set of skins (which can be done in an external project) that map various UI controls directly to native controls. This approach would allow people to have completely native controls while using the FX API, or they can use the lightweight controls (with Modena or with an iOS 7 skin or iOS 6 skin etc). I'm thinking about how to implement the auto-layer, and I'm not sure of the best approach. It seems like you need to hook into the sync-time to determine which nodes can be batched into the same layer, reusing previous layers where possible. If there is a way to then setup the NG peer side so that it thinks it was setup in sub scenes etc, although it really wasn't, then that would leave prism out of the problem (which makes this an easier thing to pull off). hmmm. SubScene itself has a peer. So what I'm thinking is, suppose I have a package: com.sun.javafx.ext.ios.controls and in this package you have all the skins. There is also someplace in here a map of skin - sub scene peer, indicating which of the nodes is in which sub scene peer (layer). Then when the sync takes place, a skin node looks back at siblings etc to determine if it can be placed in the same layer as something before it. If so, then it sets itself as a child on the sub scene as needed. If not, then it creates a new sub scene peer and sets itself on there and then carry on. So then it isn't sync'd to the real scene but instead to one of these fake sub scenes that was created. The idea can be refined, but actually I think this approach might be workable for doing auto-layering. Richard On Oct 22, 2013, at 4:10 PM, Felix Bembrick felix.bembr...@gmail.com wrote: 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
