Re: Animation swipe stutter
I had a similar problem where my calendar popup would flicker when moving the mouse. This was also only reproducible on my system alone. Turns out the fact that I'm using VMWare to separate all the different projects I work on was the cause; somewhere half consciously I've clicked on a VMWare setting called accelerate 3D graphics and that didn't quite work as expected. One of the things you can do is let other people run your app and see when the stutter occurs; maybe there is a common denominator. I'm willing to test, and creating a UI only version should not be that hard. Tom On 2013-06-02 07:36, Daniel Zwolenski wrote: Here is another one I can't reproduce in a constrained example. http://www.screencast.com/t/ufJsZhiLhNJH This is a real world app that runs on a tablet (Windows). I tried to give this app a bit of an iPad style, with animations to transition between screens, etc (this was built a year or two ago). Many of the animations ' perform poorly' and are either slow or jumpy, etc, but it's hard to capture on video and hard to replicate in simple examples. In this video you can see a 'stutter' as the animation goes from left to right and back again. The stutter is right at the end just before the transition finishes. Sometimes it's pretty much perfect but 70% of the time it either overshoots and re-adjusts or just suddenly jumps to the end point before it's finished the smooth animation. At least that's the visual effect as far as I can tell. This (and many of the problems) could very well be an issue with the actual code on my end and not true JFX issues. I've tried to narrow down further but it is very time consuming to do this and it would help to know if there were any rough guesses at what might be causing this problem. Is it the fact that everything is so highly styled, or just the number of components, is it something like I shouldn't do any actual real work in an 'on finished' method, etc? If there are any possible leads then I can try and put together a small sample but at the moment I'm firing randomly. As far as the code goes, it's a fairly standard parallel transition containing two translate transitions. A very simple example of the sort of logic used can be seen here: https://code.google.com/p/zenjava-playtime/source/browse/trunk/javafx-performance/animate1/src/main/java/com/zenjava/jfx/performance/animate1/SwipeApp.java But this one animates consistently smooth.
Re: [API Review]: Add margin property to node and make it styleable from CSS
I know I'm reiterating, but just to keep the point alive; personally I would still prefer to have such information placed in an explicit layout constraint class. node.setMargin(x); layout.getChildren().add(node); vs layout.add(node, new Constraint().margin(x)); It also prevents the Node class from bloating. On 2013-06-11 14:47, Martin Sladecek wrote: Hi, JIRA issue: https://javafx-jira.kenai.com/browse/RT-27785 This API change is about adding marginProperty() to Node that would be then used by layout Panes instead of the current constraints (static methods getMargin/setMargin). The getMargin/setMargin on these Panes will just delegate to the property. Unfortunately, it's not possible to update Region.layoutInArea and Region.positionInArea methods to use child.getMargin() internally, as there's an overloaded method (in both cases) that already doesn't have Margin in it's parameters and uses Insets.EMPTY instead. Changing this to child.getMargin() might cause backward incompatibility issues. Thanks, -Martin
Re: [API Review]: Add margin property to node and make it styleable from CSS
On 2013-06-11 15:36, Martin Sladecek wrote: Means new *Constraint class and new add method for each layout *Pane class. Also one of the nice side-effects of having this as a property is that we can style it using -fx-margin CSS property. Yup, constraint classes with values that are relevant for / supported by the used layout. The one layout may support totally different layout parameters than another. By adding this to the node, basically all layout must be modified to support this. Tom
Re: javafx-font opensourced
That was a response to the fact that Oracle prefers to self-host. Tom On 2013-06-21 09:10, Daniel Zwolenski wrote: While I agree with Tom that setting up a Nexus (or Artifactory) repo is easy, I don't see any point for OSS stuff. That's what Sonatype is for, take advantage of it. Setting up your own Nexus (or Artifactory) is needed if you have proprietary stuff that you want to keep private or have licensing restrictions on, but the whole point of OpenJDK is to not be that - OSS Sonatype exists to make life easier for exactly these sorts of projects. You may want to setup an internal Nexus inside for your Oracle stuff but then you definitely wouldn't be giving us access to that. On Fri, Jun 21, 2013 at 5:01 PM, Tom Eugelink t...@tbee.org mailto:t...@tbee.org wrote: What I wanted to say with that (friends always accuse me of not being to the point) is that by running a Nexus repo yourself, - Oracle is self hosting - But also immediately compatible with Maven, Gradle, Ivy, etc - Allow other repo's to easily proxy, which improves availability I'm more than happy to setup a Nexus. Tom On 2013-06-21 08:56, Tom Eugelink wrote: Installing Nexus is extremely simple (kudo's to sonatype for that). I've got a copy running myself, proxying all kinds of other repo's, just to be not dependent on other hosting. Tom On 2013-06-21 08:51, Richard Bair wrote: Oracle has this thing about wanting to self host everything. However that doesn't stop the community from putting OpenJDK / OpenJFX stuff somewhere reasonable until Oracle finally gets all the infrastructure in place and the OpenJDK project can then take advantage of it. Richard On Jun 20, 2013, at 11:34 PM, Daniel Zwolenski zon...@gmail.com mailto:zon...@gmail.com wrote: Why not use Sonatype for your repo? For third party jars that aren't in central, you can upload these assuming the licence allows it: https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+The+Central+Repository For your own stuff that you aren't going to publish for real but still want to be available (e.g. latest releases of JFX), publish it as a SNAPSHOT. For real stuff, publish it proper into the Maven repo and make it available for use by the community. It certainly would make my life massively more enjoyable if a build of the JRE was available for download for each of the platforms. And things like win-launcher.exe and other secondary assets would also make it much easier to work on the packaging tools, etc. On Fri, Jun 21, 2013 at 2:34 PM, Richard Bair richard.b...@oracle.com mailto:richard.b...@oracle.com wrote: Yes, working on the web view building. The main issue is there are a handful of libs (libxml, libxslt, etc) that we have to figure out where to put. I believe these are unaltered by us, but built with different flags to strip out stuff we don't need. I've asked Peter whether we can post the build instructions to produce these libs, and then figured once anyone can build them, it wouldn't be to hard to find a place to put them. Ultimately we're trying to get a public artifactory repository setup for OpenJDK which would be the natural place for us to put all our dependencies like this, but in the meantime we just need a place to put some binaries. I know some of these binaries could be found elsewhere but not all of them (win64 builds I think are missing for example). On Jun 20, 2013, at 8:56 PM, Danno Ferrin danno.fer...@shemnon.com mailto:danno.fer...@shemnon.com wrote: On Thu, Jun 20, 2013 at 5:21 PM, Daniel Zwolenski zon...@gmail.com mailto:zon...@gmail.com wrote: This time sending to the list (gets me every time!): Great news! Danno - where does this put us with the JFX78 backport? Can we get a build of this for iOS now or what's needed to close this loop? The good news is that my JFX78 project now compiles via gradle without needing a stub jar. I took out the date picker and the builders for media and web view. So you can download it locally and build a jfxrt.jar and likely use the ios libs that build currently. I haven't poked around too much with the native bits. (see https://bitbucket.org/narya/jfx78) I also have been working on some maven distribution for this, not ready for consumption yet but an accessory build file creates the poms and handles the upload tasks ( https://bitbucket.org/narya/jfx78/src/3fe6c37ebdfbed33d1bdc9ad9d6a2037972de680
Re: JavaFX properties usage out of context?
Be aware that the binding of properties is lazy. That means that if a value changes, bound properties are not updated, they only get notified of the change. Serverside that may not be the preferred / expected behavior (binding libraries like JGoodies always update), so it may be necessary to short circuit the notification to always trigger the update. Tom On 2013-07-16 10:54, John C. Turnbull wrote: I am very impressed with the JavaFX properties and bindings functionality and feel that it is far more general in scope than just a UI toolkit like JavaFX. For me, I think the entire feature should be moved to a standard Java package so that it can readily be used in non-JavaFX applications. Is there any reason such as threading issues or some form of functional dependency that would prevent JavaFX properties and bindings being used in a non-JavaFX application such as a server-side component? My testing seems to suggest that they work just fine outside of a JavaFX context but I would like to be sure. Any thoughts on extracting this functionality from JavaFX and moving it to a more general location in the Java package hierarchy? Thanks, -jct
Re: JavaFX Sightings (forked from Re: Can JavaFX do CAD?)
I was already working on getting some screenshots of a security application written in JFX (mentioned its development a few months ago). It's a purchasable product, so screenshots should be possible. I'm only curious if it will make a nice showcase, since it mainly is used to show camera images. On 2013-07-28 02:38, Jonathan Giles wrote: This is something that Jasper actually brought up just this morning with Richard and I (wrt fxexperience hosting it). I suspect we may get something underway in the coming weeks. Of course, it depends on the community getting in touch with us and letting us talk about them - so much of the JavaFX world is behind corporate firewalls, where talking about your work is generally frowned upon. In any case, for those of you that can talk about your work, please email one of us off-list. -- Jonathan Sent from a touch device. Please excuse my brevity. John C. Turnbull ozem...@ozemail.com.au wrote: +1 Such a site could be very useful. -Original Message- From: openjfx-dev-boun...@openjdk.java.net [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Daniel Zwolenski Sent: Sunday, 28 July 2013 09:56 To: Pedro Duque Vieira Cc: OpenJFX Mailing List Subject: JavaFX Sightings (forked from Re: Can JavaFX do CAD?) The idea of a JFX Sightings page (in the tradition of the Swing Sightings page) has been raised before and I think is a good one. It deserves it's own page though, that technet section isn't up to it in my opinion. Personally I think this would be great under the fxexperience site as it partners nicely with the links of the week? On 28/07/2013, at 4:17 AM, Pedro Duque Vieira pedro.duquevie...@gmail.com wrote: I have an Swing/JavaFX app, the site is: http://modellus.co How can I get it to be on that real world usecases section? Or does it not have the necessary requirements to be in it? Thanks, best regards, @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.au wrote: 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,
Re: JavaFX and iOS - it will remain a dream
Not answering for my fellow Tom but for myself; FXML is a format that is mainly of interest to the developer, not the runtime environment. So, like precompiled JSP, there is something to say for compiling something that is actually programming code, no matter in which context it is used. On 2013-07-31 09:15, John C. Turnbull wrote: Tom, why do you think FXML on mobiles is a bad idea? Performance? -Original Message- From: openjfx-dev-boun...@openjdk.java.net [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Tom Schindl Sent: Wednesday, 31 July 2013 16:29 To: Niklas Therning Cc: openjfx-dev@openjdk.java.net Mailing Subject: Re: JavaFX and iOS - it will remain a dream I don't think it is a good idea to use fxml on embedded and mobile, we are working on a fxml = java converter so you can add it to your build process. Tom Von meinem iPhone gesendet Am 31.07.2013 um 08:11 schrieb Niklas Therning nik...@therning.org: after many days trying to really build iOS apps with JavaFX and RoboVM or Avian I’m very frustrated because of the following things: Based on RoboVM, JavaFX on iOS runs unacceptable slow - I don’t know the reason - maybe it’s the rendering model of JavaFX - maybe it’s the currently unoptimized RoboVM One big problem of RoboVM is it’s dependence of the Android library, it does not support the OpenJDK. That’s a big reason for many many problems when using JavaFX. So currently it’s not possible to use fxml files (FXMLoader) because of the missing Stax xml parser and classes like XMLInputFactory in the android library… There's now a compatibility library for the jfx78 backport which includes the missing sun.* classes from OpenJDK [1]. So that will not be a problem when running on RoboVM/Android. Daniel Zwolenski is working on getting this into Maven which will make it nice and easy to develop with RoboVM+OpenJFX. FXMLLoader relies an StAX and the Java Scripting API. Those can both be made to work on RoboVM/Android. The POM of the compat project [1] contains optional dependencies on the StAX API and JSR 223 API. For StAX you'll also need a StAX provider [2][3]. For scripting you'll need a JSR 223 implementation of the scripting language you're using, like Rhino for JavaScript [4][5]. Please note that I haven't tested FXML but it should work (in theory at least ;-) ). Please give it a go. It will be a great blog story if you can make it work on iOS. As for the performance issues with RoboVM+OpenJFX: those WILL be addressed! You can either wait for it to happen or you can help out. One way to do that would be sample code that exercises the code paths that need to be optimized (e.g. the button rendering you posted about earlier). Preferably the sample should run repeatedly without user interaction. You should then be able to run Apple's Instruments application to profile this sample. This will help us determine what needs to be optimized. /Niklas [1] https://github.com/robovm/robovm-jfx78-compat [2] https://github.com/FasterXML/aalto-xml [3] http://woodstox.codehaus.org/ [4] https://developer.mozilla.org/en-US/docs/Rhino [5] https://java.net/projects/scripting/sources/svn/show/trunk/engines/javascript?rev=236
Re: Proposal to move default style-class from Control to SkinBase
Since day 1 of writing controls for JFX I've used the approach that a skin sets
its own style class, and that class is used in the CSS. If a control should not
be aware of how it is rendered, what sense does it make to have visual styling
set on it?
So in a skin I do: this.getStyleClass().add( AgendaWeekSkin );
And in the CSS: .AgendaWeekSkin { ... }
In this way I already have separate styling between control and the active
skin. So I can only +1 any change that more clearly moves any visual aspect
closer to the skin.
That said, of course there are certain things of a control that are very
generic, like a textfield having font styling. These styling could/should still
be stylable on the control and not the skin. OTOH, usually such things are set
on a more abstract level.
Tom
On 2013-08-07 17:08, David Grieve wrote:
Currently, a control has a default style-class. For example, you can use
.button in a style-sheet to style a Button. I propose to move the default
style-class from the control to the skin (RT-32186). The impetus for this
change is two-fold.
Firstly, it can be argued that setting the style-class of a control should be
left to the developer, that imposing a default style-class is implementation
detail leaking into the public API. Moving the default style-class from the
control to the skin addresses this concern.
The second motive has to do with CSS processing itself. When a skin is set on a
control, the control adopts the styles of the skin and css is reapplied to the
control in order to pick up the new styles. Thus, it takes two CSS passes to
fully style a control. By moving the default style-class to the skin, the
control no longer has to adopt the skin's styles. Styles still have to be
applied to the skin, but this can be done from the skinProperty's invalidated
method. These subtle changes - not adopting the styles and applying css to the
skin from skinProperty's invalidated method - will simplify the code in Control.
The reason for moving the default from Control to SkinBase and not Skin is that
there is no API in Skin for getting style-class (or any other css selector
attributes). Skin could implement the Styleable interface, but that would not
be backward compatible.
Another issue related to CSS processing has to do with looking up cached,
matching styles for a node. When the skin is set on the node and adopts the
styles of the skin, css is reapplied. This means that the css implementation
will look for matching styles for the control. There is a map that has a node's
simple class name, style-class, and id (the 'css selector' aspects of a node)
as a key and the matching styles as a value. Since none of the 'css selector'
aspects of the node have changed, the previously cached value is returned from
the map. Then when the styles are applied to the node, css says 'oh, I've
already calculated values for this kind of node' and doesn't bother looking up
the properties that were added by the skin. This causes problems such as
https://javafx-jira.kenai.com/browse/RT-31691.
The cache lookup issue can be resolved in other ways, such as adding the list
of properties to the key, or adding a flag to cause css to calculate a value if
there is no previously calculated value found. But I believe that moving the
default style-class will lead to cleaner code.
If a control no longer adopts the skin's styles, then the control and the skin
could be styled as separate entities. This would mean that instead of
.tool-bar { -fx-orientation: vertical; -fx-spacing: 3; }
one would have to write
ToolBar { -fx-orientation: vertical; } .tool-bar: { -fx-spacing: 3; }
since orientation is a property of ToolBar and spacing a property of
ToolBarSkin. This is an issue for maintaining backward compatibility with
existing stylesheets. This isn't a issue for caspian or modena but is for
author style-sheets and inline styles. I have some ideas here, but all of them
rather clunky and kludgey. My question on this point is whether or not this is
a real concern.
properties via CSS
Projects are starting to use my calendar picker control and requests are coming in for more fine tuned styling. One of the topics is the location and direction of the arrows of the two embedded listspinner controls. Now, the location and position of these arrows are already configurable through the control's Java properties, but since the spinners are embedded, this is not available on the calendar picker API. I would really like to be able to configure these properties in CSS. If I remember correctly, CSS set properties were made possible. Is there some example or explanation on how to do this? Regards, Tom
Re: properties via CSS
Seems my perfect english might be the cause of me not finding any info; stylEAble https://wiki.openjdk.java.net/display/OpenJFX/CSS+API+to+support+custom+UI+Controls On 2013-08-13 15:42, Tom Eugelink wrote: Projects are starting to use my calendar picker control and requests are coming in for more fine tuned styling. One of the topics is the location and direction of the arrows of the two embedded listspinner controls. Now, the location and position of these arrows are already configurable through the control's Java properties, but since the spinners are embedded, this is not available on the calendar picker API. I would really like to be able to configure these properties in CSS. If I remember correctly, CSS set properties were made possible. Is there some example or explanation on how to do this? Regards, Tom
custom Styleable properties CSS prefix
I've created my first control with custom CSS Styleable properties. Ignoring the fact that com.sun classes are involved, it worked pretty easily. Jim suggested that I also post the question about the CSS prefix I asked on the JFXtras mail list here is well. So: I would like to suggest is to use the -fxx prefix for JFXtras CSS properties, so: -fxx-arrow-direction:VERTICAL; -fxx-arrow-position:LEADING; If there is a good reason not to use -fxx I'd love to hear it. Tom
Re: custom Styleable properties CSS prefix
No, this is still 2.2, since that is the production version of JFX. The user is creating an actual production application with JFX. My next step is to port this to 8.0. Are the changes major? On 2013-08-15 16:16, David Grieve wrote: I'm assuming this is 8.0? If so, what com.sun classes did you need to pull in and why? I'd like to know from the perspective of the owner of the styleable API. If you have to pull in com.sun, then I might have missed something somewhere since all you should need is in the javafx.css package. On Aug 15, 2013, at 9:16 AM, Tom Eugelink t...@tbee.org wrote: I've created my first control with custom CSS Styleable properties. Ignoring the fact that com.sun classes are involved, it worked pretty easily. Jim suggested that I also post the question about the CSS prefix I asked on the JFXtras mail list here is well. So: I would like to suggest is to use the -fxx prefix for JFXtras CSS properties, so: -fxx-arrow-direction:VERTICAL; -fxx-arrow-position:LEADING; If there is a good reason not to use -fxx I'd love to hear it. Tom
Re: custom Styleable properties CSS prefix
Ah, that was the example I tried to use for the 2.2 branch, but didn't work. Thanks! On 2013-08-16 14:23, David Grieve wrote: The changes are significant in that many of the class names were changed and there were some other API changes. I was able to make a good number of changes using perl substitution. But, other than how pseudo-class state is handled, the model didn't change. You might also want to look here - https://wiki.openjdk.java.net/display/OpenJFX/CSS+API+to+support+custom+UI+Controls On Aug 15, 2013, at 10:20 AM, Tom Eugelink t...@tbee.org wrote: No, this is still 2.2, since that is the production version of JFX. The user is creating an actual production application with JFX. My next step is to port this to 8.0. Are the changes major? On 2013-08-15 16:16, David Grieve wrote: I'm assuming this is 8.0? If so, what com.sun classes did you need to pull in and why? I'd like to know from the perspective of the owner of the styleable API. If you have to pull in com.sun, then I might have missed something somewhere since all you should need is in the javafx.css package. On Aug 15, 2013, at 9:16 AM, Tom Eugelink t...@tbee.org wrote: I've created my first control with custom CSS Styleable properties. Ignoring the fact that com.sun classes are involved, it worked pretty easily. Jim suggested that I also post the question about the CSS prefix I asked on the JFXtras mail list here is well. So: I would like to suggest is to use the -fxx prefix for JFXtras CSS properties, so: -fxx-arrow-direction:VERTICAL; -fxx-arrow-position:LEADING; If there is a good reason not to use -fxx I'd love to hear it. Tom
Re: The rise and fall of Builders
This week I ran into the problem that I needed to provide a date format (attribute in FXML) to one of my controls. So I needed a way to convert a string to DateFormat, or even a comma separated list to a list of DateFormats. This I solved with a builder for that control. How would one solved that without builders? (What is the alternative to builders?) Tom On 2013-08-29 22:42, Richard Bair wrote: Deprecated in 8 and removed from the JavaDoc, gone in 9 (will be available as a separately downloadable Jar so you can keep using them, but they won't be updated). We're removing them from samples. Best to cycle off the builders. Richard On Aug 29, 2013, at 12:42 PM, Felix Bembrick felix.bembr...@gmail.com wrote: Thanks Jonathan, So what is Oracle's current position on this? Are Builders in or out? If out, when will they be removed and how? On 30 August 2013 05:31, Jonathan Giles jonathan.gi...@oracle.com wrote: You can catch up on the back story here: http://mail.openjdk.java.net/pipermail/openjfx-dev/2013-March/006725.html -- Jonathan On 30/08/2013 7:06 a.m., Felix Bembrick wrote: I was not privy to the original discussion but I am lead to believe that Builders are no longer considered fashionable and that we are advised not to use them. While I realise that every type of Node basically needed its own Builder, could someone please outline why this situation has arisen? Is it something to do with fluent APIs themselves or some other reason? Thanks, Felix
Re: The rise and fall of Builders
I know, the question was based on the best to cycle off builders remark, then what is advised to use as an alternative? Tom On 2013-08-30 06:56, Richard Bair wrote: You can still use your own Builders and plug them into FXML. Its just that the built in set won't be there. But the Builder base class and all the FXML support is still there. All mentioned in that long thread :-D Richard On Aug 29, 2013, at 9:50 PM, Tom Eugelink t...@tbee.org wrote: This week I ran into the problem that I needed to provide a date format (attribute in FXML) to one of my controls. So I needed a way to convert a string to DateFormat, or even a comma separated list to a list of DateFormats. This I solved with a builder for that control. How would one solved that without builders? (What is the alternative to builders?) Tom On 2013-08-29 22:42, Richard Bair wrote: Deprecated in 8 and removed from the JavaDoc, gone in 9 (will be available as a separately downloadable Jar so you can keep using them, but they won't be updated). We're removing them from samples. Best to cycle off the builders. Richard On Aug 29, 2013, at 12:42 PM, Felix Bembrick felix.bembr...@gmail.com wrote: Thanks Jonathan, So what is Oracle's current position on this? Are Builders in or out? If out, when will they be removed and how? On 30 August 2013 05:31, Jonathan Giles jonathan.gi...@oracle.com wrote: You can catch up on the back story here: http://mail.openjdk.java.net/pipermail/openjfx-dev/2013-March/006725.html -- Jonathan On 30/08/2013 7:06 a.m., Felix Bembrick wrote: I was not privy to the original discussion but I am lead to believe that Builders are no longer considered fashionable and that we are advised not to use them. While I realise that every type of Node basically needed its own Builder, could someone please outline why this situation has arisen? Is it something to do with fluent APIs themselves or some other reason? Thanks, Felix
ServiceLoader
On 2013-09-03 17:49, Richard Bair wrote: In this case, since JavaFX is Free Software! you can actually suggest the fix, prototype and propose the patch yourself, limiting the round trip time substantially. That said, in JFXtras I've created an extended FactoryBuilder that dynamically loads builder classes using Java's standard ServiceLoader approach. Would this be of interest for inclusion directly into JavaFX? https://github.com/JFXtras/jfxtras-labs/blob/2.2/src/main/java/jfxtras/labs/fxml/JFXtrasBuilderFactory.java It does require a slightly extended Builder interface though. https://github.com/JFXtras/jfxtras-labs/blob/2.2/src/main/java/jfxtras/fxml/BuilderService.java A little blabla about this on this blog entry: http://tbeernot.wordpress.com/2013/08/25/fxml-builders-detection/ Tom
Re: ServiceLoader
No, but there is a less-than-optimal-but-fast approach, and that is to write a custom BuilderFactory with if statements for all 3rd party controls. On 2013-09-03 20:46, Richard Bair wrote: It is a real problem though (how to support 3rd party controls well). Is there a JIRA for this case? Richard On Sep 3, 2013, at 11:44 AM, Tom Eugelink t...@tbee.org wrote: True, so we'll leave it JFXtras then. On 2013-09-03 20:28, Richard Bair wrote: The only knee-jerk reaction to the service loader is that it can be bad at startup, because for the service loader to work, it has to scan all jar files, which means downloading all jar files. Maybe with Jigsaw we'll have a better mechanism for this such that we can just read the first few bytes of a module and determine whether it supports a certain service or not. Richard On Sep 3, 2013, at 9:43 AM, Tom Eugelink t...@tbee.org wrote: On 2013-09-03 17:49, Richard Bair wrote: In this case, since JavaFX is Free Software! you can actually suggest the fix, prototype and propose the patch yourself, limiting the round trip time substantially. That said, in JFXtras I've created an extended FactoryBuilder that dynamically loads builder classes using Java's standard ServiceLoader approach. Would this be of interest for inclusion directly into JavaFX? https://github.com/JFXtras/jfxtras-labs/blob/2.2/src/main/java/jfxtras/labs/fxml/JFXtrasBuilderFactory.java It does require a slightly extended Builder interface though. https://github.com/JFXtras/jfxtras-labs/blob/2.2/src/main/java/jfxtras/fxml/BuilderService.java A little blabla about this on this blog entry: http://tbeernot.wordpress.com/2013/08/25/fxml-builders-detection/ Tom
Re: ServiceLoader
Richard said (2013-08-30 08:08) that builders still will be supported / needed; I need one to convert the string annotation in FXML to an appropriate data type (list of DateFormats). On my question what the alternative would be, if we're not to use builders because they were deprecated, the answer was that the build-in builders are deprecated, but the builders as a concept in FXML will still be used. On 2013-09-03 23:48, Tom Schindl wrote: Well once we have a replacement for builders this is not needed anymore so I don't think there's a JIRA needed. When we discussed replacements for builders in context of FXML the consensus was to have annotations on the constructor to map the arguments appropriately. Eva suggested @ConstructorProperties, I was more in favor of explicit @FXMLValue annotation on each argument. Tom On 03.09.13 22:53, Tom Eugelink wrote: No, but there is a less-than-optimal-but-fast approach, and that is to write a custom BuilderFactory with if statements for all 3rd party controls. On 2013-09-03 20:46, Richard Bair wrote: It is a real problem though (how to support 3rd party controls well). Is there a JIRA for this case? Richard On Sep 3, 2013, at 11:44 AM, Tom Eugelink t...@tbee.org wrote: True, so we'll leave it JFXtras then. On 2013-09-03 20:28, Richard Bair wrote: The only knee-jerk reaction to the service loader is that it can be bad at startup, because for the service loader to work, it has to scan all jar files, which means downloading all jar files. Maybe with Jigsaw we'll have a better mechanism for this such that we can just read the first few bytes of a module and determine whether it supports a certain service or not. Richard On Sep 3, 2013, at 9:43 AM, Tom Eugelink t...@tbee.org wrote: On 2013-09-03 17:49, Richard Bair wrote: In this case, since JavaFX is Free Software! you can actually suggest the fix, prototype and propose the patch yourself, limiting the round trip time substantially. That said, in JFXtras I've created an extended FactoryBuilder that dynamically loads builder classes using Java's standard ServiceLoader approach. Would this be of interest for inclusion directly into JavaFX? https://github.com/JFXtras/jfxtras-labs/blob/2.2/src/main/java/jfxtras/labs/fxml/JFXtrasBuilderFactory.java It does require a slightly extended Builder interface though. https://github.com/JFXtras/jfxtras-labs/blob/2.2/src/main/java/jfxtras/fxml/BuilderService.java A little blabla about this on this blog entry: http://tbeernot.wordpress.com/2013/08/25/fxml-builders-detection/ Tom
Re: Changes in caspian.bss
On JavaFX 8.0 we're getting all kind of CSS warnings when running the JFXtras 8.0 project. I personally am waiting for JFX8 to stabilize before trying to figure out what is going on exactly. I do not notice any (visual) problems though. On 2013-09-14 12:32, Peter Penzov wrote: Hi, I tried to implement my own version of example from jfxtras - BigDecimalField. I copied all java files and css code successfully but when I run the code I get these errors: IX 14, 2013 1:29:54 PM javafx.scene.CssStyleHelper calculateValue WARNING: Could not resolve '-fx-shadow-highlight-color' while resolving lookups for '-fx-background-color' from rule '*.big-decimal-field' in stylesheet file:/D:/Users/pterzie/Desktop/DX-57DC/target/classes/styles/BigDecimalField.css IX 14, 2013 1:29:54 PM javafx.scene.CssStyleHelper calculateValue WARNING: Could not resolve '-fx-shadow-highlight-color' while resolving lookups for '-fx-background-color' from rule '*.text-field' in stylesheet jar:file:/C:/Program%20Files/Java/jdk1.8.0/jre/lib/ext/jfxrt.jar!/com/sun/javafx/scene/control/skin/caspian/caspian.bss IX 14, 2013 1:29:54 PM javafx.scene.CssStyleHelper calculateValue WARNING: Could not resolve '-fx-text-inner-color' while resolving lookups for '-fx-highlight-text-fill' from rule '*.text-input' in stylesheet jar:file:/C:/Program%20Files/Java/jdk1.8.0/jre/lib/ext/jfxrt.jar!/com/sun/javafx/scene/control/skin/caspian/caspian.bss IX 14, 2013 1:29:54 PM javafx.scene.CssStyleHelper calculateValue WARNING: Could not resolve '-fx-text-inner-color' while resolving lookups for '-fx-text-fill' from rule '*.text-field' in stylesheet jar:file:/C:/Program%20Files/Java/jdk1.8.0/jre/lib/ext/jfxrt.jar!/com/sun/javafx/scene/control/skin/caspian/caspian.bss IX 14, 2013 1:29:54 PM javafx.scene.CssStyleHelper calculateValue WARNING: Could not resolve '-fx-control-inner-background' while resolving lookups for '-fx-highlight-fill' from rule '*.text-input' in stylesheet jar:file:/C:/Program%20Files/Java/jdk1.8.0/jre/lib/ext/jfxrt.jar!/com/sun/javafx/scene/control/skin/caspian/caspian.bss IX 14, 2013 1:29:54 PM javafx.scene.CssStyleHelper calculateValue WARNING: Could not resolve '-fx-control-inner-background' while resolving lookups for '-fx-prompt-text-fill' from rule '*.text-field' in stylesheet jar:file:/C:/Program%20Files/Java/jdk1.8.0/jre/lib/ext/jfxrt.jar!/com/sun/javafx/scene/control/skin/caspian/caspian.bss IX 14, 2013 1:29:54 PM javafx.scene.CssStyleHelper calculateValue WARNING: Could not resolve '-fx-text-box-border' while resolving lookups for '-fx-background-color' from rule '*.big-decimal-field *.arrow-button' in stylesheet file:/D:/Users/pterzie/Desktop/DX-57DC/target/classes/styles/BigDecimalField.css IX 14, 2013 1:29:54 PM javafx.scene.CssStyleHelper calculateValue WARNING: Could not resolve '-fx-control-inner-background' while resolving lookups for '-fx-background-color' from rule '*.tab-pane*.tab-content-area' in stylesheet jar:file:/C:/Program%20Files/Java/jdk1.8.0/jre/lib/ext/jfxrt.jar!/com/sun/javafx/scene/control/skin/caspian/caspian.bss IX 14, 2013 1:29:54 PM javafx.scene.CssStyleHelper calculateValue WARNING: Could not resolve '-fx-text-background-color' while resolving lookups for '-fx-text-fill' from rule '*.label' in stylesheet jar:file:/C:/Program%20Files/Java/jdk1.8.0/jre/lib/ext/jfxrt.jar!/com/sun/javafx/scene/control/skin/caspian/caspian.bss IX 14, 2013 1:29:54 PM javafx.scene.CssStyleHelper calculateValue WARNING: Could not resolve '-fx-text-background-color' while resolving lookups for '-fx-text-fill' from rule '*.label' in stylesheet jar:file:/C:/Program%20Files/Java/jdk1.8.0/jre/lib/ext/jfxrt.jar!/com/sun/javafx/scene/control/skin/caspian/caspian.bss IX 14, 2013 1:29:54 PM javafx.scene.CssStyleHelper calculateValue WARNING: Could not resolve '-fx-shadow-highlight-color' while resolving lookups for '-fx-background-color' from rule '*.combo-box-base' in stylesheet jar:file:/C:/Program%20Files/Java/jdk1.8.0/jre/lib/ext/jfxrt.jar!/com/sun/javafx/scene/control/skin/caspian/caspian.bss IX 14, 2013 1:29:54 PM javafx.scene.CssStyleHelper calculateValue WARNING: Could not resolve '-fx-outer-border' while resolving lookups for '-fx-background-color' from rule '*.combo-box-base*.arrow-button' in stylesheet jar:file:/C:/Program%20Files/Java/jdk1.8.0/jre/lib/ext/jfxrt.jar!/com/sun/javafx/scene/control/skin/caspian/caspian.bss IX 14, 2013 1:29:54 PM javafx.scene.CssStyleHelper calculateValue WARNING: Could not resolve '-fx-mark-highlight-color' while resolving lookups for '-fx-background-color' from rule '*.combo-box-base*.arrow-button*.arrow' in stylesheet jar:file:/C:/Program%20Files/Java/jdk1.8.0/jre/lib/ext/jfxrt.jar!/com/sun/javafx/scene/control/skin/caspian/caspian.bss IX 14, 2013 1:29:54 PM javafx.scene.CssStyleHelper calculateValue WARNING: Could not resolve '-fx-box-border' while resolving lookups for '-fx-background-color' from rule '*.list-view' in stylesheet
Re: losing the validation listener
Hi Richard,
I tried to reproduce the bug and so far it has not occurred anymore. So it
seems it has magically resolved itself.
Regards,
Tom
On 2013-09-26 21:56, Richard Bair wrote:
Hi Tom,
Did this issue ever get resolved? It sounds very strange indeed, and we should
have a JIRA filed for it if there is not one already.
Thanks
Richard
On Apr 8, 2013, at 3:48 AM, Tom Eugelink t...@tbee.org wrote:
Hi Werner,
It indeed is very similar (my code is public on Github, so no use adding it
here), especially the selectedToggleProperty listener. I chose to reuse as much
of the existing approach, being the getUserData().
What would be of interest to me is:
- the exact declaration of the enumValueProperty
- how you listen to changes on enumValueProperty
- and of course: what happens if you hide/disable the toggles with only one
listener attached
Tom
On 2013-04-08 11:51, Werner Lehmann wrote:
Hi Tom,
I did something similar: toggle group for toggles which correspond to enum
members. This one assume that the toggles correspond to the enum members in
their declared order. It also uses an invalidation listener and
disabling/enabling a toggle keeps the listener functional as I just tested with
a test application.
public class MintEnumToggleGroupE extends EnumE extends ToggleGroup
{
public MintEnumToggleGroup(ClassE enumClass)
{
this.enumClass = enumClass;
selectedToggleProperty().addListener(new InvalidationListener()
{
@Override
public void invalidated(Observable observable)
{
Toggle toggle = getSelectedToggle();
E value = null;
if (toggle != null)
{
int ordinal =
MintEnumToggleGroup.this.getToggles().indexOf(toggle);
value = MintEnumToggleGroup.this.enumClass
.getEnumConstants()[ordinal];
}
if (enumValue.get() != value)
enumValue.set(value);
}
});
...
}
/**
* Bidirectionally bindable property representing the enum member
* of the selected toggle.
*/
public ObjectPropertyE enumValueProperty() { return enumValue; }
public E getEnumValue() { return enumValueProperty().get(); }
public void setEnumValue(E value) { enumValueProperty().set(value); }
}
Looks similar to what you are doing. Let me know if you want to look at the
full source (toggle group and testcase).
Rgds
Werner
On 07.04.2013 21:28, Tom Eugelink wrote:
Again some strange behavior I could use some pointers with. In JFXtras I've
created an extended ToggleGroup which has a value property.
https://github.com/JFXtras/jfxtras-labs/blob/2.2/src/main/java/jfxtras/labs/scene/control/ToggleGroupValue.java
Basically what it does is listen to the selectedToggleProperty of ToggleGroup,
and upon invalidation gets the user data associated with the now active toggle
and puts that in the valueProperty. Simple, and now you can register and listen
to the value of the toggle group. Which is exactly what I do in my basketball
application by registering to the invalidated event.
toggleGroup.valueProperty().addListener(new InvalidationListener() {...});
Now I have one very strange behavior; if I disable or hide the toggles, and
then re-enable/show them again, the invalidation listener is no longer called.
Some how it seems to have been removed from the listeners list. But the API
documentation explicitly says it is a strong reference.
http://docs.oracle.com/javafx/2/api/javafx/beans/Observable.html#addListener(javafx.beans.InvalidationListener)
If I add a second dummy listener, then the first listener is not removed when
disabled/hidden.
It very much reeks like a garbage collection thing. Any suggestions?
Tom
Re: Moving on to a round house kick (forked from Re: JavaOne roundup?)
Hello Matthias, This is just how Oracle rolls, we have to get used to it. And actually it is not that bad of an attitude; never make a promise you can't keep. When deliver, deliver well. I'm in a project which communicates way to much to end users and they keep being disappointed. I kinda think not informing them would be smart. Tom
Re: Moving on to a round house kick (forked from Re: JavaOne roundup?)
On 2013-09-30 18:27, John Hendrikx wrote: To be honest, it is likely JavaFX already missed its window to become relevant on Android and iOS. Maybe, but I've done my fair share of UI toolkits and JFX really has some great features compared to the others (not counting layout - pun intended ;-). So you could be right, but you could also still be wrong. Tom
Re: JAVAFX on ANDROID
On 2013-10-14 01:06, Rafal wrote: If you honestly encourage community to make a such big effort as developing, adjusting and maintaining JVMs on the two leading mobile platforms, you don't have any plans that Oracle VM on android will be released in the next 2 years. :/ Otherwise, if Oracle announce own VM, then all this community's effort be for nothing and pointless. Open source done in the spare time by people with a full time job usually never grows much bigger than a nice but not too complex library; layout engines, testing frameworks, a web framework, that kind of stuff. Because as a project grows in size and complexity, so do the (number of) issues and the time required to provide support. That usually is the point where either a company is started (projects like Maven and Gradle) or the project gets corporate funding usually by that a corporation allows some developers to spent worktime on it (Apache, Eclipse, and Java JavaFX is getting there). A full fledged port of a JVM to a mobile platform cannot be carried in spare time, it can be showcased (which it has), but to make it production worthy one or more corporations needs to put their weight behind it. My 2 cents, Tom
Re: bugfix mode
I am seeing these warnings when starting JFXtras CalendarPicker using JDK 1.7.0_45. There is not much information to go on. Is there any way to git more information? WARNING: com.sun.javafx.css.StyleHelper calculateValue Could not resolve '-fx-text-base-color' while resolving lookups for '-fx-text-fill' from rule '*.toggle-button' in stylesheet jar:file:/C:/Program%20Files%20(x86)/Java/jdk1.7.0_21/jre/lib/jfxrt.jar!/com/sun/javafx/scene/control/skin/caspian/caspian.bss WARNING: com.sun.javafx.css.StyleHelper calculateValue Could not resolve '-fx-shadow-highlight-color' while resolving lookups for '-fx-background-color' from rule '*.toggle-button' in stylesheet jar:file:/C:/Program%20Files%20(x86)/Java/jdk1.7.0_21/jre/lib/jfxrt.jar!/com/sun/javafx/scene/control/skin/caspian/caspian.bss WARNING: com.sun.javafx.css.StyleHelper calculateValue Could not resolve '-fx-shadow-highlight-color' while resolving lookups for '-fx-background-color' from rule '*.text-field' in stylesheet jar:file:/C:/Program%20Files%20(x86)/Java/jdk1.7.0_21/jre/lib/jfxrt.jar!/com/sun/javafx/scene/control/skin/caspian/caspian.bss WARNING: com.sun.javafx.css.StyleHelper calculateValue Could not resolve '-fx-text-inner-color' while resolving lookups for '-fx-text-fill' from rule '*.text-field' in stylesheet jar:file:/C:/Program%20Files%20(x86)/Java/jdk1.7.0_21/jre/lib/jfxrt.jar!/com/sun/javafx/scene/control/skin/caspian/caspian.bss WARNING: com.sun.javafx.css.StyleHelper calculateValue Could not resolve '-fx-control-inner-background' while resolving lookups for '-fx-prompt-text-fill' from rule '*.text-field' in stylesheet jar:file:/C:/Program%20Files%20(x86)/Java/jdk1.7.0_21/jre/lib/jfxrt.jar!/com/sun/javafx/scene/control/skin/caspian/caspian.bss WARNING: com.sun.javafx.css.StyleHelper calculateValue Could not resolve '-fx-accent' while resolving lookups for '-fx-highlight-fill' from rule '*.text-input' in stylesheet jar:file:/C:/Program%20Files%20(x86)/Java/jdk1.7.0_21/jre/lib/jfxrt.jar!/com/sun/javafx/scene/control/skin/caspian/caspian.bss
Re: JavaFX on iOS and Android: The real problem and challenge
Oracle has a strict do-not-communicate-what-is-not-certain policy and I actually commend them for it. Better to not communicate than make promises you can't keep (I'm seeing the effect on that in many of the projects I'm asked to assist). I think the urgency of mobile platforms is clear to Oracle, given the recent focus on JavaME and the internet-of-things. Patience is a virtue. My 2 cents, Tom On 2013-11-9 18:21, Pedro Duque Vieira wrote: Sure we should listen to Richard. He is doing a great job as well as his team. I don't think however that enough is being communicated.. I don't think those legal boundaries are being layed out explicitly. What are those legal boundaries? Will RoboVM not be subject to those legal issues? What's the difference between us creating a project and trying to integrate it into openjdk and Oracle doing it? Once we create a project and try to integrate it into OpenJDK what will happen? Can javafx team members contribute to it (apparently yes)? Will Oracle be helping out and telling us what's the best route to follow? Once we get RoboVM correctly running javafx apps on iOS and Android what will still be left out to do? Are things like comboboxes poping up scroll wheels already in place? What about app notifications? What about saving app configurations to the local platform db? etc, etc? I think there is a lot of stuff to discuss. Also I think Oracle should be telling us what have they accomplished so far, what exactly they are working on (they are indeed actively working on this) for porting javafx to iOS and Android... probably something that an email can't cover perfectly.. Regards, On Sat, Nov 9, 2013 at 2:39 PM, Rick Walker thoughtslin...@gmail.comwrote: There is more to this issue than simply JavaFX, iOS and Android. There is a bigger picture here that involves the complex relationships between Oracle, Apple and Google. I think it is fair to say that we all have enormous respect for Richard Bair and his team. It seems to me we should listen to Richard. If I understand his postings correctly, he is saying that we, the community, should create a new OpenJDK project which, if it used the OpenJDK class libraries would let his team put support directly into the OpenJFX build system for building FX and running FX apps ... directly on RoboVM. It seems to me that the message here is that Oracle is totally willing and able to support RoboVM as an OpenJDK project. Niklas - are you up for it? The optics here are important. The project must be created by the community (NOT BY ORACLE). from Richard's post of October 22: Personally I'm interested in RoboVM on Android, so that there is a single VM across both iOS and Android. Also if RoboVM supported the OpenJDK class libraries, it would make this so much simpler for us and provide a consistent story. For example, the OpenJFX project is an OpenJDK project and we really can't be officially promoting a VM that doesn't implement the Java standard. It puts us in a very awkward position. If RoboVM used the OpenJDK class libraries instead of the Android class libraries, not only could I push it at conferences like JavaOne, but I could also put support directly into the OpenJFX build system for building FX and running FX apps (like Hello*, Modena, Ensemble, etc) directly on RoboVM without developers having to setup anything special. This would be huge for making it easy for people to contribute iOS fixes to OpenJFX. But I can't do that if RoboVM doesn't actually implement Java. and, from November 8: Totally, I think the normal process for this is to create a new OpenJDK project, is it not? Can you take a look at the OpenJDK bylaws and report back on the process? I think it would be awesome to do a port. Note that there are a few OpenJDK ports already which have ARM support, you might want to look there as a starting point? On Sat, Nov 9, 2013 at 8:59 AM, Pedro Duque Vieira pedro.duquevie...@gmail.com wrote: I'm sure the javafx team is doing a great job. My intention was not to put that in question but to try to contribute further to this discussion. Yes indeed oracle javafx team has fewer resources than what should be preferred. We need to harvest the power of the community in the best way we can to further expand the this resources. In that sense I think the best to do is to get better organized at doing so. Instead of a man for himself kind of effort we should have a kind of corporate like structure with the intricacies of being a group of volunteers... On Nov 9, 2013 1:21 PM, Felix Bembrick felix.bembr...@gmail.com wrote: What we do know is that Oracle are working on something and that RoboVM is already out there. We also know that RoboVM has serious limitations such as being based on the Android class library, not supporting JDK 8 or OpenJDK or invokedynamic etc. so is not really a viable solution at this stage. This is not to say that the work of Niklas is not first-class as it clearly is an
Re: Look and feel mechanism?
All I know, as a 3rd party control developer, is that I want to be able to setup the CSS of my controls in such a way that as much of a new skin is automatically adopted; borders, colors, focus rendering, etc. Tom
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
Re: Programmatic (Java) access to style / layout ?
Small side remark: in order to stay compliant with the Java Bean specification,
these kind of setters are often implemented as withers (which call the setter
and return this):
button.border().hover()
.withColor(red)
.withStrokeWidth(10)
.withBlink(false)
.withHandler(()-{});
Or as plain methods:
button.border().hover()
.color(red)
.strokeWidth(10)
.blink(false)
.handler(()-{});
On 2013-12-18 12:03, Assaf Yavnai wrote:
I agree that different people would like different things
here is mine ;)
button.border().hover().setColor(red);
This styling is widely used in scripting languages, jQuery is a good example. Its
done by always return an object from an operation, in this example setColor() will
return the same object that was returned from hover(), allowing further
manipulation in the same line of code. For example
button.border().hover().setColor(red).setStrokeWidth(10).setBlink(false).setHandler(()-{});
If readability is an issue it can be formatted as:
button.border().hover()
.setColor(red)
.setStrokeWidth(10)
.setBlink(false)
.setHandler(()-{});
And this reminds me another issue, which may be a fork, but in my point of view
its originated from the same approach, which is users manipulate internal data
structures directly to do operations.
I didn't understand the design decision to expose internal structures in FX to do
operations and manipulate them directly. In this case properties, another example
is root.getChilderen().add(). This not only expose the internal data structure,
but also requires more coding for simple trivial operation. users 90% don't
need/care about the internal data structures, but 100% want to write less and
simpler code. Usually user just want to do some trivial thing, add, remove,
traverse..., for those common cases an alias can be used that encapsulate inside
it the data structure used and the language quirks. In this example root.add()
would do the trick. Other operations could look similar, like root.clear(), root,
remove(...). root.traverse()(will return an iterator). For those edge cases which
requires manipulating the data structure directly API can expose them, like
root.getChildrensAsList(), or root.getChildren()
Combining the 2 approaches and the ability to retrieve the nodes related to the
operations in 2 levels, say through .base() and .parent(), would yield the
results that Oliver suggested (as I understood them)
(hope the layout wouldn't get scrambled upon send)
Group root = new Group()
.add( new Button()
.border()
.hover()
.setColor(red)
.setStrokeWidth(10)
.setBlink(false)
.setHandler(()-{})
.parent() //parent() return
border
.setColor(blue)
.setBlink(true)
.base().caption() //base()
return button
.setText(button1)
.setFontSize(30)
.base(),
new Button(button 2).caption()
.setSize(25)
.setHandler(()-{}))
.base()
)//end of add()
.some().other().operation.onGroup()
);
my 0.002$
Assaf
On 12/17/2013 11:18 PM, David Grieve wrote:
It is possible, but probably not in the way that
https://javafx-jira.kenai.com/browse/RT-17293 would provide. By that I mean, it would be
nice to be able to progammatically say the border color for this button when
hovered is red. This can be done now by adding an invalidation listener to the
hoverProperty and setting the border on Region, but I don' t think this is what you are
after.
I think RT-17923 means different things to different people. I'd be interested
to know what such and API would look like to you.
On Dec 17, 2013, at 3:39 PM, Oliver Doepner odoep...@gmail.com wrote:
Hello,
This might have been asked before but I haven't found it:
Is it possible to style JavaFX components using pure Java (i.e. without
CSS)?
If this is being worked on, does anyone know what the status is?
I think this is one of the areas where JavaFX can actually be better than
HTML5/CSS because a nicely typed Java representation of CSS could provide
great tooling and features that others had to invent LESS or SASS for.
I have seen this (from Oct 2012):
http://stackoverflow.com/questions/12943501/style-javafx-components-without-css
I have also seen this: https://javafx-jira.kenai.com/browse/RT-17293
Last update: Brian
Beckhttps://javafx-jira.kenai.com/secure/ViewProfile.jspa?name=bcbeckadded
a comment - Mar,
12 2012 09:01 PM : It is now past the point where this feature can be
added for 2.1. Will need to be considered for a future release
Thanks
Oliver
--
Oliver Doepner
IndexOutOfBoundsException with an empty CSS block
When I assign a style class to a GridPane (which is then added to a VBox and
that to a BorderPane and that in a Popup), like so:
lAppointmentGroupGridPane.getStyleClass().add(AppointmentGroups);
Which has an empty block in CSS:
.AgendaPopup .AppointmentGroups {
}
An exception occurs. Commenting out the empty block in the CSS file makes the
exception go away.
Exception in thread JavaFX Application Thread
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.rangeCheck(ArrayList.java:638)
at java.util.ArrayList.get(ArrayList.java:414)
at com.sun.javafx.css.StyleMap.getCascadingStyles(StyleMap.java:121)
at javafx.scene.CssStyleHelper.getStyle(CssStyleHelper.java:683)
at javafx.scene.CssStyleHelper.lookupFont(CssStyleHelper.java:1548)
at javafx.scene.CssStyleHelper.transitionToState(CssStyleHelper.java:460)
at javafx.scene.Node.impl_processCSS(Node.java:8677)
at javafx.scene.Parent.impl_processCSS(Parent.java:1216)
at javafx.scene.Parent.impl_processCSS(Parent.java:1228)
at javafx.scene.Parent.impl_processCSS(Parent.java:1228)
at javafx.scene.Parent.impl_processCSS(Parent.java:1228)
at javafx.scene.Node.processCSS(Node.java:8587)
at javafx.scene.Scene.doCSSPass(Scene.java:538)
at javafx.scene.Scene.preferredSize(Scene.java:1504)
at javafx.scene.Scene.impl_preferredSize(Scene.java:1571)
at javafx.stage.Window$9.invalidated(Window.java:733)
at
javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:109)
at
javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:143)
at javafx.stage.Window.setShowing(Window.java:799)
at javafx.stage.Window.show(Window.java:814)
at javafx.stage.PopupWindow.showImpl(PopupWindow.java:403)
at javafx.stage.PopupWindow.show(PopupWindow.java:348)
at
jfxtras.labs.internal.scene.control.skin.AgendaWeekSkin.showMenu(AgendaWeekSkin.java:1969)
at
jfxtras.labs.internal.scene.control.skin.AgendaWeekSkin.access$2700(AgendaWeekSkin.java:84)
at
jfxtras.labs.internal.scene.control.skin.AgendaWeekSkin$MenuIcon$5.handle(AgendaWeekSkin.java:1238)
at
jfxtras.labs.internal.scene.control.skin.AgendaWeekSkin$MenuIcon$5.handle(AgendaWeekSkin.java:1233)
at
com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:86)
at
com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:238)
at
com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191)
at
com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59)
at
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58)
at
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
at
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
at
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
at
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
at
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
at
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
at
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74)
at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:54)
at javafx.event.Event.fireEvent(Event.java:203)
at javafx.scene.Scene$ClickGenerator.postProcess(Scene.java:3321)
at javafx.scene.Scene$ClickGenerator.access$8800(Scene.java:3252)
at javafx.scene.Scene$MouseHandler.process(Scene.java:3600)
at javafx.scene.Scene$MouseHandler.process(Scene.java:3385)
at javafx.scene.Scene$MouseHandler.access$1900(Scene.java:3336)
at javafx.scene.Scene.impl_processMouseEvent(Scene.java:1618)
at javafx.scene.Scene$ScenePeerListener.mouseEvent(Scene.java:2395)
at
com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:312)
at
com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:237)
at java.security.AccessController.doPrivileged(Native
Re: Performance-limiting characteristics of Nodes
I also watched Gerrits presentation, and he put a lot of emphasis on the difference between drawing using nodes and drawing using CSS. One of the examples was one of his famous gauges, where he used a number of gradients to draw the background. His initial approach was one-node-per-gradient, so a node for the background, one for the upper shadow, one for the lower, etc. This resulted in a lot of nodes and he says the Pi has a maximum of about 120 nodes. Now, these background nodes (and all others that make up the dial) are static nodes, they do not easily go dirty. So I'm not sure that that is the problem Gerrit experienced. That said, the other approach where he tries to do as much in one node as possible, using CSS, insets and multiple backgrounds/fills seems like a much clear implementation. So there are other advantages as well. But never the less it would be interesting to see what the performance issue really is, given your statement. Tom On 2013-12-30 1:50, Jasper Potts wrote: My experience was it is not the number of Nodes. It's the number of Nodes that are changed/dirty in a single frame. So having a scene with 500 nodes may take a couple of seconds to render first time but then you can animate a couple of those nodes at 60fps if you done make too big a area dirty. Performance issues are one of two things too much SceneGraph work or too much Graphics card work. You can use pulse logger to determine which issue you are having. Jasper On Dec 29, 2013, at 3:15 PM, Felix Bembrick felix.bembr...@gmail.com wrote: I just watched the excellent presentation by Gerrit Grunwald Use the force Luke on Parleys and in it he mentions that one of the key ways to improve performance is to limit the number of nodes in the scenegraph. He also mentions that on such devices as the Raspberry Pi the maximum number of nodes viable before performance degrades significantly is very, very limited. Further, he then goes on to demonstrate that the equivalent visual appearance can be achieved by other means such as CSS, Canvas etc. where the number of nodes is much less. The implication here is that there is a performance-limiting effect of Nodes. If the device's GPU is capable of rendering certain graphics primitives, effects, transitions etc. and JavaFX is capable of making them happen by one way or another, I am curious as to why the simple presence of Nodes limits performance so significantly. The obvious conclusion is that Nodes use memory and perhaps the associated overhead is the cause but given that we are largely talking about GPU based processing I find it hard to believe that it's as simple as this. So what is it about the nature of Nodes that causes them to have such a limiting effect on performance? Cheers, Felix
Re: Performance-limiting characteristics of Nodes
removing and re-adding nodes to the scenegraph, yeah, sounds like a good suspect. I just got offered a commercial JavaFX project (which I ended up not doing because of all my other work) where the client said that they tried doing it themselves, but had all kinds of architectural issues they needed me to solve. Personally I experienced something similar Gerrit explains here when trying to write my Agenda control, it appears the first time you do JavaFX you'll be doing it wrong. Even though the learning curve is much less than Swing's, there still is one. It may be a good idea to get some best practices going. Tom On 2013-12-30 12:09, Gerrit Grunwald wrote: I'm pretty sure that one performance drawback in these gauges is related to constantly removing and re-adding nodes to the scenegraph in the layoutChildren method. This might be the reason why even static drawing code will be handled even if it was not necessary. One reason why in the Enzo controls I add nodes only once to the scenegraph and from that point on only modify the nodes. On the Pi I think one reason for performance problems might be (not sure) that paths are rastered by the cpu and because I use a lot of paths and the cpu is not that powerful it leads to performance decrease when using lots of nodes containing paths but that's more a guess... Cheers, Gerrit mailhan.s...@muenster.de webharmonic-code.org twitter hansolo_ Am 30.12.2013 um 11:01 schrieb Felix Bembrick felix.bembr...@gmail.com: Yes Tom, I also came to the conclusion that most of the nodes in those (awesome) gauges are largely static and would rarely, if ever, become dirty so the inference that it's excessive work on the scenegraph would seem unlikely as the cause of the performance degradation. It does look to me that there is some inherent impact on performance associated simply with having more nodes. I hope Richard or someone with intimate knowledge of the innards of JavaFX rendering could chime in here... On 30 December 2013 20:50, Tom Eugelink t...@tbee.org wrote: I also watched Gerrits presentation, and he put a lot of emphasis on the difference between drawing using nodes and drawing using CSS. One of the examples was one of his famous gauges, where he used a number of gradients to draw the background. His initial approach was one-node-per-gradient, so a node for the background, one for the upper shadow, one for the lower, etc. This resulted in a lot of nodes and he says the Pi has a maximum of about 120 nodes. Now, these background nodes (and all others that make up the dial) are static nodes, they do not easily go dirty. So I'm not sure that that is the problem Gerrit experienced. That said, the other approach where he tries to do as much in one node as possible, using CSS, insets and multiple backgrounds/fills seems like a much clear implementation. So there are other advantages as well. But never the less it would be interesting to see what the performance issue really is, given your statement. Tom On 2013-12-30 1:50, Jasper Potts wrote: My experience was it is not the number of Nodes. It's the number of Nodes that are changed/dirty in a single frame. So having a scene with 500 nodes may take a couple of seconds to render first time but then you can animate a couple of those nodes at 60fps if you done make too big a area dirty. Performance issues are one of two things too much SceneGraph work or too much Graphics card work. You can use pulse logger to determine which issue you are having. Jasper On Dec 29, 2013, at 3:15 PM, Felix Bembrick felix.bembr...@gmail.com wrote: I just watched the excellent presentation by Gerrit Grunwald Use the force Luke on Parleys and in it he mentions that one of the key ways to improve performance is to limit the number of nodes in the scenegraph. He also mentions that on such devices as the Raspberry Pi the maximum number of nodes viable before performance degrades significantly is very, very limited. Further, he then goes on to demonstrate that the equivalent visual appearance can be achieved by other means such as CSS, Canvas etc. where the number of nodes is much less. The implication here is that there is a performance-limiting effect of Nodes. If the device's GPU is capable of rendering certain graphics primitives, effects, transitions etc. and JavaFX is capable of making them happen by one way or another, I am curious as to why the simple presence of Nodes limits performance so significantly. The obvious conclusion is that Nodes use memory and perhaps the associated overhead is the cause but given that we are largely talking about GPU based processing I find it hard to believe that it's as simple as this. So what is it about the nature of Nodes that causes them to have such a limiting effect on performance? Cheers, Felix
scenebuilder and migpane
Would it be possible to offer MigPane as a Container in SceneBuilder? Tom
custom FXML builders in SceneBuilder
I had no problems adding the JFXtras components to SceneBuilder, but one of the controls has a custom FXML builder. It is present in the same jar, but how do I tell SceneBuilder to use it? Now when I try to load an fxml file an exception (unable to coerse) is shown by SceneBuilder. Tom
Re: scenebuilder and migpane
Well, I figure the helper lines will be a problem anyhow. But I was planning on just trying it. Tom On 2014-1-3 11:04, Eric Le Ponner wrote: I guess it's worth trying to drop MigPane JAR file in SB2 library panel and see. However SB2 makes some assumptions about containers. So that might not work straight away. Eric Le 3 janv. 2014 à 10:10, Tom Eugelink t...@tbee.org a écrit : Would it be possible to offer MigPane as a Container in SceneBuilder? Tom
Re: custom FXML builders in SceneBuilder
I think there are two usages of builders: - construct compontents / controls programatically (ending in the build() call). - mapping of FXML attributes to node properties, because in FXML everything must be a string. For example, CalendarTextField has no builder class in the first sense (I used withers for that), but does have a class that converts the dateFormats (list of SimpleDateFormat strings) in an fxml file to an actual list of DateFormats instances. https://github.com/JFXtras/jfxtras-labs/blob/8.0/src/main/java/jfxtras/labs/fxml/CalendarTextFieldBuilder.java If you can explain to me how to do this without a builder, but also without polluting CalendarTextField with FXML aspects, then I'll change the code. Tom On 2014-1-3 11:44, Eric Le Ponner wrote: When Scene Builder 2.0 found a custom components, it instantiates it using FXMLLoader without making any specific builder setup. So FXMLLoader uses the default JavaFX builder factory. Since builders are deprecated, I'm not sure it make sense for SB to have dependency on them. Eric Le 3 janv. 2014 à 10:55, Tom Eugelink t...@tbee.org a écrit : I had no problems adding the JFXtras components to SceneBuilder, but one of the controls has a custom FXML builder. It is present in the same jar, but how do I tell SceneBuilder to use it? Now when I try to load an fxml file an exception (unable to coerse) is shown by SceneBuilder. Tom
Re: not all custom controls are usable in SceneBuilder
On 2014-1-3 11:18, Yves JOAN wrote: On 03/01/14 11:03, Tom Eugelink wrote: Not all JFXtras custom components are draggable from the library's custom tab to the scene. For example Agenda and CalendarTextField can be dragged, but CalendarPicker or ListSpinner cannot. Is there any way to determine why this is the case? SceneBuilder only shows a forbidden icon as the mouse pointer. I've no trouble dragging all the one you list, CalendarPicker and ListSpinner included. I use a JFXtras jar stamped Nov. 24th and the latest promoted SceneBuilder 2 (b09). Note that in the coming b10 there's a way to read the jar analysis report, useful if you do not see coming up in the Library the expected custom item. Ok. I'll try newer versions of SceneBuilder. I'm using JFXtras 8.0-r1-SNAPSHOT. Problem remains that all the feedback I get is the forbidden mouse pointer, so I cannot diagnose the reason. Tom
Re: scenebuilder and migpane
Simply dropping the jars is not possible, because MigLayout is split into two jars; core and javafx. Core does not contain any JavaFX classes and thus SceneBuilder does not import it (button is disabled). After manually merging the two jars into one, MigPane is listed in SB as a custom control. Dropping nodes onto MigPane works; they are put next to each other, as the default layout logic of MigPane does things. But for each node there should be a possibility to specify a constraint string, the cc property is not listed in the inspector (unlike, for example, hgrow in a HBox). I've created a special FXML MigPane class to contain the FXML scaffolding, this class has a static void setCc(Node, String) method. What determines when such a static method is displayed in the inspector's layout tab? Missing are the helper lines to show the grid, like GridPane has. I'm assuming there is some kind of helper class to better embed the layouts in SB? MigLayout is a very popular layout engine in Swing and SWT (and also gaining ground on Android), I think it would be good for SceneBuilder to better support MigLayout. Tom On 2014-1-3 11:04, Eric Le Ponner wrote: I guess it's worth trying to drop MigPane JAR file in SB2 library panel and see. However SB2 makes some assumptions about containers. So that might not work straight away. Eric Le 3 janv. 2014 à 10:10, Tom Eugelink t...@tbee.org a écrit : Would it be possible to offer MigPane as a Container in SceneBuilder? Tom
JavaFX on headless Jenkins
I'm trying to run JavaFX UI tests using TestFX on a headless Jenkins server (Ubuntu / Debian). I've gotten to the point where the UI is actually started by Jenkins, but then the test fail with a no suitable pipeline found. Any suggestions how to fix that? :*test* Executing task ':test' (up-to-date check took 0.054 secs) due to: No history is available. Starting process 'Gradle Worker 1'. Working directory: /var/lib/jenkins/workspace/JFXtras8.0 Command: /usr/lib/jvm/jdk1.8.0-ea/bin/java -Djava.security.manager=jarjar.org.gradle.process.internal.child.BootstrapSecurityManager -Dfile.encoding=UTF-8 -ea -cp /var/lib/jenkins/.gradle/caches/1.9/workerMain/gradle-worker.jar jarjar.org.gradle.process.internal.launcher.GradleWorkerMain Successfully started process 'Gradle Worker 1' Gradle Worker 1 executing tests. jfxtras.labs.scene.control.test.ListSpinnerEditableTest enterSelectValueByTyping STANDARD_ERROR Graphics Device initialization failed for : es2, sw Error initializing QuantumRenderer: no suitable pipeline found java.lang.RuntimeException: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found at com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:300) at com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:244) at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:179) at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:210) at com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:653) at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:678) at com.sun.javafx.application.LauncherImpl.access$000(LauncherImpl.java:56) at com.sun.javafx.application.LauncherImpl$1.run(LauncherImpl.java:158) at java.lang.Thread.run(Thread.java:744) Caused by: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:98) at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:128) ... 1 more Exception in thread Thread-4 java.lang.RuntimeException: No toolkit found at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:191) at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:210) at com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:653) at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:678) at com.sun.javafx.application.LauncherImpl.access$000(LauncherImpl.java:56) at com.sun.javafx.application.LauncherImpl$1.run(LauncherImpl.java:158) at java.lang.Thread.run(Thread.java:744)
Re: JavaFX on headless Jenkins
Yes please, I've got Jenkins setup so it starts a vncserver and it runs on linux, so I'm interesting in the option you mention (as long as it doesn't require too many hoops I need to jump through). Tom On 2014-1-6 17:36, David Hill wrote: On 1/4/14, Jan 4, 3:57 PM, Tom Eugelink wrote: I'm trying to run JavaFX UI tests using TestFX on a headless Jenkins server (Ubuntu / Debian). I've gotten to the point where the UI is actually started by Jenkins, but then the test fail with a no suitable pipeline found. Any suggestions how to fix that? This has long been a challenge with FX. I even modified Glass/Lens to get a headless with a VNC option working on Linux Mac (Windows probably needed a little porting). This has never been a priority though, only a casual hobby. Daniel is working on a refresh of Glass/Lens that may make it even easier to do headless (as a side effect). If there is any interest, I can provide more information on the current Glass/Lens headless. Dave :*test* Executing task ':test' (up-to-date check took 0.054 secs) due to: No history is available. Starting process 'Gradle Worker 1'. Working directory: /var/lib/jenkins/workspace/JFXtras8.0 Command: /usr/lib/jvm/jdk1.8.0-ea/bin/java -Djava.security.manager=jarjar.org.gradle.process.internal.child.BootstrapSecurityManager -Dfile.encoding=UTF-8 -ea -cp /var/lib/jenkins/.gradle/caches/1.9/workerMain/gradle-worker.jar jarjar.org.gradle.process.internal.launcher.GradleWorkerMain Successfully started process 'Gradle Worker 1' Gradle Worker 1 executing tests. jfxtras.labs.scene.control.test.ListSpinnerEditableTest enterSelectValueByTyping STANDARD_ERROR Graphics Device initialization failed for : es2, sw Error initializing QuantumRenderer: no suitable pipeline found java.lang.RuntimeException: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found at com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:300) at com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:244) at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:179) at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:210) at com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:653) at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:678) at com.sun.javafx.application.LauncherImpl.access$000(LauncherImpl.java:56) at com.sun.javafx.application.LauncherImpl$1.run(LauncherImpl.java:158) at java.lang.Thread.run(Thread.java:744) Caused by: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:98) at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:128) ... 1 more Exception in thread Thread-4 java.lang.RuntimeException: No toolkit found at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:191) at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:210) at com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:653) at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:678) at com.sun.javafx.application.LauncherImpl.access$000(LauncherImpl.java:56) at com.sun.javafx.application.LauncherImpl$1.run(LauncherImpl.java:158) at java.lang.Thread.run(Thread.java:744)
Re: JavaFX on headless Jenkins
Ok. I saw xfvb passing by, but most blogs talked about xvnc, I'll give that a spin. Thanks. Tom BTW: the Travis environment keeps reporting errors; it has trouble downloading one of the supporting jar from maven. On 2014-1-6 23:49, Matthieu BROUILLARD wrote: On the linux nodes on travis.org http://travis.org xvfb is used to mimic a GUI environment on headless nodes. Have a look at : http://about.travis-ci.org/docs/user/gui-and-headless-browsers/ you might be probably able to do something like that on your linux box. Matthieu
Re: scenebuilder and migpane
On 2014-1-6 17:19, Richard Bair wrote: MigLayout is a very popular layout engine in Swing and SWT (and also gaining ground on Android), I think it would be good for SceneBuilder to better support MigLayout. +1, I’d love to see enough support in SceneBuilder that any 3rd party layout container could supply editor support, so that the SceneBuilder team doesn’t have to hard code support for different layout containers. This was one of the goals of the “Design Time API for Java Beans” JSR (273, or 277? I don’t remember) to do the same for Swing. We haven’t got that far with Scene Builder but I think the idea is great. MigLayout is widely used enough that we could just add hard-coded support for it (maybe you or another person could contribute that?). Ideally it would be something any 3rd party layout vendor could provide — but in practice there are not that many widely used 3rd party layouts — even in the Swing world. Sure, if I can get some help getting started. (Aka if somebody tells me which class needs implementing and -reading that one post- how to build SceneBuilder, I'll bring the MigPane knowledge to the party.) Tom
Re: JavaFX on headless Jenkins
Nope, Xvfb has the same problem... Xvfb starting$ /usr/bin/Xvfb :2 -screen 0 1024x768x24 -fbdir /var/lib/jenkins/2014-01-07_19-17-242962656246439721545xvfb ... :*test* Executing task ':test' (up-to-date check took 0.051 secs) due to: No history is available. Starting process 'Gradle Worker 1'. Working directory: /var/lib/jenkins/workspace/JFXtrasLabs8.0 Command: /usr/lib/jvm/jdk1.8.0-ea/bin/java -Djava.security.manager=jarjar.org.gradle.process.internal.child.BootstrapSecurityManager -Dfile.encoding=UTF-8 -ea -cp /var/lib/jenkins/.gradle/caches/1.9/workerMain/gradle-worker.jar jarjar.org.gradle.process.internal.launcher.GradleWorkerMain Successfully started process 'Gradle Worker 1' Gradle Worker 1 executing tests. jfxtras.labs.scene.control.test.ListSpinnerEditableTest enterSelectValueByTyping STANDARD_ERROR Graphics Device initialization failed for : es2, sw Error initializing QuantumRenderer: no suitable pipeline found java.lang.RuntimeException: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found at com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:300) at com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:244) at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:179) at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:210) at com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:653) at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:678) at com.sun.javafx.application.LauncherImpl.access$000(LauncherImpl.java:56) at com.sun.javafx.application.LauncherImpl$1.run(LauncherImpl.java:158) at java.lang.Thread.run(Thread.java:744) Caused by: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:98) at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:128) ... 1 more Exception in thread Thread-4 java.lang.RuntimeException: No toolkit found at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:191) at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:210) at com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:653) at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:678) at com.sun.javafx.application.LauncherImpl.access$000(LauncherImpl.java:56) at com.sun.javafx.application.LauncherImpl$1.run(LauncherImpl.java:158) at java.lang.Thread.run(Thread.java:744) jfxtras.labs.scene.control.test.ListSpinnerEditableTest enterSelectValueByTyping FAILED java.lang.RuntimeException: Unable to show stage Caused by: java.util.concurrent.TimeoutException: Timeout waiting for task. But I can start both the xvnc and Xvfb manually as user Jenkins, for example Xvfb: /jenkins@leah:~$ /usr/bin/Xvfb :2 -screen 0 1024x768x24 -fbdir /tmp// //SELinux: Disabled on system, not enabling in X server// //[dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list!/ Then I need to ^C to terminate Xvfb. But it does seem that your Travis environments indeed has run the tests: https://travis-ci.org/JFXtras/jfxtras-labs/builds/15810910 So the question is: how did Travis do that (since both approaches are identical)? One thing I notice is that it starts Xfvb as a service, not as an application. sh -e /etc/init.d/xvfb start But that script is not available on my Linux after installing Xvfb... Tom On 2014-1-7 6:58, Tom Eugelink wrote: Ok. I saw xfvb passing by, but most blogs talked about xvnc, I'll give that a spin. Thanks. Tom BTW: the Travis environment keeps reporting errors; it has trouble downloading one of the supporting jar from maven. On 2014-1-6 23:49, Matthieu BROUILLARD wrote: On the linux nodes on travis.org http://travis.org xvfb is used to mimic a GUI environment on headless nodes. Have a look at : http://about.travis-ci.org/docs/user/gui-and-headless-browsers/ you might be probably able to do something like that on your linux box. Matthieu
Re: JavaFX on headless Jenkins
Jenkins does that for me. On 2014-1-7 21:13, Matthieu BROUILLARD wrote: For JFXtras build on travis.org http://travis.org, I just followed some docs pages to setup xvfb, sorry I am not a linux/unix expert and don't know how to help more. /[Stupid linux user mode activated]/ If you do not have the /etc/init.d/xvfb script, can't you launch the program itself in background? /[/Stupid linux user mode activated]/ Matthieu
Re: CSS metadata boilerplate
Yes, I had similar considerations. I was thinking about providing exactly such
extended Property classes in JFXtras to remove as much of the boilerplate.
Tom
On 2014-1-8 3:34, John Hendrikx wrote:
Hi List,
I'm in the process of adding CSS metadata to a new control, and I noticed there
is a lot of boilerplate.
In order to reduce this, I've created some custom classes StyleableProperty
classes (SimpleStyleableXXXProperty), which reduces the boilerplate
significantly without sacrificing much (if any) performance. The only thing
that I cannot easily provide in this fashion is the static getClassCssMetaData
method. From the documentation I understand it is there just for convience for
subclass creators and is not used by the CSS engine at all -- atleast,
everything seems to work.
The shortened version for CSS aware properties basically looks like:
private final SimpleStyleableDoubleProperty cellAlignment = new
SimpleStyleableDoubleProperty(this, cellAlignment, -fx-cell-alignment, 0.8);
private final SimpleStyleableDoubleProperty density= new SimpleStyleableDoubleProperty(this,
density, -fx-density, 0.02);
private final SimpleStyleableBooleanProperty reflectionEnabled= new
SimpleStyleableBooleanProperty(this, reflectionEnabled,
-fx-reflection-enabled, true);
private final SimpleStyleableBooleanProperty clipReflections= new
SimpleStyleableBooleanProperty(this, clipReflections, -fx-clip-reflections,
true);
With one small bit of supporting code in the relevant class (Skin or Control),
which is basically a non-static implementation of the standard CSS List example
code:
private static ListCssMetaData? extends Styleable, ? cssMetaData;
@Override
public ListCssMetaData? extends Styleable, ? getCssMetaData() { //
Unsynchronized. WC: list gets initialized multiple times.
if(cssMetaData == null) {
ListCssMetaData? extends Styleable, ? metaData = new
ArrayList(super.getCssMetaData());
Collections.addAll(metaData,
cellAlignment.getCssMetaData(),
density.getCssMetaData(),
reflectionEnabled.getCssMetaData(),
clipReflections.getCssMetaData()
);
cssMetaData = Collections.unmodifiableList(metaData);
}
return cssMetaData;
}
Note that the List is static and lazy-final. The same goes for the
getCssMetaData method in the SimpleStyleableXXXProperty classes. There is a
slight performance decrease in those classes as getCssMetaData is looked up
from a static Map (indexed by Class + css property name) and lazily created as
needed -- a Map lookup however should be quite fast enough.
I'm sure the design had good reason to do things as they are, and I'm wondering
if reducing the boilerplate has left me missing something important.
I welcome any insights!
--John
Re: Future of Skins
I've written the Agenda control (Google Calendar alike) in JFXtras, which of course also can have multiple skins although right now it only has one. So this is an interesting discussion. On 2014-1-8 22:31, John Hendrikx wrote: That's basically how I've solved it so far (although I call the reusable skins Layouts for lack of a more imaginitive name). However, I'd like to support CSS properties as well for the delegates, and I'm not sure how the CSS engine deals with Skins that can change their properties when some other property (the delegated Skin) changes. I suspect that changing properties will work fine for changing normal Skins, but that it won't be able to detect the properties having changed when the a Skin I delegate to changes. Perhaps though I'm going a bit too far in order to provide that little bit of extra convience and customization possibilities to the end-user of the Control. --John On 7/01/2014 17:04, Richard Bair wrote: Could you write a single skin that delegates to one or more reusable skins?
Re: custom FXML builders in SceneBuilder
Hi Eric, Any chance you had time to look into this? Tom On 2014-1-3 12:19, Eric Le Ponner wrote: I will look at that and come back to you middle of next week. Eric Le 3 janv. 2014 à 12:12, Tom Eugelink t...@tbee.org a écrit : I think there are two usages of builders: - construct compontents / controls programatically (ending in the build() call). - mapping of FXML attributes to node properties, because in FXML everything must be a string. For example, CalendarTextField has no builder class in the first sense (I used withers for that), but does have a class that converts the dateFormats (list of SimpleDateFormat strings) in an fxml file to an actual list of DateFormats instances. https://github.com/JFXtras/jfxtras-labs/blob/8.0/src/main/java/jfxtras/labs/fxml/CalendarTextFieldBuilder.java If you can explain to me how to do this without a builder, but also without polluting CalendarTextField with FXML aspects, then I'll change the code. Tom On 2014-1-3 11:44, Eric Le Ponner wrote: When Scene Builder 2.0 found a custom components, it instantiates it using FXMLLoader without making any specific builder setup. So FXMLLoader uses the default JavaFX builder factory. Since builders are deprecated, I'm not sure it make sense for SB to have dependency on them. Eric Le 3 janv. 2014 à 10:55, Tom Eugelink t...@tbee.org a écrit : I had no problems adding the JFXtras components to SceneBuilder, but one of the controls has a custom FXML builder. It is present in the same jar, but how do I tell SceneBuilder to use it? Now when I try to load an fxml file an exception (unable to coerse) is shown by SceneBuilder. Tom
Go Gerrit
Just to update the people who are not keeping taps on what Gerrit Grunwald is doing, but he has his JavaFX application running on a Mac, Nexus 7, iPad, iPhone and this afternoon on an Android SmartWatch. Here is the watch version http://www.youtube.com/watch?v=XpplIIIKZ2s Of course the different screen sizes require different layouts, but the code is shared between the devices as much as possible, so basically it's the same code base. #GoGerrit
Re: 8u20: Request for feedback on unit test proposal
Am I to understand that this is using the VNC server? Because I'm not seeing the tell-tale -D parameters in the gradle.build. Or is this actually running on-screen? Tom On 2014-1-30 18:40, Daniel Blaukopf wrote: Hi, I put up on https://javafx-jira.kenai.com/browse/RT-35396 a draft of what our unit tests might look like if we were to run them on top of the real Quantum Toolkit instead of StubToolkit. The main problem is how to solve the threading: tests that use StubToolkit are all accessing the toolkit and scene graph on the main thread, which you can’t do in Quantum. A webrev is here: http://cr.openjdk.java.net/~dblaukop/webrev-20140123-1559-RT-35330/webrev It’s not complete. I rewrote some tests to correct the threading, but many other problems remain, like that tests call methods on StubToolkit that are not part of the Toolkit interface. For a start I’d like feedback on how we get around the threading problems in JUnit. Thanks, Daniel
Re: UndoFX: undo manager for JavaFX
And then there is JFXtras... :-) On 2014-2-6 18:20, Christian Schudt wrote: Hehe, funny how every project is called *FX. Still waiting for the YetAnotherProjectFX :-) Let's see, what I could find by a quick research: ControlsFX DataFX RedFX CodeAreaFX ReactFX UndoFX ExtFX ScreenFX TestFX DrawKidFX FontAwesomeFX AquaFX PlantUMLFX GroovyFX MonologFX TiddlyWikiFX DromblerFX ScalaFX OrbitFX SendGridFX -- Christian Am 06.02.2014 um 18:02 schrieb Tomas Mikula: Hi all, I just published a general-purpose undo manager for JavaFX. https://github.com/TomasMikula/UndoFX I've been using it for a while in CodeAreaFX and thought it would be useful to release it separately. Best regards, Tomas
TestFX and popup
I'm using a Popup and need TestFX to click some buttons that are in the popup, but the nodes are not found. How is a Popup hooked into an existing node tree? The code in a.o. PopupWindow seems to only reference one way; from the popup towards the owner, but not the other way. Only if the owning window is a PopupWindow is the popup added to its children. But if the owning window is a simple stage, then I see no way to get to the Popup. What I (and TestFX) would need is some way to bridge from the stage over to the popup.
Image by CSS and popup size
In the datetime textfields in JFXtras, the picker popup has an explicit close button rendered using an ImageView, the image is specified using CSS -fx-image. This ImageView is added as the right of a BorderPane, and the BorderPane is the content of a popup. What happens is that the close image is not shown. I suspect this is because the CSS is applied after the popup is opened, so the ImageView initially has a width of 0. For the moment I enforce a width using setFitWidth(16), but that of course is not the idea of styling via CSS. Trying to preload the ImageView is not possible, because it is not part of any scene/stage until the popup is shown and therefore its CSS is not applied until then. Preloading the image is not possible, because it is styled through CSS. I'm stuck; how do I make sure the popup sizes to the correct width, taking the CSS styled image in account? Tom
CircularPane
For those interested, I've just put an implementation of a CircularPane in JFXtras-labs. http://jfxtras.org/images/gallery/CircularPane.png One never knows how to put such a thing to use. Regards, Tom
Re: add calculating methods to bind
Found it! Slightly different DoubleBinding was required (copied it from negate).
private DoubleBinding snap(final ObservableNumberValue value, final
Observable... dependencies) {
return new DoubleBinding() {
{
super.bind(value);
}
@Override
public void dispose() {
super.unbind(value);
}
@Override
protected double computeValue() {
return NodeUtil.snapXY(value.doubleValue());
}
@Override
public ObservableList? getDependencies() {
return FXCollections.singletonObservableList(value);
}
};
}
On 2014-5-21 21:34, Tomas Mikula wrote:
Hi Tom,
it seems to me that in your custom DoubleBinding implementation
`other` is not its dependency, thus it does not react to it's
invalidations.
Tomas
On Wed, May 21, 2014 at 9:25 PM, Tom Eugelink t...@tbee.org wrote:
I came up with this:
startXProperty().bind( *snap(*heightProperty().multiply(0.2)) )
And then:
private DoubleBinding snap(final ObservableNumberValue other, final
Observable... dependencies) {
return new DoubleBinding() {
{
super.bind(dependencies);
}
@Override
public void dispose() {
super.unbind(dependencies);
}
@Override
protected double computeValue() {
return NodeUtil.snap(other.doubleValue());
}
@Override
public ObservableList? getDependencies() {
return new
ImmutableObservableListObservable(dependencies);
}
};
}
But that always returns 0... I feel this should have worked.
Tom
Re: add calculating methods to bind
If I ever write a real application, I'm most definitely will use EasyBind. But
this is for sharping up Agenda in JFXtras. I try to minimize the dependencies.
Tom
On 2014-5-21 22:00, Tomas Mikula wrote:
Just a side note, you could use
EasyBind.map(heightProperty(), value -
NodeUtil.snapXY(value.doubleValue() * 0.2));
instead of
snap(heightProperty().multiply(0.2))
and you don't need your custom DoubleBinding implementation. But note
that it returns BindingDouble, not DoubleBinding.
EasyBind is at http://www.fxmisc.org/easybind/
Tomas
On Wed, May 21, 2014 at 9:47 PM, Tomas Mikula tomas.mik...@gmail.com wrote:
Yeah, and you could also eliminate Observable... dependencies from
snap's signature, since now you are not using them to invalidate your
binding.
On Wed, May 21, 2014 at 9:36 PM, Tom Eugelink t...@tbee.org wrote:
Found it! Slightly different DoubleBinding was required (copied it from
negate).
private DoubleBinding snap(final ObservableNumberValue value, final
Observable... dependencies) {
return new DoubleBinding() {
{
super.bind(value);
}
@Override
public void dispose() {
super.unbind(value);
}
@Override
protected double computeValue() {
return NodeUtil.snapXY(value.doubleValue());
}
@Override
public ObservableList? getDependencies() {
return FXCollections.singletonObservableList(value);
}
};
}
On 2014-5-21 21:34, Tomas Mikula wrote:
Hi Tom,
it seems to me that in your custom DoubleBinding implementation
`other` is not its dependency, thus it does not react to it's
invalidations.
Tomas
On Wed, May 21, 2014 at 9:25 PM, Tom Eugelink t...@tbee.org wrote:
I came up with this:
startXProperty().bind( *snap(*heightProperty().multiply(0.2)) )
And then:
private DoubleBinding snap(final ObservableNumberValue other, final
Observable... dependencies) {
return new DoubleBinding() {
{
super.bind(dependencies);
}
@Override
public void dispose() {
super.unbind(dependencies);
}
@Override
protected double computeValue() {
return NodeUtil.snap(other.doubleValue());
}
@Override
public ObservableList? getDependencies() {
return new
ImmutableObservableListObservable(dependencies);
}
};
}
But that always returns 0... I feel this should have worked.
Tom
Re: add calculating methods to bind
I feel the standard binding should offer an easy hook option
heightProperty().multiply(3.4).calc( value - { snap(vallue); } ).add(5.0)
On 2014-5-21 22:00, Tomas Mikula wrote:
Just a side note, you could use
EasyBind.map(heightProperty(), value -
NodeUtil.snapXY(value.doubleValue() * 0.2));
instead of
snap(heightProperty().multiply(0.2))
and you don't need your custom DoubleBinding implementation. But note
that it returns BindingDouble, not DoubleBinding.
EasyBind is at http://www.fxmisc.org/easybind/
Tomas
On Wed, May 21, 2014 at 9:47 PM, Tomas Mikula tomas.mik...@gmail.com wrote:
Yeah, and you could also eliminate Observable... dependencies from
snap's signature, since now you are not using them to invalidate your
binding.
On Wed, May 21, 2014 at 9:36 PM, Tom Eugelink t...@tbee.org wrote:
Found it! Slightly different DoubleBinding was required (copied it from
negate).
private DoubleBinding snap(final ObservableNumberValue value, final
Observable... dependencies) {
return new DoubleBinding() {
{
super.bind(value);
}
@Override
public void dispose() {
super.unbind(value);
}
@Override
protected double computeValue() {
return NodeUtil.snapXY(value.doubleValue());
}
@Override
public ObservableList? getDependencies() {
return FXCollections.singletonObservableList(value);
}
};
}
On 2014-5-21 21:34, Tomas Mikula wrote:
Hi Tom,
it seems to me that in your custom DoubleBinding implementation
`other` is not its dependency, thus it does not react to it's
invalidations.
Tomas
On Wed, May 21, 2014 at 9:25 PM, Tom Eugelink t...@tbee.org wrote:
I came up with this:
startXProperty().bind( *snap(*heightProperty().multiply(0.2)) )
And then:
private DoubleBinding snap(final ObservableNumberValue other, final
Observable... dependencies) {
return new DoubleBinding() {
{
super.bind(dependencies);
}
@Override
public void dispose() {
super.unbind(dependencies);
}
@Override
protected double computeValue() {
return NodeUtil.snap(other.doubleValue());
}
@Override
public ObservableList? getDependencies() {
return new
ImmutableObservableListObservable(dependencies);
}
};
}
But that always returns 0... I feel this should have worked.
Tom
Re: add calculating methods to bind
https://javafx-jira.kenai.com/browse/RT-37255
On 2014-5-23 8:05, Martin Sladecek wrote:
That would be nice. Don't forget to add it to JIRA!
-Martin
On 23.5.2014 07:11, Tom Eugelink wrote:
I feel the standard binding should offer an easy hook option
heightProperty().multiply(3.4).calc( value - { snap(vallue); } ).add(5.0)
On 2014-5-21 22:00, Tomas Mikula wrote:
Just a side note, you could use
EasyBind.map(heightProperty(), value -
NodeUtil.snapXY(value.doubleValue() * 0.2));
instead of
snap(heightProperty().multiply(0.2))
and you don't need your custom DoubleBinding implementation. But note
that it returns BindingDouble, not DoubleBinding.
EasyBind is at http://www.fxmisc.org/easybind/
Tomas
On Wed, May 21, 2014 at 9:47 PM, Tomas Mikula tomas.mik...@gmail.com wrote:
Yeah, and you could also eliminate Observable... dependencies from
snap's signature, since now you are not using them to invalidate your
binding.
On Wed, May 21, 2014 at 9:36 PM, Tom Eugelink t...@tbee.org wrote:
Found it! Slightly different DoubleBinding was required (copied it from
negate).
private DoubleBinding snap(final ObservableNumberValue value, final
Observable... dependencies) {
return new DoubleBinding() {
{
super.bind(value);
}
@Override
public void dispose() {
super.unbind(value);
}
@Override
protected double computeValue() {
return NodeUtil.snapXY(value.doubleValue());
}
@Override
public ObservableList? getDependencies() {
return FXCollections.singletonObservableList(value);
}
};
}
On 2014-5-21 21:34, Tomas Mikula wrote:
Hi Tom,
it seems to me that in your custom DoubleBinding implementation
`other` is not its dependency, thus it does not react to it's
invalidations.
Tomas
On Wed, May 21, 2014 at 9:25 PM, Tom Eugelink t...@tbee.org wrote:
I came up with this:
startXProperty().bind( *snap(*heightProperty().multiply(0.2)) )
And then:
private DoubleBinding snap(final ObservableNumberValue other, final
Observable... dependencies) {
return new DoubleBinding() {
{
super.bind(dependencies);
}
@Override
public void dispose() {
super.unbind(dependencies);
}
@Override
protected double computeValue() {
return NodeUtil.snap(other.doubleValue());
}
@Override
public ObservableList? getDependencies() {
return new
ImmutableObservableListObservable(dependencies);
}
};
}
But that always returns 0... I feel this should have worked.
Tom
monitor mouse events but not capture them
Hi all, Maybe someone has solved this already, so I thought I pop the question. Currently I'm working on CirclePopupMenu; a menu that is supposed to pop up on any place in a scene when a certain (usually the middle or right) mouse button is pressed. Right now CirclePopupMenu requires a stackpane to which it binds itself. CirclePopupMenu initially places an empty canvas Pane on the stack pane, and will use that to render and position the menu when it needs to appear. Also I need to monitor the mouse to detect if the menu should appear. In order to do that, I would like to use that canvas pane, but then any non relevant button clicks will not reach the underlying controls. In order to enable correct behavior I need to setPickOnBounds(false) on the pane, but then it does receive the mouse events anymore. Is there any way to monitor mouse events but still pass them through to the underlying controls? In Swing I did something similar and used a system level mouse event hook. Tom PS: I'm not certain if the stackpane approach I've used is the best way to do this. It does work expect the mouse button problem. But any suggestions are welcome.
Re: monitor mouse events but not capture them
Hm, maybe I chose bad words; I'm not using Canvas, but just a Pane. Since the Pane is only used to draw the menu on when it need to appear, I'm calling it the canvas pane, as in what is painted on. On 2014-6-9 9:46, Martin Sladecek wrote: Just looked at the code and it seems Canvas does pick on bounds independently of the pickOnBounds value. There's currently no logic for picking only when over an opaque pixel ( worth filing a JIRA issue maybe?). This makes Canvas to consume everything as it's always picked instead of some controls underneath. Unfortunately, I can't think of any solution that would work right now. If we'd support Node picking (https://javafx-jira.kenai.com/browse/RT-20184), it would be possible to redirect an unwanted event to a different event target on that mouse position. -Martin On 06/09/2014 08:44 AM, Tom Eugelink wrote: Ye. It does not work on the canvas pane, I suspect because of the pickOnBounds, but it does work on the stackpane. Plus, I can register to the stack pane without claiming the onMouseClick/Press hook. Many thanks! Tom On 2014-6-9 8:29, Martin Sladecek wrote: Hi Tom, have you tried .addEventFilter() method? It receives the Event before the controls underneath the canvas, in the capturing phase. If you don't consume the Event, it should pass down to the controls. For more on the topic, see http://docs.oracle.com/javafx/2/events/processing.htm or http://parleys.com/play/514892290364bc17fc56c39f -Martin On 06/09/2014 08:19 AM, Tom Eugelink wrote: Hi all, Maybe someone has solved this already, so I thought I pop the question. Currently I'm working on CirclePopupMenu; a menu that is supposed to pop up on any place in a scene when a certain (usually the middle or right) mouse button is pressed. Right now CirclePopupMenu requires a stackpane to which it binds itself. CirclePopupMenu initially places an empty canvas Pane on the stack pane, and will use that to render and position the menu when it needs to appear. Also I need to monitor the mouse to detect if the menu should appear. In order to do that, I would like to use that canvas pane, but then any non relevant button clicks will not reach the underlying controls. In order to enable correct behavior I need to setPickOnBounds(false) on the pane, but then it does receive the mouse events anymore. Is there any way to monitor mouse events but still pass them through to the underlying controls? In Swing I did something similar and used a system level mouse event hook. Tom PS: I'm not certain if the stackpane approach I've used is the best way to do this. It does work expect the mouse button problem. But any suggestions are welcome.
Re: monitor mouse events but not capture them
No, I require a StackPane, to which a special canvas Pane is added. And on that Pane a circular shaped menu is placed. The separate pane prevents conflicting with other nodes that may be drawn, the stack pane makes sure the menu is on top. See the blog post about both corner menu and circle popup menu: http://tbeernot.wordpress.com/ On 2014-6-9 10:13, Martin Sladecek wrote: OK, so to avoid further confusion, you have a PopupWindow with a Pane and you want to capture Events on the Pane and sent those events to the underlying controls (in a parent window) if those events are not relevant to that popup? Thanks, -Martin On 06/09/2014 10:07 AM, Tom Eugelink wrote: Hm, maybe I chose bad words; I'm not using Canvas, but just a Pane. Since the Pane is only used to draw the menu on when it need to appear, I'm calling it the canvas pane, as in what is painted on. On 2014-6-9 9:46, Martin Sladecek wrote: Just looked at the code and it seems Canvas does pick on bounds independently of the pickOnBounds value. There's currently no logic for picking only when over an opaque pixel ( worth filing a JIRA issue maybe?). This makes Canvas to consume everything as it's always picked instead of some controls underneath. Unfortunately, I can't think of any solution that would work right now. If we'd support Node picking (https://javafx-jira.kenai.com/browse/RT-20184), it would be possible to redirect an unwanted event to a different event target on that mouse position. -Martin On 06/09/2014 08:44 AM, Tom Eugelink wrote: Ye. It does not work on the canvas pane, I suspect because of the pickOnBounds, but it does work on the stackpane. Plus, I can register to the stack pane without claiming the onMouseClick/Press hook. Many thanks! Tom On 2014-6-9 8:29, Martin Sladecek wrote: Hi Tom, have you tried .addEventFilter() method? It receives the Event before the controls underneath the canvas, in the capturing phase. If you don't consume the Event, it should pass down to the controls. For more on the topic, see http://docs.oracle.com/javafx/2/events/processing.htm or http://parleys.com/play/514892290364bc17fc56c39f -Martin On 06/09/2014 08:19 AM, Tom Eugelink wrote: Hi all, Maybe someone has solved this already, so I thought I pop the question. Currently I'm working on CirclePopupMenu; a menu that is supposed to pop up on any place in a scene when a certain (usually the middle or right) mouse button is pressed. Right now CirclePopupMenu requires a stackpane to which it binds itself. CirclePopupMenu initially places an empty canvas Pane on the stack pane, and will use that to render and position the menu when it needs to appear. Also I need to monitor the mouse to detect if the menu should appear. In order to do that, I would like to use that canvas pane, but then any non relevant button clicks will not reach the underlying controls. In order to enable correct behavior I need to setPickOnBounds(false) on the pane, but then it does receive the mouse events anymore. Is there any way to monitor mouse events but still pass them through to the underlying controls? In Swing I did something similar and used a system level mouse event hook. Tom PS: I'm not certain if the stackpane approach I've used is the best way to do this. It does work expect the mouse button problem. But any suggestions are welcome.
Re: monitor mouse events but not capture them
Looking at PopupWindow; that is an abstract class and I'm not finding much
examples on how to use it. Maybe extending PopupControl would be a better
choice.
Been looking at the ContextMenu source code (which is extending PopupControl),
but it is somewhat mysterious how those MenuItems get rendered. I would expect
maybe a skin, but I'm not finding it.
On 2014-6-9 13:48, Tomas Mikula wrote:
Hi Tom,
I am in favor of the menu being a PopupWindow, but alternatively,
could your canvas be a Group instead of a Pane?
The code would look like this:
StackPane stack = new StackPane();
Group canvas = new Group();
canvas.setManaged(false);
stack.setOnMousePressed(e - {
// layout in the top left corner of the stack pane
canvas.setLayoutX(0);
canvas.setLayoutY(0);
stack.getChildren().add(canvas);
});
Regards,
Tomas
On Mon, Jun 9, 2014 at 11:01 AM, Tom Eugelink t...@tbee.org wrote:
But a PopupWindow would be detached from the pane? Not sure if that is what
I envision, but I'll give it a go and see what it looks like.
Your event filter does work though for what I need now.
Thanks!
On 2014-6-9 10:41, Martin Sladecek wrote:
Oh, I see. So it's not a PopupWindow at all.
Events can pass only though parent-child hierarchy, so you can't catch an
Event in your circular menu pane and then pass it to some other children
of the parent StackPane. The menu pane would have to be parent of the
controls in the StackPane.
So again, you'd need RT-20184 to determine the target again by temporarily
making the menu pane mouse transparent, doing Scene.pick and then
redirecting the Event by Event.fireEvent().
But I think reworking you menu to be a PopupWindow should work. The
transparent areas in the circular menu should pass mouse events to the
underlying window.
-Martin
On 06/09/2014 10:20 AM, Tom Eugelink wrote:
Or to see in in action with a single java -jar statement, download the
samples from.
http://jfxtras.org/
On 2014-6-9 10:13, Martin Sladecek wrote:
OK, so to avoid further confusion, you have a PopupWindow with a Pane
and you want to capture Events on the Pane and sent those events to the
underlying controls (in a parent window) if those events are not relevant to
that popup?
Thanks,
-Martin
On 06/09/2014 10:07 AM, Tom Eugelink wrote:
Hm, maybe I chose bad words; I'm not using Canvas, but just a Pane.
Since the Pane is only used to draw the menu on when it need to appear, I'm
calling it the canvas pane, as in what is painted on.
On 2014-6-9 9:46, Martin Sladecek wrote:
Just looked at the code and it seems Canvas does pick on bounds
independently of the pickOnBounds value. There's currently no logic for
picking only when over an opaque pixel ( worth filing a JIRA issue maybe?).
This makes Canvas to consume everything as it's always picked instead of
some controls underneath.
Unfortunately, I can't think of any solution that would work right
now. If we'd support Node picking
(https://javafx-jira.kenai.com/browse/RT-20184), it would be possible to
redirect an unwanted event to a different event target on that mouse
position.
-Martin
On 06/09/2014 08:44 AM, Tom Eugelink wrote:
Ye. It does not work on the canvas pane, I suspect because of the
pickOnBounds, but it does work on the stackpane. Plus, I can register to the
stack pane without claiming the onMouseClick/Press hook.
Many thanks!
Tom
On 2014-6-9 8:29, Martin Sladecek wrote:
Hi Tom,
have you tried .addEventFilter() method? It receives the Event
before the controls underneath the canvas, in the capturing phase. If you
don't consume the Event, it should pass down to the controls.
For more on the topic, see
http://docs.oracle.com/javafx/2/events/processing.htm or
http://parleys.com/play/514892290364bc17fc56c39f
-Martin
On 06/09/2014 08:19 AM, Tom Eugelink wrote:
Hi all,
Maybe someone has solved this already, so I thought I pop the
question. Currently I'm working on CirclePopupMenu; a menu that is supposed
to pop up on any place in a scene when a certain (usually the middle or
right) mouse button is pressed.
Right now CirclePopupMenu requires a stackpane to which it binds
itself. CirclePopupMenu initially places an empty canvas Pane on the stack
pane, and will use that to render and position the menu when it needs to
appear.
Also I need to monitor the mouse to detect if the menu should
appear. In order to do that, I would like to use that canvas pane, but then
any non relevant button clicks will not reach the underlying controls. In
order to enable correct behavior I need to setPickOnBounds(false) on the
pane, but then it does receive the mouse events anymore.
Is there any way to monitor mouse events but still pass them
through to the underlying controls? In Swing I did something similar and
used a system level mouse event hook.
Tom
PS: I'm not certain if the stackpane approach I've used is the best
way to do this. It does work expect the mouse button problem
Re: monitor mouse events but not capture them
Thanks for all the help, you've given me a lot of helpful tips. I already was
working on a popup based version and I see you ran into the same problems as I
did (initial popup had no width for the circularPane, etc), the difference is
that I bind the menu to Stage, since I do not envision CirclePopupMenu as a
context menu to a specific node. It could of course... Uncertain about that.
Anyhow, the only remaining problem is hiding when the mouse exits. Stage does
not send the mouse events to addEventFilter. The node.addEventFilter does not
solve that and on scene I'm not getting the events either. But I like the way
it is going.
Thanks!
Tom
On 2014-6-10 16:26, Tomas Mikula wrote:
Here it is, using a Popup:
https://github.com/TomasMikula/jfxtras-labs/blob/8.0/src/main/java/jfxtras/labs/scene/menu/CirclePopupMenu2.java
https://github.com/TomasMikula/jfxtras-labs/blob/8.0/src/main/java/jfxtras/labs/scene/menu/Sample2.java
The nice thing about popup window is that it can extend beyond the
bounds of the owner window.
Just let me know if transparency works for you as expected. Some time
ago transparency stopped working on my system and I didn't care to
find out why, so my Popup has white background instead of transparent,
but should be transparent on a healthy system.
On Tue, Jun 10, 2014 at 3:57 PM, Tomas Mikula tomas.mik...@gmail.com wrote:
Just because I wanted to make minimal changes to your code, which was
already using StackPane. Yes, Popup would remove the need for a
StackPane.
On Tue, Jun 10, 2014 at 3:52 PM, Tom Eugelink t...@tbee.org wrote:
You're way ahead of me. Why use stackpane and not popup as suggested?
Wouldn't Popup remove the need for a stackpane?
Tom
On 2014-6-10 15:38, Tomas Mikula wrote:
Since talk is cheap, I slightly reworked your code (not using
PopupWindow) and it seems to work.
CircularPopupMenu:
https://github.com/TomasMikula/jfxtras-labs/blob/8.0/src/main/java/jfxtras/labs/scene/menu/CirclePopupMenu1.java
Sample:
https://github.com/TomasMikula/jfxtras-labs/blob/8.0/src/main/java/jfxtras/labs/scene/menu/Sample1.java
Main points:
* No canvas pane used, CircularPane is added directly to the stack pane.
* CircularPane is added as the last child to the stack pane in order
to be on top.
* CircularPane is an unmanaged child of the stack pane, in order to
allow custom positioning (at mouse pointer)
* Since setPickOnBounds(false) causes the mouse exit the circular pane
as soon as it opens, there's slightly more logic to hide the menu
instead of just listening to MOUSE_EXITED events:
stackPane.addEventHandler(MouseEvent.MOUSE_MOVED, e - {
if(isShown()) {
Bounds localBounds = circularPane.getBoundsInLocal();
Bounds screenBounds = circularPane.localToScreen(localBounds);
if(!screenBounds.contains(e.getScreenX(), e.getScreenY())) {
hide();
}
}
});
Cheers,
Tomas
On Tue, Jun 10, 2014 at 1:45 PM, Tomas Mikula tomas.mik...@gmail.com
wrote:
What about using Popup, which is a subclass of PopupWindow? You just need
to
populate its content
popup.getContent().addAll(Node...);
and then show it at the right position, relative to any node
popup.show(canvas, x, y);
Tomas
On Jun 10, 2014 8:49 AM, Tom Eugelink t...@tbee.org wrote:
Looking at PopupWindow; that is an abstract class and I'm not finding
much
examples on how to use it. Maybe extending PopupControl would be a
better
choice.
Been looking at the ContextMenu source code (which is extending
PopupControl), but it is somewhat mysterious how those MenuItems get
rendered. I would expect maybe a skin, but I'm not finding it.
On 2014-6-9 13:48, Tomas Mikula wrote:
Hi Tom,
I am in favor of the menu being a PopupWindow, but alternatively,
could your canvas be a Group instead of a Pane?
The code would look like this:
StackPane stack = new StackPane();
Group canvas = new Group();
canvas.setManaged(false);
stack.setOnMousePressed(e - {
// layout in the top left corner of the stack pane
canvas.setLayoutX(0);
canvas.setLayoutY(0);
stack.getChildren().add(canvas);
});
Regards,
Tomas
On Mon, Jun 9, 2014 at 11:01 AM, Tom Eugelink t...@tbee.org wrote:
But a PopupWindow would be detached from the pane? Not sure if that is
what
I envision, but I'll give it a go and see what it looks like.
Your event filter does work though for what I need now.
Thanks!
On 2014-6-9 10:41, Martin Sladecek wrote:
Oh, I see. So it's not a PopupWindow at all.
Events can pass only though parent-child hierarchy, so you can't
catch
an
Event in your circular menu pane and then pass it to some other
children
of the parent StackPane. The menu pane would have to be parent of the
controls in the StackPane.
So again, you'd need RT-20184 to determine the target again by
temporarily
making the menu pane mouse transparent, doing Scene.pick and then
redirecting
Re: monitor mouse events but not capture them
My internet provider has problems sending to GMail addresses.
For me it worked to register to scene.getRoot().
I like registering to a node, because it allows to install different menu's to
different nodes, but still do the most common approach of install a single menu
to the top level pane.
Your code already uses addEventHandler, I adopted that.
Tom
On 2014-6-10 19:07, Tomas Mikula wrote:
Somehow I didn't get your previous email that you are quoting now.
Listening to MOUSE_MOVED events on the Scene seemed to work for me.
Didn't it work for you? You may as well install the menu to a Scene
instead of a Node. That will also simplify listening to scene's
events, because you don't have to worry about the case when the node
is not yet attached to the scene (when node.getScene() returns null).
By the way, you should probably use addEventHandler instead of
addEventFilter, to allow child nodes to consume the event if they want
to override the right click.
Tomas
On Tue, Jun 10, 2014 at 6:50 PM, Tom Eugelink t...@tbee.org wrote:
Ah, attaching to Node is a good idea after all!
Tom
On 2014-6-10 17:44, Tom Eugelink wrote:
Thanks for all the help, you've given me a lot of helpful tips. I already
was working on a popup based version and I see you ran into the same
problems as I did (initial popup had no width for the circularPane, etc),
the difference is that I bind the menu to Stage, since I do not envision
CirclePopupMenu as a context menu to a specific node. It could of course...
Uncertain about that.
Anyhow, the only remaining problem is hiding when the mouse exits. Stage
does not send the mouse events to addEventFilter. The node.addEventFilter
does not solve that and on scene I'm not getting the events either. But I
like the way it is going.
Thanks!
Tom
On 2014-6-10 16:26, Tomas Mikula wrote:
Here it is, using a Popup:
https://github.com/TomasMikula/jfxtras-labs/blob/8.0/src/main/java/jfxtras/labs/scene/menu/CirclePopupMenu2.java
https://github.com/TomasMikula/jfxtras-labs/blob/8.0/src/main/java/jfxtras/labs/scene/menu/Sample2.java
The nice thing about popup window is that it can extend beyond the
bounds of the owner window.
Just let me know if transparency works for you as expected. Some time
ago transparency stopped working on my system and I didn't care to
find out why, so my Popup has white background instead of transparent,
but should be transparent on a healthy system.
On Tue, Jun 10, 2014 at 3:57 PM, Tomas Mikula tomas.mik...@gmail.com
wrote:
Just because I wanted to make minimal changes to your code, which was
already using StackPane. Yes, Popup would remove the need for a
StackPane.
On Tue, Jun 10, 2014 at 3:52 PM, Tom Eugelink t...@tbee.org wrote:
You're way ahead of me. Why use stackpane and not popup as suggested?
Wouldn't Popup remove the need for a stackpane?
Tom
On 2014-6-10 15:38, Tomas Mikula wrote:
Since talk is cheap, I slightly reworked your code (not using
PopupWindow) and it seems to work.
CircularPopupMenu:
https://github.com/TomasMikula/jfxtras-labs/blob/8.0/src/main/java/jfxtras/labs/scene/menu/CirclePopupMenu1.java
Sample:
https://github.com/TomasMikula/jfxtras-labs/blob/8.0/src/main/java/jfxtras/labs/scene/menu/Sample1.java
Main points:
* No canvas pane used, CircularPane is added directly to the stack
pane.
* CircularPane is added as the last child to the stack pane in order
to be on top.
* CircularPane is an unmanaged child of the stack pane, in order to
allow custom positioning (at mouse pointer)
* Since setPickOnBounds(false) causes the mouse exit the circular pane
as soon as it opens, there's slightly more logic to hide the menu
instead of just listening to MOUSE_EXITED events:
stackPane.addEventHandler(MouseEvent.MOUSE_MOVED, e - {
if(isShown()) {
Bounds localBounds = circularPane.getBoundsInLocal();
Bounds screenBounds =
circularPane.localToScreen(localBounds);
if(!screenBounds.contains(e.getScreenX(),
e.getScreenY())) {
hide();
}
}
});
Cheers,
Tomas
On Tue, Jun 10, 2014 at 1:45 PM, Tomas Mikula tomas.mik...@gmail.com
wrote:
What about using Popup, which is a subclass of PopupWindow? You just
need
to
populate its content
popup.getContent().addAll(Node...);
and then show it at the right position, relative to any node
popup.show(canvas, x, y);
Tomas
On Jun 10, 2014 8:49 AM, Tom Eugelink t...@tbee.org wrote:
Looking at PopupWindow; that is an abstract class and I'm not
finding
much
examples on how to use it. Maybe extending PopupControl would be a
better
choice.
Been looking at the ContextMenu source code (which is extending
PopupControl), but it is somewhat mysterious how those MenuItems get
rendered. I would expect maybe a skin, but I'm not finding it.
On 2014-6-9 13:48, Tomas Mikula wrote:
Hi Tom,
I am in favor of the menu being a PopupWindow, but alternatively,
could your canvas be a Group instead
Re: monitor mouse events but not capture them
Placed a new version in GIT, tests are green as well. I'm quite pleased with the improvements. Going to take a peek at CornerMenu to see if it makes sense to refactor it also. Tom
Re: Blurry strokes and zooming via scale transforms
I recently had a similar situation, but then because certain properties were calculated-via-binding and the resulting value was not snapped to good values either. This resulted in my suggestion to allow custom calculations in bindings, which would then snap the value. https://javafx-jira.kenai.com/browse/RT-37255 And transformations on such values have the same effect of course. I was wondering, similar to the binding suggestion, would it be possible to apply a snapping transformation as the last transformation? Tom On 2014-6-12 10:56, Robert Fisher wrote: Hi all, I'm trying to avoid the blurry strokes you can get in JavaFX in some cases, e.g. for a non-integer stroke width, or a stroke width of 1 and StrokeType.CENTERED. So far my 'solution' to this problem has been to round layout values to integers, or to round and add 0.5 in the StrokeType.CENTERED case. However this approach is pretty useless if I apply a scale transform afterwards, which is the simplest way I know to create a zooming mechanism. So my question is: is there any way I can round things to integer values *after* transforms have been applied? Or tell the renderer to not try to approximate strokes drawn 'off-pixel' but instead to round move them to the nearest pixel so that lines look sharp and clean? Any tips would be appreciated. Cheers, Rob
8u40 9 CSS issues
Has anything changed in 8U40 and J9 concerning CSS processing? I'm using SVG and images in CSS to draw a.o. arrows. These are not visible in 8U40 and 9. But 8u20 and J8 they work fine. And clues where to look? Tom
Re: 8u40 9 CSS issues
Thanks. Will see what problems he has. On 8-10-2014 21:07, Mark Heckler wrote: Tom, David, Sounds similar to (but not the same as) an issue Rob Terpilowski (@RobTerpilowski) mentioned yesterday on Twitter and that Gerrit Grunwald corroborated. I believe Rob is logging an issue as well, may want to see if the issues are at all related and coordinate. HTH, Mark -Original Message- From: David Grieve Sent: Wednesday, October 08, 2014 12:22 PM To: openjfx-dev@openjdk.java.net Subject: Re: 8u40 9 CSS issues If it worked in 8u20 but not in 8u40, then there is a regression somewhere. Please file an issue in jira and include a reproducible example. On 10/8/14, 12:08 PM, Tom Eugelink wrote: Has anything changed in 8U40 and J9 concerning CSS processing? I'm using SVG and images in CSS to draw a.o. arrows. These are not visible in 8U40 and 9. But 8u20 and J8 they work fine. And clues where to look? Tom
Re: CSS: style leaks from unrelated stylesheet
My controls in JFXtras have been overriding getUserAgentStylesheet from day 1
(or better JavaFX 2.0), AFAIK that is the way to do it. But I'm curious if this
change is the cause of the CSS issues I'm seeing in 8U40.
On 9-10-2014 15:27, David Grieve wrote:
In 8u20 and before, adding a stylesheet via Control.getUserAgentStylesheet will
simply add the user-agent stylesheet to the entire scene, not just the control.
This has been fixed in 8u40 where the getUserAgentStylesheet method is now
public API on Region and the styles added will affect only the Region and its
children.
Incidentally, the code you point out from the 3rd party control (controlsfx)
was added as a work-around for a separate issue related to
Control.getUserAgentStylesheet(). I believe the 8u40 branch of controlsfx has
removed this work-around and is using the Region#getUserAgentStylesheet method.
On 10/9/14, 8:58 AM, Werner Lehmann wrote:
Turns out that the 3rd party control adds its stylesheet like this:
class SomeControlSkin...
static {
StyleManager.getInstance().addUserAgentStylesheet(...)
}
In this way it is not only using private API but also the stylesheet is not
associated with only such control nodes and therefore seems to affect other
nodes, too. Is this correct, and should the stylesheet rather be provided by
overriding Control.getUserAgentStylesheet?
Werner
On 09.10.2014 12:00, Werner Lehmann wrote:
Then a dialog stage is displayed and its scene does not use the 3rd
party control. However, a combobox list-cell (its button cell) is still
Re: CSS warning
I understand and see the merrits of special handling so that the engine prevents leaking. OTOH, special handling always is extra overhead, and I know how careful the JavaFX team weighs any additional performance hit, so the question remains if the engine should have a special handling or the CSS should have selectors that prevent leaking. You could, for example, have the CSS parser add an generated class to all the control's CSS rules, and also add that class to the control (basically what I have done explicitely). In this way the CSS engine does not need special handling, but uses the existing selector logic to prevent leaking. Anywho, my concern was placed on the table, I do not have enough knowledge of the CSS engine to argue the finer details. Tom On 21-10-2014 19:20, David Grieve wrote: On 10/21/14, 1:09 PM, Tom Eugelink wrote: That makes sense :-) I've tested it under 8U40, took some hacking because of the other CSS problems with the only affects the control, but it indeed seems to not be a problem anymore. About this only affects the control; are you sure you want to add special CSS handling for controls in the code, instead of making sure that the CSS only applies to the correct nodes by better using CSS selectors? It seems to me CSS classes are a perfect mechanism for this. HTML engines don't have special CSS handling for divs or imgs or ... Yes, I'm sure. Keep in mind that the stylesheet returned by getUserAgentStylesheet() is treated as a user-agent stylesheet for the purpose of the cascade. I would argue, however, that you don't want styles from some third party control leaking into other parts of your application. What the special handling does is allow css to be bundled with some control and for the control to be dropped into a scene-graph without affecting the rest of the application. Tom On 21-10-2014 16:19, David Grieve wrote: JavaFX CSS has a 'lookup' feature that allows you to declare the value of a property as another property. For example, the -fx-base property defines the base color of the modena theme (the same goes for caspian). When a css value is calculated, these looked-up properties have to be resolved to a real value. The code looks for matching styles starting with the current node and going up the parent chain to the root of the scene-graph until it finds a value that doesn't need to be further resolved. If the value isn't resolved, then this message is printed out. Resolving a lookup value is dependent on a node's parents having already been processed by CSS. If, for example, -fx-base is in .root and the root of the scene-graph hasn't been processed by CSS, the root node will not have any styles and the lookup will fail. The CSS code tries to ensure that CSS is always processed from the root down and also tries to ensure that the CSS state of parent nodes is not dirty when CSS is processed on a child node. When new styles are added to the scene-graph, from adding a stylesheet to the scene or adding a user-agent stylesheet, CSS is reapplied to the scene-graph. This means that all the matching styles and calculated values are thrown away and re-evaluated from scratch. In 8u20, adding a stylesheet to a control via the Control method getUserAgentStylesheet() will cause this to happen. So I think what is happening here is that the getUserAgentStylesheet() call happens in the middle of CSS being processed on the Control; thus, the CSS for the parent nodes of the control will all be tossed out and the lookups will fail. This all settles out in the next CSS pass, which is why you don't see an issue with the look. There was some work done in 8u40 improve the handling of reapplying CSS. There were also some changes to getUserAgentStylesheet() so that it only affects the control and not the whole scene-graph. Try 8u40 and see if that doesn't help. If you still get these warnings on 8u40, then please create a bug in jira. On 10/21/14, 2:10 AM, Tom Eugelink wrote: Has anyone every figured out what the cause is of these CSS warnings I get? They do not seem to influence the look at all, and since I copied the styling from moderna.css, they do not seem to be valid either. I suspect it may have to do with a different handling of CSS and that I cannot reuse stuff defined in moderna? Because if I take the first error; -fx-focus-color is defined in moderna.css. Tom okt 21, 2014 8:02:42 AM javafx.scene.CssStyleHelper calculateValue WARNING: Could not resolve '-fx-focus-color' while resolving lookups for '-fx-background-color' from rule '*.ListSpinnerSkin' in stylesheet file:/C:/Users/user/Documents/jfxtras/jfxtras-controls/_build/jfxtras/internal/scene/control/ListSpinner.css okt 21, 2014 8:02:42 AM javafx.scene.CssStyleHelper calculateValue WARNING: Could not resolve '-fx-text-background-color' while resolving lookups for '-fx-text-fill' from rule '*.label' in stylesheet jar:file:/C:/Program%20Files%20(x86)/Java
Re: Java 8 not supporting Windows XP
Java 8 is not supported on WindowsXP, so installing will not work. You can try copying an installed JDK or JRE directory from a Windows 7 or 8 system and see if it runs; I had problems with that, but some say it can work. Tom On 27-10-2014 10:30, Nada Milosavljevic wrote: I have problem to ibstall java 8,plz help me. Respect, Nada Milosavljevic
Re: Monocle in 8u25
This is extremely good news. I have no problem to drag that library along in the JFXtras project (project name seems to be a good match for this usage ;-) and release it to maven - if that is allowed by the JavaFX license. Tom On 5-11-2014 16:57, Benjamin Gudehus wrote: Hi Sean, I've put the Monocle sources directly in my code directories for testing purposes. Putting it into a separate Jar is possible and I thought that pre-compiled jars could be provided via Maven. I didn't do a complete OpenJFX build, because I was only interested in the Headless component of Monocle, i.e. I didn't needed the platform-dependent dynamic libraries. Rough instructions were given in a previous mail. There were some request to provide the pre-compoile jars so I will additionally set up a public repository with detailed instructions when I'm back home. --Benjamin On 11/5/14, Sean True sean.t...@gmail.com wrote: Did you build the glass/ui/monocle sources into a separate jar, or did you do a complete OpenJFX build? If you did a separate build, a recipe would be extremely helpful. -- Sean On Tue, Nov 4, 2014 at 6:17 PM, Benjamin Gudehus hasteb...@gmail.com wrote: I managed to run Monocle/Headless on Windows with 8u25. This will allow users to run headless tests. All what is needed is to copy all files from com/sun/glass/ui/monocle of javafx-src.zip and add the cursor resource files from modules/graphics/src/main/resources/com/sun/glass/ui/monocle of the related hg tag in the OpenJFX repository [1]. Before Application#launch() is called we need to manually set the Glass and Monocle platforms: accessStaticField(com.sun.glass.ui.PlatformFactory.class, instance, new com.sun.glass.ui.monocle.MonoclePlatformFactory()); accessStaticField(com.sun.glass.ui.monocle.NativePlatformFactory.class, platform, new com.sun.glass.ui.monocle.headless.HeadlessPlatform()); The directory structure in 8u40 is a bit different, but there could be added version checks. Checking for the JVM vars glass.platform and monocle.platform might be also added to this code. [1] http://hg.openjdk.java.net/openjfx/8u-dev/rt/tags On Tue, Nov 4, 2014 at 8:42 PM, Benjamin Gudehus hasteb...@gmail.com wrote: Hmm. Seems that Class.forName() in com.sun.glass.ui.PlatformFactory won't retrieve externally defined PlatformFactorys. So I will try to set the PlatformFactory.instance field manually, before the Application/Tookit/FX-Thread is launched. On Tue, Nov 4, 2014 at 7:36 PM, Benjamin Gudehus hasteb...@gmail.com wrote: Thank you. That makes it clearer. :) Is it possible to supply the headless part of Monocle in an external Jar for desktop platforms? As far as I know the only possibility to run TestFX tests with Hudson/Jenkins is in headless mode. TestFX's tests itself can only run with the X virtual framebuffer on Linux test clients for the Travis CI so far. So far the only advice I could give TestFX users who like to run headless tests is to use 1.8.0_20-ea-b05.
off topic: LocalDate
I'm trying to do some refactoring on the Agenda control; its skin class is quite large. I figured I also switch to use the new Java 8 date time API, because it is much easier than Calendar. At least... That is what I expect after using JodaTime a lot in my projects. But, ah, does anyone know how we got from JodaTime's localDate.toDate() to Java 8's Date.from(localDate.atZone(ZoneId.systemDefault()).toInstant())???
Re: off topic: LocalDate
Starting point is a LocalDate. On 9-11-2014 08:29, oma...@free.fr wrote: Date date = Date.from(Instant.now()); - Mail original - De: Tom Eugelink t...@tbee.org À: openjfx-dev@openjdk.java.net Envoyé: Vendredi 7 Novembre 2014 22:49:01 Objet: off topic: LocalDate I'm trying to do some refactoring on the Agenda control; its skin class is quite large. I figured I also switch to use the new Java 8 date time API, because it is much easier than Calendar. At least... That is what I expect after using JodaTime a lot in my projects. But, ah, does anyone know how we got from JodaTime's localDate.toDate() to Java 8's Date.from(localDate.atZone(ZoneId.systemDefault()).toInstant())???
Re: Monocle in 8u25
I've build the jars from the sources in github (this makes creating new
releases easier) and the artifacts are on their way to Maven Central... If
everything seems to be ok, I'll create a pull request with some changes to
gradle.build for the releasing process.
Tom
On 12-11-2014 09:09, Benjamin Gudehus wrote:
That would be nice, Tom.
Example usage:
Since com.sun.glass.ui.PlatformFactory can't find Monocle classes from the
external jars, we need to change
public static void main(String[] appArgs) {
Application.launch(appClass, appArgs);
}
to
public static void main(String[] appArgs) {
new ToolkitApplicationLauncher().launch(appClass, appArgs);
}
and start the Application with -Djavafx.monocle.headless=true.
ToolkitApplicationLauncher.jar:
https://gist.github.com/hastebrot/cbca1128dd791966e3a6
On Wed, Nov 12, 2014 at 8:48 AM, Tom Eugelink t...@tbee.org
mailto:t...@tbee.org wrote:
I can roll it out under the same name (openjfx-monocle-1.8.0_20) within the
org.jfxtras group. Just say so.
Tom
On 12-11-2014 08:30, Benjamin Gudehus wrote:
Hi all!
Files and instructions are available at https://github.com/TestFX/Monocle.
Releases with jars: https://github.com/TestFX/Monocle/releases
License (taken from OpenJFX respository):
https://github.com/TestFX/Monocle/blob/master/LICENSE
Would be nice to have this available from Maven.
--Benjamin
On Wed, Nov 5, 2014 at 8:20 PM, Tom Eugelink t...@tbee.org
mailto:t...@tbee.org wrote:
This is extremely good news. I have no problem to drag that library
along in the JFXtras project (project name seems to be a good match for this usage ;-)
and release it to maven - if that is allowed by the JavaFX license.
Tom
On 5-11-2014 16:57, Benjamin Gudehus wrote:
Hi Sean,
I've put the Monocle sources directly in my code directories for
testing purposes. Putting it into a separate Jar is possible and I
thought that pre-compiled jars could be provided via Maven.
I didn't do a complete OpenJFX build, because I was only interested
in
the Headless component of Monocle, i.e. I didn't needed the
platform-dependent dynamic libraries.
Rough instructions were given in a previous mail. There were some
request to provide the pre-compoile jars so I will additionally set
up
a public repository with detailed instructions when I'm back home.
--Benjamin
On 11/5/14, Sean True sean.t...@gmail.com
mailto:sean.t...@gmail.com wrote:
Did you build the glass/ui/monocle sources into a separate jar,
or did you
do a complete OpenJFX build?
If you did a separate build, a recipe would be extremely
helpful.
-- Sean
On Tue, Nov 4, 2014 at 6:17 PM, Benjamin Gudehus hasteb...@gmail.com
mailto:hasteb...@gmail.com
wrote:
I managed to run Monocle/Headless on Windows with 8u25.
This will allow
users to run headless tests.
All what is needed is to copy all files from
com/sun/glass/ui/monocle
of
javafx-src.zip and add the
cursor resource files from
modules/graphics/src/main/resources/com/sun/glass/ui/monocle of the
related hg tag in the OpenJFX repository [1].
Before Application#launch() is called we need to manually
set the Glass
and
Monocle platforms:
accessStaticField(com.sun.glass.ui.PlatformFactory.class,
instance,
new com.sun.glass.ui.monocle.MonoclePlatformFactory());
accessStaticField(com.sun.glass.ui.monocle.NativePlatformFactory.class,
platform,
new
com.sun.glass.ui.monocle.headless.HeadlessPlatform());
The directory structure in 8u40 is a bit different, but
there could be
added version checks. Checking
for the JVM vars glass.platform and monocle.platform
might be also
added to this code.
[1] http://hg.openjdk.java.net/openjfx/8u-dev/rt/tags
On Tue, Nov 4, 2014 at 8:42 PM, Benjamin Gudehus
hasteb...@gmail.com mailto:hasteb...@gmail.com
wrote:
Hmm. Seems that Class.forName() in
com.sun.glass.ui.PlatformFactory
won't
retrieve externally defined PlatformFactorys. So I will
try to set the
PlatformFactory.instance field manually, before the
Application/Tookit/FX-Thread is launched.
On Tue, Nov 4, 2014 at 7:36 PM, Benjamin Gudehus
Re: Monocle in 8u25
org.jftras:openjfx-monicle:1.8.0_20 is available in Maven central.
Tom
On 12-11-2014 09:09, Benjamin Gudehus wrote:
That would be nice, Tom.
Example usage:
Since com.sun.glass.ui.PlatformFactory can't find Monocle classes from the
external jars, we need to change
public static void main(String[] appArgs) {
Application.launch(appClass, appArgs);
}
to
public static void main(String[] appArgs) {
new ToolkitApplicationLauncher().launch(appClass, appArgs);
}
and start the Application with -Djavafx.monocle.headless=true.
ToolkitApplicationLauncher.jar:
https://gist.github.com/hastebrot/cbca1128dd791966e3a6
On Wed, Nov 12, 2014 at 8:48 AM, Tom Eugelink t...@tbee.org
mailto:t...@tbee.org wrote:
I can roll it out under the same name (openjfx-monocle-1.8.0_20) within the
org.jfxtras group. Just say so.
Tom
On 12-11-2014 08:30, Benjamin Gudehus wrote:
Hi all!
Files and instructions are available at https://github.com/TestFX/Monocle.
Releases with jars: https://github.com/TestFX/Monocle/releases
License (taken from OpenJFX respository):
https://github.com/TestFX/Monocle/blob/master/LICENSE
Would be nice to have this available from Maven.
--Benjamin
On Wed, Nov 5, 2014 at 8:20 PM, Tom Eugelink t...@tbee.org
mailto:t...@tbee.org wrote:
This is extremely good news. I have no problem to drag that library
along in the JFXtras project (project name seems to be a good match for this usage ;-)
and release it to maven - if that is allowed by the JavaFX license.
Tom
On 5-11-2014 16:57, Benjamin Gudehus wrote:
Hi Sean,
I've put the Monocle sources directly in my code directories for
testing purposes. Putting it into a separate Jar is possible and I
thought that pre-compiled jars could be provided via Maven.
I didn't do a complete OpenJFX build, because I was only interested
in
the Headless component of Monocle, i.e. I didn't needed the
platform-dependent dynamic libraries.
Rough instructions were given in a previous mail. There were some
request to provide the pre-compoile jars so I will additionally set
up
a public repository with detailed instructions when I'm back home.
--Benjamin
On 11/5/14, Sean True sean.t...@gmail.com
mailto:sean.t...@gmail.com wrote:
Did you build the glass/ui/monocle sources into a separate jar,
or did you
do a complete OpenJFX build?
If you did a separate build, a recipe would be extremely
helpful.
-- Sean
On Tue, Nov 4, 2014 at 6:17 PM, Benjamin Gudehus hasteb...@gmail.com
mailto:hasteb...@gmail.com
wrote:
I managed to run Monocle/Headless on Windows with 8u25.
This will allow
users to run headless tests.
All what is needed is to copy all files from
com/sun/glass/ui/monocle
of
javafx-src.zip and add the
cursor resource files from
modules/graphics/src/main/resources/com/sun/glass/ui/monocle of the
related hg tag in the OpenJFX repository [1].
Before Application#launch() is called we need to manually
set the Glass
and
Monocle platforms:
accessStaticField(com.sun.glass.ui.PlatformFactory.class,
instance,
new com.sun.glass.ui.monocle.MonoclePlatformFactory());
accessStaticField(com.sun.glass.ui.monocle.NativePlatformFactory.class,
platform,
new
com.sun.glass.ui.monocle.headless.HeadlessPlatform());
The directory structure in 8u40 is a bit different, but
there could be
added version checks. Checking
for the JVM vars glass.platform and monocle.platform
might be also
added to this code.
[1] http://hg.openjdk.java.net/openjfx/8u-dev/rt/tags
On Tue, Nov 4, 2014 at 8:42 PM, Benjamin Gudehus
hasteb...@gmail.com mailto:hasteb...@gmail.com
wrote:
Hmm. Seems that Class.forName() in
com.sun.glass.ui.PlatformFactory
won't
retrieve externally defined PlatformFactorys. So I will
try to set the
PlatformFactory.instance field manually, before the
Application/Tookit/FX-Thread is launched.
On Tue, Nov 4, 2014 at 7:36 PM, Benjamin Gudehus
hasteb...@gmail.com mailto:hasteb...@gmail.com
wrote:
Thank you. That makes it clearer. :)
Is it possible to supply
Re: Monocle in 8u25
A developer is mandatory, your name is as good as any?
Tom
On 13-11-2014 22:06, Benjamin Gudehus wrote:
@Tom Thanks for the patch. Will apply it soon.
Is there something like a package maintainer field for Maven? I think
developer is a bit too pompous; I didn't touch the code.
On Thu, Nov 13, 2014 at 10:01 PM, Benjamin Gudehus hasteb...@gmail.com
wrote:
Hi Neil!
The TestFX library is still moving the Windows mouse!
TestFX is using Awt's robot. This robot ignores Glass/Monocle and controls
the OS's cursor.
We need to replace it with Glass' robot. I already tested it and it works
fine.
PR will be ready soon. This PR will also replace the Awt screenshot
mechanism with the one
from the Glass robot. I hoped that this will also take screenshots wenn
running in headless mode.
But unfortunately the screenshots were empty. I saw in Monocle's source
code, that it writes
color values into an internal byte stream, so it actually should work.
Also very nice to see, that people are using bleeding edge version of
TestFX. :)
TestFX will also have better Spock/Groovy support in the future.
--Benjamin
On Thu, Nov 13, 2014 at 9:38 PM, ngalarn...@abinitio.com wrote:
Hi Benjamin,
We are using Spock for testing, and have modified the setupStage() method
to support optional headless testing with Monocle,
which is working well on Windows (the code is in groovy):
void setupStage(Closurejavafx.scene.Node rootNodeFactory)
{
if (fx == null isHeadless)
{
// Cribbed from:
https://gist.github.com/hastebrot/cbca1128dd791966e3a6
PlatformFactory.instance = new MonoclePlatformFactory()
NativePlatformFactory.platform = new HeadlessPlatform()
}
fx = new GuiTest()
fx.rootNodeFactory = rootNodeFactory
fx.setupGuiTest()
}
It works nicely until fx.clickOn is called. The TestFX library is still
moving the Windows mouse!
Any thoughts?
Thanks,
Neil
From:Benjamin Gudehus hasteb...@gmail.com
To:Tom Eugelink t...@tbee.org,
Cc:openjfx-dev@openjdk.java.net openjfx-dev@openjdk.java.net
Date:11/12/2014 03:10 AM
Subject:Re: Monocle in 8u25
Sent by:openjfx-dev openjfx-dev-boun...@openjdk.java.net
--
That would be nice, Tom.
Example usage:
Since com.sun.glass.ui.PlatformFactory can't find Monocle classes from the
external jars, we need to change
public static void main(String[] appArgs) {
Application.launch(appClass, appArgs);
}
to
public static void main(String[] appArgs) {
new ToolkitApplicationLauncher().launch(appClass, appArgs);
}
and start the Application with -Djavafx.monocle.headless=true.
ToolkitApplicationLauncher.jar:
https://gist.github.com/hastebrot/cbca1128dd791966e3a6
On Wed, Nov 12, 2014 at 8:48 AM, Tom Eugelink t...@tbee.org wrote:
I can roll it out under the same name (openjfx-monocle-1.8.0_20) within
the org.jfxtras group. Just say so.
Tom
On 12-11-2014 08:30, Benjamin Gudehus wrote:
Hi all!
Files and instructions are available at
https://github.com/TestFX/Monocle
.
Releases with jars: https://github.com/TestFX/Monocle/releases
License (taken from OpenJFX respository):
https://github.com/TestFX/Monocle/blob/master/LICENSE
Would be nice to have this available from Maven.
--Benjamin
On Wed, Nov 5, 2014 at 8:20 PM, Tom Eugelink t...@tbee.org wrote:
This is extremely good news. I have no problem to drag that library
along in the JFXtras project (project name seems to be a good match for
this usage ;-) and release it to maven - if that is allowed by the
JavaFX
license.
Tom
On 5-11-2014 16:57, Benjamin Gudehus wrote:
Hi Sean,
I've put the Monocle sources directly in my code directories for
testing purposes. Putting it into a separate Jar is possible and I
thought that pre-compiled jars could be provided via Maven.
I didn't do a complete OpenJFX build, because I was only interested in
the Headless component of Monocle, i.e. I didn't needed the
platform-dependent dynamic libraries.
Rough instructions were given in a previous mail. There were some
request to provide the pre-compoile jars so I will additionally set up
a public repository with detailed instructions when I'm back home.
--Benjamin
On 11/5/14, Sean True sean.t...@gmail.com wrote:
Did you build the glass/ui/monocle sources into a separate jar, or
did
you
do a complete OpenJFX build?
If you did a separate build, a recipe would be extremely helpful.
-- Sean
On Tue, Nov 4, 2014 at 6:17 PM, Benjamin Gudehus
hasteb...@gmail.com
wrote:
I managed to run Monocle/Headless on Windows with 8u25. This will
allow
users to run headless tests.
All what is needed is to copy all files from
com/sun/glass/ui/monocle
of
javafx-src.zip and add the
cursor resource files from
modules/graphics/src/main/resources/com/sun/glass/ui/monocle of
the
related hg tag in the OpenJFX repository [1].
Before Application#launch() is called we need to manually set the
Glass
Re: What Scene Builder needs YESTERDAY!
I do not think that JavaFX is aiming at replacing flash, HTML and javascript are doing a great job there, hence animations are not equally important as they were for flash. Tom On 24-11-2014 10:46, Felix Bembrick wrote: I am surprised more people have not expressed an opinion on this. To me, it seems absolutely *vital* to the long term (or any term) success of JavaFX. Haven't any of you ever programmed in Flash? Can you imagine trying to create any of those complex (or even the simple) animations and visualisations *without* a visual editor and by doing it code alone? It wouldn't have been practical (read possible) and similarly, and with JavaFX having even richer features, to do this by hand. To me, this is the reason why we haven't seen any great animations/visualisations/applications using JavaFX and we probably never will until a visual animation editor is available. Specifying and controlling the motion and appearance of numerous complex objects and their transitions relying exclusively on code would not be possible for even the gunnest JFX coder... On 18 November 2014 at 02:48, Richard Bair richard.b...@oracle.com wrote: I’m afraid at this time there are no plans for adding an animation/transition effect editor to Scene Builder, certainly not in the short-term. Thanks Richard On Nov 13, 2014, at 7:34 PM, Felix Bembrick felix.bembr...@gmail.com wrote: Java applets were the first programs to run inside a web browser and for a (little) while they were flavour of the month. But then along came Flash which had several advantages such as faster load times, consistent loads and antialiased fonts/graphics and soon completely surpassed applets. But the MAIN reason why Flash was initially so successful and went on for years and years of domination is that the Flash tools had an Animation/Timeline Editor pretty much from the beginning. This enabled even a novice to drag images around and draw the path they wanted them to move along, add all sorts of bouncing effects and sounds and the result was the birth of the online greeting card company. But Flash soon went on to be so much more. As the Adobe tools improved, so did the SWFs and soon entire websites were written in Flash. Meanwhile, applet programmers had absolutely nothing remotely similar and had to try (and I stress try) to tediously hand code any animations and transitions and effects and I don't think it ever worked. Fast forward 15-20 years and now we have JavaFX which doesn't need to run in the browser, has even more features than Flash, uses hardware acceleration for superior performance, has a wide range of built-in animations, transitions and effects but STILL we have to hand code any animation/transitions. This is INCREDIBLY inefficient and unless Scene Builder incorporates a powerful, sophisticated animation/transition and effect editor VERY, VERY SOON I fear that the advanced graphics features are never going to be used to their full potential (much to the detriment of JavaFX itself). Does anyone know if one is in the pipeline? I see this as one of the most vital features for the JavaFX ecosystem to achieve more penetration and, eventually, survive. Felix
Re: What Scene Builder needs YESTERDAY!
I have no problems using JavaFX's animations for my purposes, which are decorative effects. I do not need an editor for that, forced me to use it and it probably will even get in my way. Which BTW was the case with the Flash coding that I have done; I hated that Flash EDI, it was way too much focussed on animation. Actually that is why Adobe created Flex, which basically was flash-for-developers (instead of animators). JavaFX is more a alternative for Flex than Flash. Tom On 24-11-2014 11:20, Felix Bembrick wrote: Really? My point is, why have such good built-on classes to support the building of everything from simple animations to complex visualisations if it is practically impossible to do so? On 24 November 2014 at 21:02, Tom Eugelink t...@tbee.org mailto:t...@tbee.org wrote: I do not think that JavaFX is aiming at replacing flash, HTML and javascript are doing a great job there, hence animations are not equally important as they were for flash. Tom On 24-11-2014 10:46, Felix Bembrick wrote: I am surprised more people have not expressed an opinion on this. To me, it seems absolutely *vital* to the long term (or any term) success of JavaFX. Haven't any of you ever programmed in Flash? Can you imagine trying to create any of those complex (or even the simple) animations and visualisations *without* a visual editor and by doing it code alone? It wouldn't have been practical (read possible) and similarly, and with JavaFX having even richer features, to do this by hand. To me, this is the reason why we haven't seen any great animations/visualisations/applications using JavaFX and we probably never will until a visual animation editor is available. Specifying and controlling the motion and appearance of numerous complex objects and their transitions relying exclusively on code would not be possible for even the gunnest JFX coder... On 18 November 2014 at 02:48, Richard Bair richard.b...@oracle.com mailto:richard.b...@oracle.com wrote: I’m afraid at this time there are no plans for adding an animation/transition effect editor to Scene Builder, certainly not in the short-term. Thanks Richard On Nov 13, 2014, at 7:34 PM, Felix Bembrick felix.bembr...@gmail.com mailto:felix.bembr...@gmail.com wrote: Java applets were the first programs to run inside a web browser and for a (little) while they were flavour of the month. But then along came Flash which had several advantages such as faster load times, consistent loads and antialiased fonts/graphics and soon completely surpassed applets. But the MAIN reason why Flash was initially so successful and went on for years and years of domination is that the Flash tools had an Animation/Timeline Editor pretty much from the beginning. This enabled even a novice to drag images around and draw the path they wanted them to move along, add all sorts of bouncing effects and sounds and the result was the birth of the online greeting card company. But Flash soon went on to be so much more. As the Adobe tools improved, so did the SWFs and soon entire websites were written in Flash. Meanwhile, applet programmers had absolutely nothing remotely similar and had to try (and I stress try) to tediously hand code any animations and transitions and effects and I don't think it ever worked. Fast forward 15-20 years and now we have JavaFX which doesn't need to run in the browser, has even more features than Flash, uses hardware acceleration for superior performance, has a wide range of built-in animations, transitions and effects but STILL we have to hand code any animation/transitions. This is INCREDIBLY inefficient and unless Scene Builder incorporates a powerful, sophisticated animation/transition and effect editor VERY, VERY SOON I fear that the advanced graphics features are never going to be used to their full potential (much to the detriment of JavaFX itself). Does anyone know if one is in the pipeline? I see this as one of the most vital features for the JavaFX ecosystem to achieve more penetration and, eventually, survive. Felix
Re: What Scene Builder needs YESTERDAY!
Oh, you are right, if the JavaFX team does not need to make choices on where to invest their precious time, then all possible usages could be implemented immediately. Unfortunately they too have to place priorities and then the most likely usage will get implemented first (since most usages already have some existing platform, alternative or replacement for an that platform comes to mind). Apparently it is not animations, personally I'm still hoping 3rd party controls support in SceneBuilder will get higher on the list, but I'm not getting my hopes up. But as Mike pointed out; it is a missing functionality, go build it! ;-) Tom On 24-11-2014 13:18, Felix Bembrick wrote: JavaFX should not be seen as a replacement for anything or an alternative. It has characteristics of both Flash and Flex along with Silverlight and especially Qt, (not to mention even HTML5/CSS/JS), but is a separate and distinct product in its own class. Just because the Flash visual editor may have got in the way of your desire to code directly, that doesn't mean that JavaFX should not have such an editor for all the same reasons and use cases that Flash had one. Sure, for *your* purposes of decorative effects, I am confident that coding would suffice but for *my* purposes (and anyone who has worked in the animation industry or worked creating visualisations) I really need a visual editor of the ilk I have described. Why just make one class of user happy but seriously limit the effectiveness of another (and in doing so possibly significantly limit the market of JavaFX)? I am sure at least one of the developers on the JavaFX team has at one point at least envisaged JavaFX being used for complex animations, visualisations or even non-trivial games. What they need to do now is make such use cases feasible. On 24 November 2014 at 22:04, Tom Eugelink t...@tbee.org mailto:t...@tbee.org wrote: I have no problems using JavaFX's animations for my purposes, which are decorative effects. I do not need an editor for that, forced me to use it and it probably will even get in my way. Which BTW was the case with the Flash coding that I have done; I hated that Flash EDI, it was way too much focussed on animation. Actually that is why Adobe created Flex, which basically was flash-for-developers (instead of animators). JavaFX is more a alternative for Flex than Flash. Tom On 24-11-2014 11:20, Felix Bembrick wrote: Really? My point is, why have such good built-on classes to support the building of everything from simple animations to complex visualisations if it is practically impossible to do so? On 24 November 2014 at 21:02, Tom Eugelink t...@tbee.org mailto:t...@tbee.org wrote: I do not think that JavaFX is aiming at replacing flash, HTML and javascript are doing a great job there, hence animations are not equally important as they were for flash. Tom On 24-11-2014 10:46, Felix Bembrick wrote: I am surprised more people have not expressed an opinion on this. To me, it seems absolutely *vital* to the long term (or any term) success of JavaFX. Haven't any of you ever programmed in Flash? Can you imagine trying to create any of those complex (or even the simple) animations and visualisations *without* a visual editor and by doing it code alone? It wouldn't have been practical (read possible) and similarly, and with JavaFX having even richer features, to do this by hand. To me, this is the reason why we haven't seen any great animations/visualisations/applications using JavaFX and we probably never will until a visual animation editor is available. Specifying and controlling the motion and appearance of numerous complex objects and their transitions relying exclusively on code would not be possible for even the gunnest JFX coder... On 18 November 2014 at 02:48, Richard Bair richard.b...@oracle.com mailto:richard.b...@oracle.com wrote: I’m afraid at this time there are no plans for adding an animation/transition effect editor to Scene Builder, certainly not in the short-term. Thanks Richard On Nov 13, 2014, at 7:34 PM, Felix Bembrick felix.bembr...@gmail.com mailto:felix.bembr...@gmail.com wrote: Java applets were the first programs to run inside a web browser and for a (little) while they were flavour of the month. But then along came Flash which had several advantages such as faster load times, consistent loads and antialiased fonts/graphics and soon completely surpassed applets
Re: What Scene Builder needs YESTERDAY!
In light of the reflection performance hit, the approach dagger 2 has taken with DI may be pretty interesting. http://www.youtube.com/watch?v=oK_XtfXPkqw On 24-11-2014 16:19, Manfred Karrer wrote: I have a longtime backgroud in Flash and Flex development and a bit if iOS, so I would like to add here my 5 cents. My first impression and experience with Scene Builder was kind of: Is this meant serious? It cannot be that Oracle release such a product in year 2014 when other platform had shipped well working UI - WYSIWYG editors more then 10 years ago. Sorry I don't want to be rude, but that was my first reaction. Beside that it is (at least on mac) pretty buggy and not 2 way compatible (if you continue to edit in FXML you soon get to the point where you cannot open it in Scenebuilder anymore because it does not support all what the compiler supports). That leads either to a very cautious and restrictive usage of FXML or that you use it just initially for the first UI prototype and then later don't use it anymore and have the annoying workflow to compile and run the app to see visual changes. I know that a really well working WYSIWIG editor is a challenge, and so far the only 2 which really worked well from my experience was the Flash IDE (I did not use later versions anymore so no idea how it is today) and Xcode. The Flex editor had more or less the same problems like Scene Builder (in the teams I worked it was considered as a toy). One general problem is as soon you have 2 development paths (visual and xml) it tends that one gets lost behind from proper support of the vendor. Xcode and early Flash IDE made the radical decision to have only an visual editor, the workflow does not involve xml editing when you reach the limits of the editor. That forced the visual editors that they need to make it all possible, which worked for both platforms pretty well. Of course the Flash IDE was too limited on the coding side and had another direction, but XCode combined both worlds in a pretty good way. I am not expecting to have support for animations. Thats another hard challenge and I am not sure if that should not be left out to some external tools. I just would be happy to have an visual editor that really represents correctly what i will see when its compiled and which sticks in sync when the UI gets more complex and integrated with the projects code base (here Scene Builder lacks a lot!). But beside that, another disappointment for me was (coming from Flex) that it is pretty slow (for a such a fast runtime like Java). It feels for me same slow like Flex was, but the Flash runtime used by Flex is a much, much slower then Java, so how can it be that a Java based UI framework is not min. 10 times faster? Flex used code generation so all was compiled, otherwise it would have been completely unusable (slow). JavaFX use reflection and interprets FXML at runtime which introduces 2 performance penalties: - The runtime loading (takes 50-200 ms depending on the size of the FXML) - The parsing and reflection based interpretation which takes another 50-200 ms (not so sure about that, as in that time the inclusion in the scene graph is included as well, but if the layout or rendering is so slow, then that is another question why). Every delay larger then 50 ms is very clear visible to the user, resulting in an UI which just does not feel snappy. In my current app I use caching to avoid at least the slow loading (after the initial load). I will probably convert all FXML when the UI is final to java code to get rid of the second performance penalty. But that of course is not a satisfying situation! Hopefully some code generation projects gets mature enough to be really useful in complex UIs or Oracle take JavaFX serious enough to put more effort on that. Conclusion: You can see in the UI how well the tools have supported the work process. If its a pain and a lot of work to get simple stuff done the UI looks like that. Flash was very good on that already back in 2002, you could create stunning animations, effects, designs without pain, it was fun to work on that. XCode is pretty good on that as well, Apple has a long tradition to take the visual aspect and the usability very important. And you can see that. Sorry again for the pretty critical and negative feedback. Actually I love to work with JavaFX, it just feels it could do much better, specially as we are in 2014 (Flex become mature around 2006). Kudos to all who are working hard on the platform. I am totally aware those are not easy tasks and limited resources produce restrictions... br, Manfred Karrer Am 24.11.2014 um 13:37 schrieb Tom Eugelink t...@tbee.org: Oh, you are right, if the JavaFX team does not need to make choices on where to invest their precious time, then all possible usages could be implemented immediately. Unfortunately they too have to place priorities and then the most likely usage
Re: What Scene Builder needs YESTERDAY!
and which sticks in sync when the UI gets more complex and integrated with the projects code base (here Scene Builder lacks a lot!). But beside that, another disappointment for me was (coming from Flex) that it is pretty slow (for a such a fast runtime like Java). It feels for me same slow like Flex was, but the Flash runtime used by Flex is a much, much slower then Java, so how can it be that a Java based UI framework is not min. 10 times faster? Flex used code generation so all was compiled, otherwise it would have been completely unusable (slow). JavaFX use reflection and interprets FXML at runtime which introduces 2 performance penalties: - The runtime loading (takes 50-200 ms depending on the size of the FXML) - The parsing and reflection based interpretation which takes another 50-200 ms (not so sure about that, as in that time the inclusion in the scene graph is included as well, but if the layout or rendering is so slow, then that is another question why). Every delay larger then 50 ms is very clear visible to the user, resulting in an UI which just does not feel snappy. In my current app I use caching to avoid at least the slow loading (after the initial load). I will probably convert all FXML when the UI is final to java code to get rid of the second performance penalty. But that of course is not a satisfying situation! Hopefully some code generation projects gets mature enough to be really useful in complex UIs or Oracle take JavaFX serious enough to put more effort on that. Conclusion: You can see in the UI how well the tools have supported the work process. If its a pain and a lot of work to get simple stuff done the UI looks like that. Flash was very good on that already back in 2002, you could create stunning animations, effects, designs without pain, it was fun to work on that. XCode is pretty good on that as well, Apple has a long tradition to take the visual aspect and the usability very important. And you can see that. Sorry again for the pretty critical and negative feedback. Actually I love to work with JavaFX, it just feels it could do much better, specially as we are in 2014 (Flex become mature around 2006). Kudos to all who are working hard on the platform. I am totally aware those are not easy tasks and limited resources produce restrictions... br, Manfred Karrer Am 24.11.2014 um 13:37 schrieb Tom Eugelink t...@tbee.org mailto:t...@tbee.org: Oh, you are right, if the JavaFX team does not need to make choices on where to invest their precious time, then all possible usages could be implemented immediately. Unfortunately they too have to place priorities and then the most likely usage will get implemented first (since most usages already have some existing platform, alternative or replacement for an that platform comes to mind). Apparently it is not animations, personally I'm still hoping 3rd party controls support in SceneBuilder will get higher on the list, but I'm not getting my hopes up. But as Mike pointed out; it is a missing functionality, go build it! ;-) Tom On 24-11-2014 13:18, Felix Bembrick wrote: JavaFX should not be seen as a replacement for anything or an alternative. It has characteristics of both Flash and Flex along with Silverlight and especially Qt, (not to mention even HTML5/CSS/JS), but is a separate and distinct product in its own class. Just because the Flash visual editor may have got in the way of your desire to code directly, that doesn't mean that JavaFX should not have such an editor for all the same reasons and use cases that Flash had one. Sure, for *your* purposes of decorative effects, I am confident that coding would suffice but for *my* purposes (and anyone who has worked in the animation industry or worked creating visualisations) I really need a visual editor of the ilk I have described. Why just make one class of user happy but seriously limit the effectiveness of another (and in doing so possibly significantly limit the market of JavaFX)? I am sure at least one of the developers on the JavaFX team has at one point at least envisaged JavaFX being used for complex animations, visualisations or even non-trivial games. What they need to do now is make such use cases feasible. On 24 November 2014 at 22:04, Tom Eugelink t...@tbee.org mailto:t...@tbee.org mailto: t...@tbee.org mailto:t...@tbee.org wrote: I have no problems using JavaFX's animations for my purposes, which are decorative effects. I do not need an editor for that, forced me to use
Re: JavaFX application for different resolutions
Just like with any other application, HTML or Android for example, you can rearrange the layout depending on the screensize and use different icons with less detail, this is called responsive design. HTML offers through CSS support for automatically applying different styles based on the available space (http://en.wikipedia.org/wiki/Responsive_web_design). Hendrik Ebbers tried to do something similar with ResponsiveFX (http://www.guigarage.com/2014/11/responsive-design-javafx/). In the end you still have to engineer your application so it can be responsive, supporting tools and techniques or not. Tom On 14-12-2014 16:07, Peter Penzov wrote: I'm using Simple JavaFX application on computers with different solution. But on computers with small resolution the appearance is not good. Is there any way to ajust the size of the application according to the screen size? BR, Peter
switching skins at runtime
Is it allowed / supported to execute setSkin with a new skin on a control that is part of a scene? Tom
Re: switching skins at runtime
Then this NPE on getSkinnable() when switching Agenda's skin when the control is already shown (instead of when created) must be my doing some how. Thanks! Tom On 23-12-2014 14:36, David Grieve wrote: Yes, it is allowed. But know that there is some code in setSkin that prevents setting a skin that is either instance equal or the same class. On 12/23/14, 6:27 AM, Tom Eugelink wrote: Is it allowed / supported to execute setSkin with a new skin on a control that is part of a scene? Tom
Re: switching skins at runtime
Hm, I've got it working, but I need to call a getChildren().clear() before I start creating nodes in a skin. If not, the control will retain the nodes an old skin has created. Also any style classes that were assigned remain, but those can be reset easily. Never the less I feel that setSkin() should clear the children and reset the style classes itself? Tom On 23-12-2014 15:39, Tom Eugelink wrote: Then this NPE on getSkinnable() when switching Agenda's skin when the control is already shown (instead of when created) must be my doing some how. Thanks! Tom On 23-12-2014 14:36, David Grieve wrote: Yes, it is allowed. But know that there is some code in setSkin that prevents setting a skin that is either instance equal or the same class. On 12/23/14, 6:27 AM, Tom Eugelink wrote: Is it allowed / supported to execute setSkin with a new skin on a control that is part of a scene? Tom
Re: switching skins at runtime
Clearing the children in dispose does not work, the control than actually has no nodes what so ever, so that still is done when building the new skin. Tom On 29-12-2014 11:55, Werner Lehmann wrote: That's what I meant: clear children, or undo whatever you are doing to them, in dispose(). At any rate I wouldn't know if that is correct. It is just how I assume this would work. On 29.12.2014 11:44, Tom Eugelink wrote: That works for unbinding listeners to skinnable and the reset code for style class, I still need to clear the childeren. Tom
CSS under 1.8.0_40 not identical to 31 or older
I've just now ran JFXtras Samples under the latest 1.8.0_40 and it does not render
identical as when run under 1.8.0_31, some CSS rules are not applied. Samples is easily
downloaded from here
(http://jfxtras.org/resources/java/jfxtras-labs-samples-8.0-r4-SNAPSHOT-shadow.jar) and
started simply with java -jar.
When run under 1.8.0_31 or older, the LocalDateTimeTextfieldSample shows a
textfield with a popup button. When the button is pressed a popup is shown, with a
gradient as the background and both an ok and cancel icon in the right top. The exact
same jar under 1.8.0_40 does not show the gradient nor the two icons.
LocalDateTimeTextfield under water uses CalendarTextField, so the code for this
is in the calendar based control:
https://github.com/JFXtras/jfxtras/blob/8.0/jfxtras-controls/src/main/java/jfxtras/internal/scene/control/skin/CalendarTextFieldSkin.java
https://github.com/JFXtras/jfxtras/blob/8.0/jfxtras-controls/src/main/resources/jfxtras/internal/scene/control/CalendarTextField.css
Interesting are the lines starting at 351 in the skin, which do:
Popup lPopup = new Popup();
...
BorderPane lBorderPane = new BorderPane();
lBorderPane.getStyleClass().add(this.getClass().getSimpleName() + _popup); // this
amounts to CalendarTextFieldSkin_popup
...
lPopup.getContent().add(lBorderPane);
This no longer results in applying the background colors as defined in the css
file on line 12.
.CalendarTextFieldSkin_popup {
-fx-background-color: -fx-shadow-highlight-color, -fx-outer-border,
-fx-inner-border, -fx-body-color;
-fx-background-insets: 0 0 -1 0,0,1,2;
-fx-background-radius: 5,5,4,3;
-fx-padding: 0.77em 0.73em 0.75em 0.73em;
-fx-text-fill: -fx-text-base-color;
}
Neither are the two in the css defined icons applied to the ImageViews.
Is this intentional or a bug?
Tom
Re: Event when CSS is applied
On 18-2-2015 08:34, Tomas Mikula wrote: Hope this helps. I'll give it a try! Maybe it will solve some of the TBEERNOT (TODO) tags further down the code. Tom
Re: Event when CSS is applied
On 18-2-2015 08:34, Tomas Mikula wrote: What I think should be done is, instead of trying to hack around Pane, create class NeedlePane that extends Region and overrides layoutChildren. It would create its children in the constructor (or take them as constructor parameters), add them to its children list right in the constructor and never clear them, and position them on the layout pass (i.e. in layoutChildren). Creating a DialPane is not such a problem, but creating a path only once and the only layout it turns out to be more of a challenge: the constructed but not yet correctly initialized path elements do not behave well with the rotate. It is an approach with merrit though, especially in resizing. Tom
Re: Event when CSS is applied
I like the improvements to the code. Thanks! Tom
Re: Event when CSS is applied
On 18-2-2015 21:49, Tomas Mikula wrote: So back to your original question: Basically I would like to be informed when the styling of a node has been applied or changed. Is there some place that can provide this information? Turns out you don't actually need this information ;) Indeed. Pattern learned. What does surprise me is that JavaFX aims at doing things via composition, that is why almost everything is final, and where the structure in my original code comes from. This turns out is best solved with inheritance. Tom
Re: Event when CSS is applied
needsLayoutProperty() is not available on Text, and I figure that on the container it in the end will call layoutChildren, which I'm using already. On 17-2-2015 14:24, Benjamin Gudehus wrote: Basically I would like to be informed when the styling of a node has been applied or changed. There are isNeedsLayout() and needsLayoutProperty() and they might give Node-based information whether the the layout and thus the styling was applied. I guess this might be true, since doCSSPass() is called before doLayoutPass() in the JavaFX thread, but could be wrong on this regard. As another (more fuzzy) option you could place a custom Logger into PulseLogger and handle calls to the newPhase() method. The problem is, that it only gives Scene-based information, i.e. you don't see which Node was processed, so it might be unreliable information. I use a custom PulseLogger for performance tests. --Benjamin On 2/17/15, Tom Eugelink t...@tbee.org wrote: I have a skin (of a control) that centers a Text node. This Text node can be styled via CSS, so this styling is a factor when centering. because larger font means wider text. The centering works perfectly, the only problem is figuring out when to center the node. At the moment I'm centering the node on every layoutChildren call of the skin, but this is way to often, because after applying the CSS chances are very low that the node will need to be repositioned. Basically I would like to be informed when the styling of a node has been applied or changed. Is there some place that can provide this information? Tom
Re: Event when CSS is applied
Registering to fontProperty works, but potentially requires a lot of listeners on every property that may affect the size, like effect, scale, etc. So I'm leaving it in layoutChildren for now; better once to many than not often enough. Would adding such an event be a big change? On 17-2-2015 14:50, David Grieve wrote: On 2/17/15 8:02 AM, Tom Eugelink wrote: I have a skin (of a control) that centers a Text node. This Text node can be styled via CSS, so this styling is a factor when centering. because larger font means wider text. The centering works perfectly, the only problem is figuring out when to center the node. At the moment I'm centering the node on every layoutChildren call of the skin, but this is way to often, because after applying the CSS chances are very low that the node will need to be repositioned. Basically I would like to be informed when the styling of a node has been applied or changed. Is there some place that can provide this information? Not in general, no. But you can add a listener to a property that is styled by CSS and react to the change. You might add a listener to the Text node's fontProperty, for example. Clearly this isn't an all-purpose solution. Another approach is to hold onto the bounds (or maybe just the pref width and height) of the child node. If the old bounds doesn't equal the new bounds, then recenter.
Re: Event when CSS is applied
(after a night's sleep)
Well... I was trying to do things by composition and it did not work. My
implemention worked, but it had to depend on a layoutChildren, only at the top
level (Skin), which was not fine grained enough.
Interesting is that for JFXtras Agenda I used the inherit pattern, but because Agenda
has a lot of nested layout (week - day - appointment - time, title, ...).
Inheritance was used there out of a need for encapsulation; the composition code got
very complex. But it probably saved me from a lot of CSS and layout woos.
Now, back to the gauge, I just tried to see if I could hammer a composition
pattern onto NeedlePane. The separation between construction and layout is a
good thing, so I ended up doing this:
- Removing the whole NeedlePane class and replace it with a Pane needlePane = new
Pane(); since we're doing absolute layout.
- Convert the constructor to a method private void constructNeedlePane()
- Convert the layoutChildren to a method private void layoutNeedlePane()
- Then I tried to wire it up by listening to needlePane.needsLayoutProperty()
That did not work... It worked partially, which was weird.
What of course did work was hooking into layoutChildren():
final private Pane needlePane = new Pane() {
@Override
protected void layoutChildren() {
super.layoutChildren();
layoutNeedlePane();
}
};
So, now I have composed the layout with a smallish hack. But, getting back to my remark
on Agenda... Encapsulation was a good thing there, and actually I like using
extends (I always complain when things are final, and I cannot override). So
I'm not too displeased with what we ended up with. ;-)
Tom
On 18-2-2015 22:50, Tomas Mikula wrote:
Hmm, my view is rather reverse to yours:
The fact that the implementation of layout is best solved with
inheritance is a sign that JavaFX does _not_ aim enough at doing
things via composition.
Tomas
On Wed, Feb 18, 2015 at 4:37 PM, Tom Eugelink t...@tbee.org wrote:
On 18-2-2015 21:49, Tomas Mikula wrote:
So back to your original question:
Basically I would like to be informed when the styling of a node has been
applied or changed. Is there some place that can provide this information?
Turns out you don't actually need this information ;)
Indeed. Pattern learned.
What does surprise me is that JavaFX aims at doing things via composition,
that is why almost everything is final, and where the structure in my
original code comes from. This turns out is best solved with inheritance.
Tom
Re: Event when CSS is applied
On 17-2-2015 20:01, David Grieve wrote: On 2/17/15 1:30 PM, Tom Eugelink wrote: The control is a codewise polish up one of Gerrit's gauges (with permission!) and pulled into JFXtras (with tests and all). For an idea on what we are talking about: https://www.youtube.com/watch?v=RH5X1uBu1d8 The process of centering the Text in that circle is a bit more complex. 1. The value may vary between a min and max value. 2. I want the Text to automatically utilize the maximum available space, but not change size when a longer or shorter text is shown. To do this I have two additional Text nodes that have the same styling as the Text node (so these are on the scene, but not visible, otherwise CSS is not applied). These two text nodes get the maximum and minimum possible value set. Then on these two some pythagoras is applied and in that way one can determine the scale factor so that the value will never be rendered outside of the circle. Then the actual to-be-rendered value can be placed into the Text node and positioned in the centre of the circle. The problem is that a lot of these calculations depend on the CSS styling. What font is set? Bold or not? So I can only do these calculcation after the CSS has been applied. This unfortunately is not yet the case when the skin is instantiated. This means that if I do not used the layoutChildren, the initial presentation is totally off, untill the first min/max/value is set. Have you looked at the javadoc for Node#applyCss()? I did just now and tried calling that and layout when the skin is being instantiated, but apparently things are not setup right yet. Maybe layoutChildren with bound checking is the way to go.
Event when CSS is applied
I have a skin (of a control) that centers a Text node. This Text node can be styled via CSS, so this styling is a factor when centering. because larger font means wider text. The centering works perfectly, the only problem is figuring out when to center the node. At the moment I'm centering the node on every layoutChildren call of the skin, but this is way to often, because after applying the CSS chances are very low that the node will need to be repositioned. Basically I would like to be informed when the styling of a node has been applied or changed. Is there some place that can provide this information? Tom
Re: Setting a default stylesheet for a custom control
Indeed. There are more than enough examples to look at and copy from :-) https://github.com/JFXtras/jfxtras/blob/8.0/jfxtras-controls/src/main/java/jfxtras/scene/control/ListSpinner.java On 27-1-2015 23:30, Jonathan Giles wrote: If I'm correctly understanding your question, you want to override the getUserAgentStylesheet() method inside your Control class. In here you'll simply return the CSS file that is being used to style your custom control. I'm also aware there are some issues (with CSS error messages being printed to the console) in certain releases (8u20). If you run into these, ping me and I'll give you some pointers. -- Jonathan On 28/01/2015 11:24 a.m., Pedro Duque Vieira wrote: Hi, I'm developing a custom control, in the process I've used CSS to define its style. Now I want to make this control available for use by any developer, so I want this control to have a default stylesheet which is the one I've used to create the control much like javafx controls have a default stylesheet (modena or caspian). How can I do this? I still want to make it possible for any user of my control to override the css styles that the default stylesheet defines. Thanks
custom controls: printing
Do I need to do something special to support printing of custom controls? The use case is that on screen a spreadsheet can be shown in a scrollpane, but when printing the whole spreadsheet should be printed. Tom
Re: custom controls: printing
Ok, so looking at some examples like http://java.dzone.com/articles/introduction-example-javafx-8 where PrintJob is let lose on a node, JavaFX's PrintJob will either use the screen rendering or -if present- call: public void print(PrinterJob job) Correct? Tom On 28-1-2015 02:43, Phil Race wrote: On 1/27/15 4:08 PM, Tom Eugelink wrote: Do I need to do something special to support printing of custom controls? The use case is that on screen a spreadsheet can be shown in a scrollpane, but when printing the whole spreadsheet should be printed. Being a 'custom' control doesn't really make a difference here. The same would apply if you wanted to print one of the built-in controls that is in a scroll pane or otherwise not likely to fit on a page. Spreadsheets, like TableView, TextArea and the like will need to have their data laid out for the printer by the application. In practice this means starting with the data contained in the spreadsheet and iterating over it printing as much as fits on each page in what ever way you want. I am sure that something that can handle this this would make a nice add-on to to the core API but it was not something that was considered appropriate to be part of FX core. We expected reporting packages to pop up from 3rd parties The exception to this is HtmlEditor / WebEngine where you cannot reasonably expect the application or such a package to know how to properly print the data (HTML and other web content) Hence that has a method to print its content to a PrinterJob http://docs.oracle.com/javase/8/javafx/api/javafx/scene/web/WebEngine.html#print-javafx.print.PrinterJob- So one possibility for you is to throw your data into HTML table syntax, load it into a web node and print that. -phil.
Re: custom controls: printing
Ok, I see my question is not quite clear: I'm not looking for how to print, I am trying to figure out how to properly implement printing on a custom control, more specifically JFxtras' Agenda. Agenda has the same problem as the more recognizable usecase of a spreadsheet: it uses a scrollpane in its skin, so when taking a screenshot this scrollpane limits what is captured, but when printing -like a spreadsheet- I need all the data. So first I was trying to grasp how printing in JavaFX works conceptually, but from what I'm decuding so far this is very limited and basically no more that screen capturing. Correct? Tom On 29-1-2015 05:53, Phil Race wrote: That example is not great as it picked the one node type that knows how to do something special with printing and completely overlooks it. The print(Node) method it provides can print any node type but it is scaling it to fit on a single side of paper. That's not ideal for a huge spreadsheet/table as you won't be able to read the output without a microscope. I was pointing to the method on webengine that you mention last below as the one you should use and the example does not use that anywhere. To get proper pagination you need to explicitly call the WebEngine.print(PrinterJob) method -phil. On 1/27/15 10:22 PM, Tom Eugelink wrote: Ok, so looking at some examples like http://java.dzone.com/articles/introduction-example-javafx-8 where PrintJob is let lose on a node, JavaFX's PrintJob will either use the screen rendering or -if present- call: public void print(PrinterJob job) Correct? Tom On 28-1-2015 02:43, Phil Race wrote: On 1/27/15 4:08 PM, Tom Eugelink wrote: Do I need to do something special to support printing of custom controls? The use case is that on screen a spreadsheet can be shown in a scrollpane, but when printing the whole spreadsheet should be printed. Being a 'custom' control doesn't really make a difference here. The same would apply if you wanted to print one of the built-in controls that is in a scroll pane or otherwise not likely to fit on a page. Spreadsheets, like TableView, TextArea and the like will need to have their data laid out for the printer by the application. In practice this means starting with the data contained in the spreadsheet and iterating over it printing as much as fits on each page in what ever way you want. I am sure that something that can handle this this would make a nice add-on to to the core API but it was not something that was considered appropriate to be part of FX core. We expected reporting packages to pop up from 3rd parties The exception to this is HtmlEditor / WebEngine where you cannot reasonably expect the application or such a package to know how to properly print the data (HTML and other web content) Hence that has a method to print its content to a PrinterJob http://docs.oracle.com/javase/8/javafx/api/javafx/scene/web/WebEngine.html#print-javafx.print.PrinterJob- So one possibility for you is to throw your data into HTML table syntax, load it into a web node and print that. -phil.
Re: custom controls: printing
On 29-1-2015 08:01, Phil Race wrote: If you create an Agenda that is never displayed but has the same data and set its size so that it can display all the data, I expect it should be possible to scale it so that it fits on one page like the example you referenced but once you have 500 items in your agenda, someone is going to have to handle the magic that splits that across pages and there's no way the core printing API could know how to do that for a control. All it sees are Nodes .. Ok. I get that. So bottom line is that I need to implement print(PrintJob), similar to webview's, to get rid of the scrollpane. Agenda looks like Google Calendar, so it is more complex than a list. And that for each skin. Ok. Tom
