For each such visual tool, there are programmatic means to achieve the same effect. As a result you have to find a balance between hand crafting graphics in a visual tool and generating them programatically. In some cases the former is the more effective approach, in some cases the latter, or a mixture of both.

I don't have definitive proof yet, but I believe using F3 to develop such tools should make it far easier than what the competitors are doing (with the possible exception of Microsoft Expression), since other than Matisse all of those mentioned above are written in C.

As a partial demonstration, here's a basic F3 implementation of a "Pen Tool", which is a tool for drawing a sequence of connected cubic Bezier curves. I am not an expert or even a regular user of any of the above mentioned tools, so it took me a while to figure out how "Pen Tool" is supposed to work, but once I understood that it was straightforward to implement.

Each time you click on the canvas a new point and two new invisible control points are added to the curve. If you drag the mouse before releasing it you can adjust the tangent of the curve at that point (in effect by changing the values of the control points). If you hover near a point you'll see two small circles connected by a line and a larger circle surrounding the point. Dragging the larger circle moves the point. Dragging the smaller circles adjusts the tangent of the curve at that point (there are tooltips to that effect).

In this demo you can't delete points or insert points in the middle of the curve, however it does have infinite undo/redo with CTRL-z (undo) and CTRL-y (redo).

The model of the curve is simply an array of points. The first point is a dummy control point. Following that points are added according to the following pattern: [pt, cp, cp, pt, cp, cp, ...], i.e. a point followed by two control points. For each point its preceding and following control point must be collinear (on the same line) with it. The mouse drag handlers for the control points implement this invariant when you drag one of the them by rotating the corresponding control point around the point.

From the array of points a Path is projected (with the F3 bind operator) having a MoveTo element for the first point, and CurveTo elements for each sequence of [cp, cp, pt] after that, which creates the visual curve. In addition, the circles and lines mentioned above are also projected from and bound to the same points in the array. As a result when the mouse handlers or undo/redo operations add points to the array or modify the coordinates of a point the visual elements (path, circles, lines) are automatically added, moved, or removed accordingly.

Hi Chris,
I definitely appreciate your effort of making Java UI graphics faster and easier to write. On the other hand, wouldn't it make more sense to rather consolidate our forces on using already existing standards (e.g. SVG/XUL/ECMAScript)? While F3 is a very nice technology for demos, IMHO it doesn't have a chance in a long run when compared to Flash/Flex or WPF. If you would like to discuss this further, please drop me an email. You can find me using namefinder.
Thanks,
Martin

Hi Chris, This is all looking good. But when can we see a 'Hello World' kind of working tutorial?. It should contain from where we can get F3 script engine, IDE plugins etc.I read your previous comments that F3 will be public project by Feb 2007. Is it going to happen this month?.

Very nice indeed.
Chris: are you planning to share F3 with us? I mean some kind of runtime classes and stuff. I've already tried to use some ot the classes provided by the jnlp files but it kinda reminds me hacking:)
Cheers,
P

Well, I was just expressing my opinion - hopefully it is not illegal :-). I just simply believe using standard W3C XML formats combined with the power of Java language is much better than creating yet another programming language for a specific purpose. And the reason why I don't believe in it's success when compered to Flash/WPF? Both Adobe/Microsoft are working hard on their solutions and are trying to estabilish them as lead technolgoies for creating RIAs. What helps both companies is the fact their tools are actually miles ahead from anything available for F3. So even though F3 might be a nice piece technology itself, without good tools it doesn't have a chance in today's world. This is just my opinion - there is nothing to be ashamed of.

@Martin: it's probably just that people like to understand the basis for your opinion, just yelling "it's never going to work" is not very constructive.

Personally for example I think that specialized languages have their value, as shown by projects like Ruby on Rails. The good thing about F3 seems to be the amount of power it packs in so few lines, it's elegantly expressive.

On the other hand I have my doubts that any combination of SVG/XUL/ECMAScript will even be powerfull and easy enough to equal let alone beat Flash/Flex at its own game.

Of course I have no idea if F3 could do such a thing either nor if we would even want to but sometimes something completely new is needed to show us the way to go... or not to go.

And in the end here is someone willing to do the work so he gets to decide where to take this project. Nothing prevents you from taking SVG/XUL/ECMAScript and showing the world how things should be done properly :-)

The examples I saw on this blog convinced me that it was easy to create great-looking UIs with "minimal" effort in F3. So I think that F3 could be a worthy competitor to Flash and WPF. After all, it seems to me that there are some unworthy ties between WPF and Windows, which I don't like very much (and it does not seem so miles ahead, it is a very young technology). As for Flash, it is not XML too...

Martin, your question is valid (not shameful), and people should always questions. but all R&D is equally valid and shouldn't be discouraged. Who knows what the future will hold? The future is not about the here and now, even if we are.

For what it's worth, I disagree with Martin that the lack of designer
tools is the essential problem.

On the contrary from my
experience the UI designers/Graphic artists are never the bottleneck in
the software development process. Rather it's the programmers (and by a
large margin).

My primary goal with F3 in its current
incarnation is to allow programmers to be more efficient and as a result
be able to deliver faithful implementations of UI designs in a short or
reasonable amount of time.

Images and vector graphics
created in Photoshop, Illustrator, or other third party tools can be
easily incorporated into F3 programs and manipulated
programmatically.

Although it would be nice to have
automated integration between designer and programmer tools, the cost of
transfering artifacts between the graphic artist and the programmer is
not a significant bottleneck in the overall process either from my
observations.

To summarize: the purpose of F3 right now is
specifically to improve the efficiency of programmers, not that of designers,
and not of the process of integration between programmers and designers.

I agree Chris. I have used visual builder tools to get an idea for what the product might look like, a prototype basically. But once I have the basic idea, then translating that into an acceptable solution has been a lot of manual coding. Basically I find the code generated by these tools unfit for anything but prototypes. I am hoping that F3 will provide a streamlined approach from transitioning from the storyboard or prototype phase to the actual product.

What I don't like about F3 is the technology has been created for just for developers. Actually how many of you know developers which are good designers? In my entire career I met 2-3 good designers/programmers. On the other hand I met at least 50 programmers having a hard time to create a good looking form in Swing (fortunately they got Matisse, which helps a lot). I'm afraid F3 won't help these guys much.

Because of that, in my opinion it doesn't make any sense to create another language for developers without trying to solve how to integrate output from real designers (which often don't have any programming skills, or they know just a bit of JavaScript, because they create web sites). BTW when I'm talking about output from real designers, I'm not talking just about static images, but rather about animated and interactive content (all of this can be very nicely done with SVG for example).
So, while I agree F3 is really a nice piece of technology, since it currently does not trying to solve the integration between designers/programmers (which both Microsoft/Adobe are trying to do), it is in a very difficult position when compared with Flash/Flex and WPF.

BTW just from the technology point of view - can F3 for example stream the UI from the server, where it is being dynamically created by the server based on the current data? This can be done easily with all SVG/XUL/Java, Flash/Flex and WPF (WPF has some limits there, though). In my opinion this is very important feature for the future desktop apps (just look where the world is heading - RIAs, widgets, ... - the traditional desktop is basically dead from that point of view).

to quintesse: Perhaps I expressed myself wrong in the firstr posting, but when using standards, I meant using SVG/XUL/ECMAscript on the designer side and Java on the developer side. So it is actually SVG/XUL/ECMAScript/Java.

to evanx: "but all R&D is equally valid and shouldn't be discouraged" - I agree with that, so in the case you feel my post is having "discouraging" tone, I'm sorry for that and I'll try to avoid this in the future.

to Fred: I also don't like much tools generating the code. That's the reason I believe SVG/XUL + Java is a good solution - the SVG/XUL part is just a description of the UI (which can be changed on the fly while the app is running), and Java represents the business logic of the app.

Sorry for this "spam" guys, but when I tried to post the whole comment, the site was blocking it, so I had to split it into several pieces.
<p/>
Perhaps final words from me: I definitely don't want discredit F3, all I wanted to do is to point out, that to be able to effectively compete with Adobe/Microsoft, the UI design process must include both, the designer and the programmer and not to focus just on the programmer.

@Martin: I understood that SVG/XUL/ECMAscript was meant for the client, either with Java on the server or whatever technology but I stand by my remark that I don't see much future for a combination of these technologies, not to try to "dethrone" Flash at least.

Personally I think Flash is successful in spite of the fact that it uses ECMAScript for example, not because of it. Its strongest point are the easy with which it can be distrubted and the tools that exist for it. I think the fact that an "open/free" version of Flash has never seen the light of day does have to do with that last fact: the lack of tools. And I do think that to be to do what Flash does F3 will need some pretty good tools.

But in the end it's the programmers that have to enable the designers and the artists to do their work (by making those tools) and IMHO the more expressive the language they have to do that, the better are the options they can give to the designers/artists.

to quintesse: When I was talking about Java, I was thinking about Java on the client, not on the server - SVG/XUL/Java is a very powerful combination.
Nevertheless you are right about the tools - that's the strongest point of Flash - its tools focusing at designers and not exactly on developers. By focusing on developers F3 seems to be going the opposite direction and here we are back again to my complaint about this technology.

Wow Chris, if nothing else, you have sparked a healthy discussion.
Also, I really enjoy new programming languages, especially ones that help me solve a problem in a "satisfying" and interesting fashion. They help me think about the problem in a new way, and even when I can't use the langauge for an actual deployment I benefit from thinking about the problem from a different perspective.