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: JavaFX on Android build (instructions)
Thanks Johan for gathering this information! I just tried to run my simple JavaFx application on Android with your build instructions, and I got it build and deployed rather easily. When trying to run it the UI appeared (albeit rather distorted), but when touching the app it crashed, I guess because of the know touch issues. Also, my app was using Google Guice, which gave me some reflection errors when trying the run it on the device (it crashed upon startup). So I swapped Guice with RoboGuice and it worked (for as far as I could test it). So for anyone who wants some dependency injection in their JavaFx Android app, try out RoboGuice as it seems to work. Greetz, Yennick On 26/11/2013 14:29:50, Sebastian Rheinnecker sebastian.rheinnec...@yworks.com wrote: Hi, I used your instructions with some tweaks to build a JavaFX application for android on Windows. However, it turns out that Android's dex format is putting a spoke into our wheel with the 65k method reference limit. The JavaFX runtime itself already contains 51k method references and because of that I was not yet able to bring our full application showcase to android. So if some android expert could contribute to the project by showing how to use multiple dex files, one containing the javafx runtime and one for the application, that would be great. Any help on the mailing list is appreciated as well. Kind regards, Sebastian Rheinnecker Am 16.11.2013 19:53, schrieb Johan Vos: Hi, Since I (and others) think it is very important that we can have JavaFX applications running on Android (and IOS, but in this mail I limit myself to Android), I created a bitbucket project containing code and build instructions to run JavaFX applications on Android. I didn't do much myself. Rather, this project is about providing easy and consistent build instructions. I combined information from this mailinglist with information I could find online, and with help from the JavaFX team. The project is here: https://bitbucket.org/johanvos/jfx78 After I gathered the information, it didn't cost me much time to get HelloWorld running on my Samsung S3 mini. I never wrote an Android project before, and I never used the Android SDK or NDK before I started with this thing almost a week ago. Hence, it is not that hard to create a JavaFX application on Android. This project is far from finished. There are a number of things that have to be done: * Improve build instructions * Simplify build * Fix bugs (e.g. touch-events are not processed yet) * Manage the synchronization with the main JavaFX repo * create plugins for IDE's or maven to automatically build the Android packages I want to open this project at this early stage, though, since I think it is important to have more community input. Also, I want to give a shout to the world that JavaFX on Android is not a dream. I hope many of you try out the instructions, improve them, correct them, and test your applications on Android. Thanks a lot to all the people on this mailinglist for telling how they were dealing with JavaFX on Android. Again, I didn't write much code, but rather tried to combine the information and make it useful for everybody. I know there is an intense debate about the role of Oracle on the Android (and IOS) ports. Let me close with a similar situation. About 17 years ago (sigh, time flies), I was involved with the port of Java to Linux, as part of the Blackdown team. Initially, we didn't get much help from Sun Microsystems (it was even not easy to get the latest code). But once we showed that we could run the thing on Linux, and that many developers were interested in it, Sun started to add resources on this as well. Eventually, we became obsolete. I hope to reach the obsolete stage on this project as well. Again, the project can be found here:https://bitbucket.org/johanvos/jfx78 - Johan -- Sebastian Rheinnecker phone: +49 7071 9709050 fax: +49 7071 9709051 yWorks GmbH Vor dem Kreuzberg 28 72070 Tuebingen Germany http://www.yworks.com Managing Directors: Sebastian Müller, Michael Pfahler Commercial Registry: Stuttgart, Germany, HRB 382340
Re: Use ScenePulseListener to avoid expensive recalculations?
Isn't it somewhat counter-intuitive to perform such changes in one of the
computePref*() methods? You're adding children in a method which is
supposed to compute the preferred width/height.
There should be a better way to do this. In Apache Flex for example,
there's a commitProperties() and updateDisplayList() method in which you
can do these things, which are called somewhat similar to a pulse in JavaFx
(except that you have to invalidate them yourself).
On Tue, Nov 5, 2013 at 8:10 PM, Jonathan Giles jonathan.gi...@oracle.comwrote:
You're right in that controls don't tend to use ScenePulseListener. This
may be due to an oversight on our part, or just that our requirements
differ (I don't honestly know).
You're also right that it is important to batch up property changes and
do them once per pulse, rather than as they come in. If this is not done
you do indeed get a severe performance hit (I remember back in the day
before I optimised many of the controls in this way, the performance
impact of not doing this was staggering).
The way I do it is simple: in places where I receive events from
properties / bindings / listeners, where I know that there is
potentially a lot of changes coming through, I create a boolean (e.g.
'refreshView' or somesuch). I then set this boolean to true, and in the
appropriate place in the code (most commonly layoutChildren(), but
sometimes in the computePref*() methods), I start the method with code
like this:
if (refreshView) {
doExpensiveOperationThatShouldHappenOnlyOncePerPulse();
refreshView = false;
}
The reason why I sometimes use layoutChildren() and sometimes the
computePref*() methods comes down to the (new) rule in JavaFX 8.0 that
you can not change the children list of a node within the
layoutChildren() method. Because of this, if I need to modify the
children list, I put the above code in the computePref*() method.
I hope that helps.
-- Jonathan
On 6/11/2013 3:58 a.m., John Hendrikx wrote:
Hi List,
I'm considering using a ScenePulseListener to avoid expensive
recalculations when multiple bindings trigger an action.
My problem is this:
I like to build Views (Controls) that are dumb and expose properties
that can be manipulated by whatever is using the View. The View
listens to its own Properties and adjusts its state accordingly. Some
of these adjustments are related (like width + height) and can be
expensive when calculated immediately. So I would like to mark the
View as invalid and recalculate its state (if invalid) on the next
Pulse.
My current use case I'm looking at is a View that wraps (amongst
others) a TreeView. The View exposes an ObservableList and a
BooleanProperty that decides whether the first level of the Tree
should be displayed as Tabs or as Nodes (which has an impact on what
Nodes actually are added to the TreeView, and which are added as
Tabs). User code will thus often set a new list of nodes + change the
boolean to show tabs or nodes. The View currently naively has
InvalidationListeners on both of these properties which cause
TreeNodes to be created after the first change... then discarded and
recreated after the second change by the user code, ie:
view.nodesProperty().setAll(nodes); // Recreates all
Tabs/TreeNodes with the current value of expand top level, as we donot
know another change might be incoming...
view.expandTopLevelProperty().set(false); // Recreates all
Tabs/TreeNodes again if expand top level was changed...
This specific problem might be done in a better way, but the point
remains, how do I avoid expensive calculations when multiple
properties get changed one after the other by the user code? I'm
assuming that JavaFX controls already avoid these kinds of things, and
I'd like to know whether using a ScenePulseListener is the way to go,
or that it can/should be done in a different way -- examining the code
for TreeView (and its superclasses), I couldn't find uses of
ScenePulseListener...
--John
Re: Can JavaFX do CAD?
@John: On the JavaFx community site they have a section with references to real world usecases. http://www.oracle.com/technetwork/java/javafx/community/index.html On Sat, Jul 27, 2013 at 1:40 AM, John C. Turnbull ozem...@ozemail.com.auwrote: Like Daniel said, none of what we say is in any way a criticism of the JavaFX development team who, in my view and that of the entire community, are doing an awesome job. For mine, all the shortcomings of JavaFX (perceived or actual) can be blown away if I could just demonstrate what JavaFX is really capable of. We have Ensemble from Oracle and also Ensemble from JFXtras (whose demo incidentally doesn't run since Java 7 Update 21). With Oracle Ensemble we can see that JavaFX has quite a nice set of basic controls and that it at least supports very simple animations. With JFXtras Ensemble we can see that very nice controls are possible but unfortunately many of these are of a rather whimsical nature and not the kind of control you would use in everyday business apps. What else is there? Of course we have rock stars like Gerrit Grunwald who frequently post awesome controls and code snippets but we really need something that brings it altogether in a kick-arse showcase. Preferably a whole suite of killer apps that highlights everything JavaFX is capable of. Yes, that would require a lot of effort but IMHO it is absolutely worth it. Without it, people like me really struggle to sell JavaFX or even get a handle on its true potential. I can promise people that more advanced things are possible but given that they write the cheques, they need to see it for themselves. And how about a website of JavaFX reference sites? There must be big companies out there using it right? In the end it doesn't matter if I personally see enormous potential for JavaFX if I cannot convince others to see what I see. -jct From: Daniel Zwolenski [mailto:zon...@gmail.com] Sent: Saturday, 27 July 2013 09:12 To: John C. Turnbull Cc: Richard Bair; openjfx-dev@openjdk.java.net Subject: Re: Can JavaFX do CAD? +1 I've failed to convince multiple clients that they should use JFX because of a) lack of examples of what it can really do, and how to make it do that (e.g. in enterprise space we have http://static.springsource.org/docs/petclinic.html) b) lack of any big or notable players out there actually using it, or at least publicly saying they are using it c) the deployment hassles vs the ease of html app deployment and the true cross-platform-ness of html After actually getting one client to trust me on it and use it on a real, commercial app (startup), I hit problems with performance (broad interpretation of the term, not 'framerate'), crippling deployment and auto updating issues, missing basic features (e.g. maximise button, coming in 2014 I believe?), unpredictability of CSS styling, and a lack of best practices for things like how to do CAD-like diagrams (not so much render performance but zooming, panning, mouse input, layering, dragging, etc). Like John, I've been guilty of letting my frustration show in these forums. Like John, it's because I want so badly for JavaFX to be the platform I develop on, it has the potential to be awesome, but things (that seem obvious and small to me) completely stop it from being usable in a real world situation for me. It's not that we think the JFX team aren't slogging their guts out, clearly you are. It's just that in some key areas, there are small-ish blocks that stop the whole rocket from launching. To then see a whole lot of effort be poured into things like binary CSS/FXML compilation, Pi platform support (that's more important than iOS/Android, really?), web deployment patches, or even 3D (as cool as that is), just knocks me about. Obviously your priorities are coming from somewhere different to ours, but the way you prioritise is unfathomable to me and that definitely adds to the frustration. At this stage, I am not suggesting my clients use JFX (I actively discourage them from it, in their interest). Mobile is the area that has the potential to bring JFX back into usable for me as it can compete easier with the current technologies (which are all crap). Maybe if that ends up working (a long, long road to go on that and very much an 'if') then it will seep back into the desktop for me, but at a minimum the desktop deployment options will need to be improved before that's even a possibility. I've come to accept that I am not in the primary target audience for JavaFX, maybe a secondary target. I don't understand who the primary target is though, and knowing/accepting doesn't make it any less frustrating. I keep involved in the hope that I might get a usable platform somewhere along the way but it's more of a hope than a belief. So nothing really new above, but just adding my voice to John's. JavaFX is definitely not
