FX Experience Has Gone Read-Only
I've been maintaining FX Experience for a really long time now, and I love hearing from people who enjoy my weekly links roundup. One thing I've noticed recently is that maintaining two sites (FX Experience and JonathanGiles.net) takes more time than ideal, and splits the audience up. Therefore, FX Experience will become read-only for new blog posts, but weekly posts will continue to be published on JonathanGiles.net. If you follow @FXExperience on Twitter, I suggest you also follow @JonathanGiles. This is not the end - just a consolidation of my online presence to make my life a little easier!
tl;dr: Follow me on Twitter and check for the latest news on JonathanGiles.net.
by Richard Bair | Nov 18, 2009 | Controls, Devoxx, Web Services
In a couple hours Jasper and I will be presenting a talk titled “Enterprising JavaFX” at Devoxx. The main purpose of the talk is to describe how to use JavaFX for writing enterprise application content. Here’s a quick teaser screenshot of one of the apps we’re going to describe:
Jira Dashboard Application
We’ll be writing some additional blog posts over the next few weeks describing various tips n’ tricks as to how we used web services in this app, how we wrote the custom list cells, and so forth.
by Richard Bair | Nov 13, 2009 | General, Tips n' Tricks
Just a quick post here. Found another example in Popup code that can be cleaned up and wanted to share. Here is the original code:
[jfx]
FX.deferAction(function() { doAutoHide(); });
[/jfx]
This line of code is going to use the FX.deferAction function which takes as a parameter a function with no arguments and no return. (FX.deferAction is essentially like SwingUtilities.invokeLater(Runnable)). However, since the doAutoHide() function already has this method signature, I can avoid creating the anonymous function and instead simply do:
[jfx]
FX.deferAction(doAutoHide);
[/jfx]
Much nicer.
by Richard Bair | Nov 13, 2009 | API Design, General
The Node class has a lookup function which is used for finding a node in the scenegraph based on an id. Every node has a String id, similar to HTML. In theory it should be unique within the scenegraph though in practice this isn’t necessarily the case.
This lookup function currently only operates over the “public” or “logical” scenegraph, not the physical one. For example, a Button is a Control which delegates its visuals to its Skin. The Skin has a sub-scenegraph. But since we typically want to encapsulate all that, we hide it from the programmer such that most things don’t find this part of the scenegraph. Seems like a reasonable thing to do (Swing went the other way and all the gory details were public which led to issues sometimes where people would dig around and rely on internal details — the horror! — and this made it incredibly difficult to fix bugs later in Swing).
CustomNode was our level of encapsulation. Any CustomNode’s children was explicitly not part of the public API. However, a number of people have complained, likely because they aren’t using CustomNode for encapsulation but rather for modularization of their source code (ie: break a huge file into several files where each piece extended from CustomNode).
So it seems like this partitioning of “logical” and “physical” scenegraphs is quite confusing at times. So the question is, should the lookup function operate on the physical scenegraph? Vote!
[poll id=”2″]
by Richard Bair | Nov 13, 2009 | General, Tips n' Tricks
I was doing a bit of work today reviewing the Popup class we’re working on for the next release of JavaFX. I showed Jasper some code snippets and he pointed out that I should write a quick blog on it because it shows a nice progression of how to do looping in JavaFX. (more…)
by Richard Bair | Oct 13, 2009 | API Design
Stuart Marks (one of the UI Controls “heavies”) has a great write-up on that “Infernal Scene Graph Warning Message”. You know, the one that showed up in JavaFX 1.2 in seemingly innocuous situations such as the following:
[jfx]
var g = bind Group {
translateX: someX
content: node
}
[/jfx]
In this code, whenever “someX” changes, a new Group is created and the node is mysteriously moved from this Group to the new one, and in the process the “infernal scenegraph warning message” is printed. Stuart goes into a lot of great history and detail to give context to the problem, but here is probably the money-quote as to why the warning message was useful:
When we added the enforcement code, we were surprised that it uncovered a few bugs and quite a number of questionable coding practices in our code, both in our runtime library and in our samples. In one case a node from the scene graph was also being used as a clip. This was illegal and didn’t actually work, but nobody had noticed up to that point. As for questionable coding practices, the enforcement turned up quite a number of cases where a scene graph was being constructed with some initial structure, and some code later on would rearrange the nodes into a different structure for no good reason. This caused the scene graph machinery to do a lot of extra work. The fix was to rewrite the code to create the scene graph in the desired structure, avoiding the rearranging and any error messages that the old code had caused.
Go visit his blog to get more information, I’m waiting for the second installment which I anticipate will go into all the nitty gritty details. Its kind of a cliff hanger because he doesn’t tell you what the final unanimous decision was regarding the warning message. Codify it as an error? Remove it? Something else?
