Re: A lot WARING with CSS
I encountered the same issue when trying to run my demo application on Android with the JavaFx Android port. All my background and border styles wouldn't show up when I had any *-radius styles defined, once I removed those it was working fine. Back then I thought this was only an issue on Android, because when I ran my app on the desktop it was working fine. Regards, Yennick On 14/12/2013 21:27:28, Francisco Javier Godino jgod...@yahoo.com wrote: I have an application running perfectly with JAVAFX 2. I trying to migrate this application to OpenJFX 8. When I run the program, there is a lot of warning like: Executing C:\Desarrollos\NovoviaSistema8\dist\run1862230921\NovoviaSistema8.jar using platform C:\Program Files\Java\jdk1.8.0/bin/java dic 14, 2013 5:11:24 PM javafx.scene.CssStyleHelper lookup WARNING: caught: java.lang.ClassCastException: [Ljavafx.geometry.Insets; cannot be cast to [Ljavafx.scene.layout.CornerRadii; and the screen look is different. It's not considering my CSS as JAVAFX 2. Do I need to change somethings? Thanks
Re: A lot WARING with CSS
I'm having loads of CSS warnings and one or two class cast exceptions running the JFXtras samples (have been reporting them for a long while already). But there they do not seem to have any visual impact. On 2013-12-15 11:14, Yennick Trevels wrote: I encountered the same issue when trying to run my demo application on Android with the JavaFx Android port. All my background and border styles wouldn't show up when I had any *-radius styles defined, once I removed those it was working fine. Back then I thought this was only an issue on Android, because when I ran my app on the desktop it was working fine. Regards, Yennick On 14/12/2013 21:27:28, Francisco Javier Godino jgod...@yahoo.com wrote: I have an application running perfectly with JAVAFX 2. I trying to migrate this application to OpenJFX 8. When I run the program, there is a lot of warning like: Executing C:\Desarrollos\NovoviaSistema8\dist\run1862230921\NovoviaSistema8.jar using platform C:\Program Files\Java\jdk1.8.0/bin/java dic 14, 2013 5:11:24 PM javafx.scene.CssStyleHelper lookup WARNING: caught: java.lang.ClassCastException: [Ljavafx.geometry.Insets; cannot be cast to [Ljavafx.scene.layout.CornerRadii; and the screen look is different. It's not considering my CSS as JAVAFX 2. Do I need to change somethings? Thanks
accessibility
Hello, I have the following question: Does javafx support or plan to support accessibility? Another question is: if it is planned, then for what release?
Re: discussion about touch events
Pavel, I will summarize my answers here, and not inline, I hope I will touch all your points. Let me start my answer with a different perspective. I think that it is correct to try and make mouse oriented application to work under touch screens, but its not the same as looking how UI should behave with touch screens. To explain myself, here an example tested on the iPhone. It doesn't mean that we need to do the same, but rather a pointer for checking how UI can behave under touch. In iPhone, when you press on a control, say send button, and you start dragging it away the button will remain 'armed' for quite large distance, even if you drag it on top of other controls. Only after a large distance is passed, the button is been deactivated and the operation is canceled, this is true a cross the platform. What I'm trying to say that we first need to define how we would like touch behave from UI/UX point of view and only then try to resolve the technical issues. After saying that its very important to note that JFX is cross platform and device specific as smartphones are for example. So I believe that: - mouse events should act as mouse events (regardless to touch) - touch events should act as touch events (regardless to mouse) and - mouse applications that run on a touch device should have 80/20 functionality working i.e usable but not perfect (again the way the application behaved and designed could not overlap in 100%, like small UI elements) - a question how we want touch application work on mouse platform (migrating embedded application to desktop for example) But UI should behave differently on touch platforms and mouse platform, or more accurately when events derived from touch device or a pointer device. And this (mainly) is currently not supported. I would like to suggest the following, hoping its feasible for the next release (8u20 or 9) 1) define UI/UX requirements for touch devices 2) check overlaps and unique behavior between mouse and touch behaviors 3) suggest 3 UI paths 1) mouse based UI 2) touch based UI 3) common behavior 4) discuss and define technical approach We might end up in a solution very similar to what we have now, or as you said, something completely new. The challenge is to come to it with 'empty minds' (that why it would be best if UX engineer will define it and not us) Further more, I think that solutions like Glass generates a MOUSE_EXITED event any time all touches are released should be implemented in the shared code in not platform specific point, for obvious reasons as this example provide. I apologize if it was hinted that the technical chalnges are not imoprtent or not challenging, I meant that it isn't the time to tackle them (top down approach vs bottom-up) I believe that we both want to to deliver a top notch platform and not one that works most of the time, the difference between us, I think, is that I focus on the differences and you on the commonalities. Maybe it would be best if we assemble a team to discuss those issues by phone instead of mails, what do you think? Hope its clearer. Assaf On 12/12/2013 10:30 PM, Pavel Safrata wrote: Hi Assaf, please see my comments inline. On 20.11.2013 16:30, Assaf Yavnai wrote: Pavel, I think that this is a very good example why touch events should be processed separately from mouse events. For example, if you will press a button with a touch it will remain in hover state although you released the finger from the screen. This is done because the hover state listen to the mouse coordinates, which is invalid for touch. Touch events doesn't have the concept of move, only drag. My initial feeling would be for the synthesized mouse events to behave similarly to touch events - when touching the screen you want the application respond certain way regardless of the events used. Do we agree? Specifically, the hover problem can be solved quite easily. On iOS, Glass generates a MOUSE_EXITED event any time all touches are released, which clears the hover state of everything. I suppose all platforms can do that (for synthesized mouse events). As I mentioned before, from my point of view, the goal of this thread is to understand and map the difference and expected behavior between touch events and mouse events and have separate behavior depends of the type of events (Nodes, Controls and application level). One of them is the picking mechanism, the hover is another. I think the discussion of how to implement it is currently in lower priority, as it is only a technical detail. OK. Regarding picking, I believe the logical algorithm pick each pixel and find the touch-sensitive one closest to the center if there's any is the most natural behavior (just let me note that implementation is not really a technical detail because right now I don't see any way to implement it, so we might need to do something different). I already covered hover state. Another major
Re: [announce] InhiBeans: mitigate redundant recalculations
Interesting idea. There is a case I have been curious about and wonder what the best practices are for it. Suppose you have a case when you are changing multiple different properties that will be used in a single calculation. You want to deal with a single change to all of them in one go. E.g. imagine you have an area property that is bound to both width and height. You want to write code like: obj.setWidth(w); obj.setHeight(h); and have only ONE recalculation of the area property happen. Currently the way bindings work the area will be calculated twice. The intermediate calculation is really not a value that you ever want to observe. Are there helpers for this sort of situation? Are there guidelines in the JavaFX docs somewhere? Regards, Scott On Sat, Dec 14, 2013 at 11:54 PM, Tomas Mikula tomas.mik...@gmail.comwrote: Hello, I just published a small extension of javafx bindings and properties that can help you reduce redundant recalculations. They provide two additional methods: public void block(); public void release(); Call p.block() when you suspect your actions will lead to multiple invalidations of p, and call p.release() when you are done and want to deliver a single invalidation notification to p's observers. https://github.com/TomasMikula/InhiBeans Regards, Tomas
Re: [announce] InhiBeans: mitigate redundant recalculations
Since you are only allowed to modify properties on the JavaFX thread (in most cases), I've been using Platform.runLater() to make sure I observe only complete changes. Basically I register an InvalidationListener on the properties that are relevant, and when one gets triggered I set a boolean and trigger a Runnable that will be run on the JavaFX thread later (and after the change completes). The Runnable checks the relevant values and acts on them, then resets the boolean. I use this mechanism for example when I'm observing Objects with many properties that need to be stored in a database. To make sure I only store consistent objects, I only observe the values of the properties when my own little piece of observer code runs on the JavaFX thread. Since nothing can modify the properties except on the JavaFX thread, this is almost like a form of transactions, ensuring that every change has completed before observing the results. --John On 15/12/2013 18:39, Scott Palmer wrote: Interesting idea. There is a case I have been curious about and wonder what the best practices are for it. Suppose you have a case when you are changing multiple different properties that will be used in a single calculation. You want to deal with a single change to all of them in one go. E.g. imagine you have an area property that is bound to both width and height. You want to write code like: obj.setWidth(w); obj.setHeight(h); and have only ONE recalculation of the area property happen. Currently the way bindings work the area will be calculated twice. The intermediate calculation is really not a value that you ever want to observe. Are there helpers for this sort of situation? Are there guidelines in the JavaFX docs somewhere? Regards, Scott On Sat, Dec 14, 2013 at 11:54 PM, Tomas Mikulatomas.mik...@gmail.comwrote: Hello, I just published a small extension of javafx bindings and properties that can help you reduce redundant recalculations. They provide two additional methods: public void block(); public void release(); Call p.block() when you suspect your actions will lead to multiple invalidations of p, and call p.release() when you are done and want to deliver a single invalidation notification to p's observers. https://github.com/TomasMikula/InhiBeans Regards, Tomas
Re: [announce] InhiBeans: mitigate redundant recalculations
Yes, that does the trick, but this basically means you can't use bindings for such things. I'm wondering if there might be an opportunity for another enhancement similar to the block() resume() that Tomas has implemented, but for receiving size of the notification mechanism. Effectively it would operate on a bound property and prevent the re-evaluation until the resume() is called. When resume is called the property binding would check if it was invalidated since it was blocked and do the appropriate recalculation. E.g. property.blockEvaluation(), property.resumeEvaluation(), only callable on a property that is bound. I haven't thought it through yet, so I'm not sure if it buys much. Scott On Sun, Dec 15, 2013 at 2:30 PM, John Hendrikx hj...@xs4all.nl wrote: Since you are only allowed to modify properties on the JavaFX thread (in most cases), I've been using Platform.runLater() to make sure I observe only complete changes. Basically I register an InvalidationListener on the properties that are relevant, and when one gets triggered I set a boolean and trigger a Runnable that will be run on the JavaFX thread later (and after the change completes). The Runnable checks the relevant values and acts on them, then resets the boolean. I use this mechanism for example when I'm observing Objects with many properties that need to be stored in a database. To make sure I only store consistent objects, I only observe the values of the properties when my own little piece of observer code runs on the JavaFX thread. Since nothing can modify the properties except on the JavaFX thread, this is almost like a form of transactions, ensuring that every change has completed before observing the results. --John On 15/12/2013 18:39, Scott Palmer wrote: Interesting idea. There is a case I have been curious about and wonder what the best practices are for it. Suppose you have a case when you are changing multiple different properties that will be used in a single calculation. You want to deal with a single change to all of them in one go. E.g. imagine you have an area property that is bound to both width and height. You want to write code like: obj.setWidth(w); obj.setHeight(h); and have only ONE recalculation of the area property happen. Currently the way bindings work the area will be calculated twice. The intermediate calculation is really not a value that you ever want to observe. Are there helpers for this sort of situation? Are there guidelines in the JavaFX docs somewhere? Regards, Scott On Sat, Dec 14, 2013 at 11:54 PM, Tomas Mikulatomas.mik...@gmail.com wrote: Hello, I just published a small extension of javafx bindings and properties that can help you reduce redundant recalculations. They provide two additional methods: public void block(); public void release(); Call p.block() when you suspect your actions will lead to multiple invalidations of p, and call p.release() when you are done and want to deliver a single invalidation notification to p's observers. https://github.com/TomasMikula/InhiBeans Regards, Tomas
hg: openjfx/8u-dev/rt: RT-34564: PieChart labels are overlapped by control
Changeset: dd01cc258204 Author:jgiles Date: 2013-12-13 11:59 +1300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/dd01cc258204 RT-34564: PieChart labels are overlapped by control ! modules/controls/src/main/java/javafx/scene/chart/PieChart.java
Fwd: Re: accessibility
Resending because of wrong recipient: -- Treść oryginalnej wiadomości -- Temat: Re: accessibility Data: Sun, 15 Dec 2013 17:05:55 +0100 Nadawca: Michał Zegan webczat_...@poczta.onet.pl Adresat: Joe McGlynn joe.mcgl...@oracle.com Unless my informations are outdated, I know that at this time java fx 8 does not have any accessibility or accessibility-related api, so it's the reason for the question W dniu 2013-12-15 16:05, Joe McGlynn pisze: Hi Michał,http://www.oracle.com/commitment This is a top priority for us, look for more information here as plans firm up. http://www.oracle.com/commitment http://www.oracle.com/commitment http://www.oracle.com/commitment On Dec 15, 2013, at 4:15 AM, Michał Zegan webczat_...@poczta.onet.pl mailto:webczat_...@poczta.onet.pl wrote: Hello, I have the following question: Does javafx support or plan to support accessibility? Another question is: if it is planned, then for what release?
Re: [announce] InhiBeans: mitigate redundant recalculations
On Sun, Dec 15, 2013 at 6:39 PM, Scott Palmer swpal...@gmail.com wrote: Interesting idea. There is a case I have been curious about and wonder what the best practices are for it. Suppose you have a case when you are changing multiple different properties that will be used in a single calculation. You want to deal with a single change to all of them in one go. E.g. imagine you have an area property that is bound to both width and height. You want to write code like: obj.setWidth(w); obj.setHeight(h); and have only ONE recalculation of the area property happen. Currently the way bindings work the area will be calculated twice. The intermediate calculation is really not a value that you ever want to observe. Hi Scott, this is precisely the problem that I'm trying to address here. Now, the question is whether you have control over the implementation of obj. If yes, then it is the same case as the AND gate motivational example from InhiBeans page. You provide a method setSize(w, h) and use block()/release() to implement it in a way that causes only one change of the area property. If you cannot change the implementation of obj, what you can do is to bind an inhibeans.binding.DoubleBinding to the area value, call it relaxedArea, and listen to that one for all your purposes. Then you resize obj like this: relaxedArea.block(); obj.setWidth(); obj.setHeight(); relaxedArea.release(); Only one change of relaxedArea is emitted. Best, Tomas Are there helpers for this sort of situation? Are there guidelines in the JavaFX docs somewhere? Regards, Scott On Sat, Dec 14, 2013 at 11:54 PM, Tomas Mikula tomas.mik...@gmail.com wrote: Hello, I just published a small extension of javafx bindings and properties that can help you reduce redundant recalculations. They provide two additional methods: public void block(); public void release(); Call p.block() when you suspect your actions will lead to multiple invalidations of p, and call p.release() when you are done and want to deliver a single invalidation notification to p's observers. https://github.com/TomasMikula/InhiBeans Regards, Tomas
