I agree that we need an “Interface Builder”-like tool in Java, and I’m OK with it storing the UI in an opaque file — in fact I think I might prefer opaque storage.

However, I don’t think that there is anything to be gained by converting XIB files to Java UIs. For example, in Interface Builder, you can mark components with certain properties to change the way they render; that is you can indicate that an OutlineView should render as a SourceList, or that a button should render as a Disclosure button. These things just won’t translate, which I think makes trying to convert a XIB file to a Java UI a futile effort.

-Ken

Java needs Interface Builder (for JavaFX / Swing + MiG layout, whatever). Not more “text editing”.

Engineers, chip designers, artists use AutoCAD, Photoshop, Final Cut Pro, Pro Tools, …whatever — not “text editors”. Who gives a crap about the storage format for a UI? Certainly not Interface Builder users. This app is the gold standard in UI design, originally created in the 80s! Second place contenders are still far behind. For anyone interested it’s currently an XML format, before that a binary .plist format (bad for version control). The point is nobody edits .xib files by hand in a “text editor”.

Judging by what Sun have done with the UI design tools in NetBeans it is safe to say that it is an impossibility for Sun to create anything close to Interface Builder within the next 100 years. This appears true for other efforts too. Shame.

Thus we need a new build tool that converts an Interface Builder .xib file to JavaFX….!

Where can such a godsend be found?

- John

I’m not sure how to articulate the rules to follow when writing JavaFX script, but I do know that it should be *readable*, where readable means that I can follow the code relatively effortlessly. I think you’ve done that with your code snippet.

Your right about a larger file being the true test – I’ve seen some pretty gnarly JavaFX script that was virtually impenetrable!

-Ken

I agree, going more than a few levels deep gets really bad (though I might extend it to 5 levels before I start to get lost). I think the same general problem with deeply nested if/while/for statements applies here. I suspect breaking out deep parts of the tree into separate files is probably going to win out as deep trees also tend to have reusable chunks. We’ll see I guess as we go along.

http://weblogs.java.net/blog/rbair/archive/2009/03/keep_your_fx_co.html

It runs between the two styles, but favors the first. Short example, so its easy to make the first form look good, so you need to produce a really horrible 3 page long example and then we can go another round and see what the code looks like :-)

Notice that I use the more compact KeyFrame literal syntax (which I can do since there is no action function declared on these keyframes) and that goes a long way towards cleaning it up, as does using translateY instead of transforms and since the Line’s are simple they can go on one line.

Your right in that pulling out everything into defs isn’t the right answer, but I think there is a balance (one I have yet to find!). I’m sure best practices will emerge out of good solutions as we go along. I think we’ll discover, though, that nesting things much more than 3 levels deep will be untenable.

-Ken
P.S. I’m looking forward to the designer tool that Tor alluded to.

I think you’re right, we haven’t figured out what good style in JavaFX is yet. I think breaking everything down into def’s is ugly too. I think defining both KeyFrames separately is very ugly.

And setting the width/height on the Stage instead of the Scene is a bad practice. Bad on us! We shouldn’t be showing examples of setting width/height on Stage instead of Scene.

I tend to agree. The thing is: I still deem a declarative approach to be a good thing, but only down to a certain level – burying all variables inside a labyrinth of anonymous inner classes does not seem like a good idea to me in ANY language, not just Java and JavaFX.

@Brian

I do not think you are blinded by Java ;) … before starting my Ph.D. and consequently started using Java only, I have been developing PHP/HTML/JS applications for some five years and still I do not like the nested structures.
Your transformed version of the initial JFX script already shows that clearer structure is possible. I just fear, we will not see it that often in JFX applications in the next few years.

Best,
S.

I put a png of the code here: http://drop.io/t3tqdys
(hope it works).

The Scene content is a pair of lines on a background image.

The Timeline moves the lines over a 3 second interval between -20 and 200.

Both these things can just be “read” once you are used to the syntax.

There are just two vars, a y-coordinate and the image Url.

I agree there should be a balance in this, I just don’t agree with you about where it should be.

I also think this will evolve with subsequent releases of JavaFX, right now everybody is just getting to grips with it.