I've started my next big Fan feature - the Fan Widget Toolkit or FWT (suggestions for better names would be welcome). Before doing any IDE work, we need a clean API for writing desktop apps with Fan. Like all Fan APIs, we desire portability between the JVM and .NET.

Back in 2000 or so, Andy and I wrote a light weight widget toolkit from scratch using Java2D. It looks great and is way easier to use for writing production quality code than Swing. It has been quite successful for our product and our customers. Because there is a clean graphics API to hide the Java2D mess, it is nice and portable. The nice thing about this approach for Fan is that only the graphics layer would need to be ported between Java and .NET versus all the widgets - and graphics layers are all pretty much the same these days.

But back in 2000 Windows XP, Vista, and OS X didn't exist - so a non-native widget toolkit was an OK solution. But now native look and feels are really sophisticated and polished. So any solution really needs to use native widgets. And with that requirement, I think the best solution on the Java side is the SWT (the toolkit used by Eclipse). SWT is quite elegant, although a bit low level. It has a couple issues which are programmer unfriendly:

• you have to construct widgets with their parent
• using colors, fonts, images is kind of awkward
• disposal of OS resources is very manual

Those are reasonable trade-offs for SWT because its design goal is to be a thin layer over the OS. But I definitely want the Fan APIs to be easier to use and take advantage with-blocks and closures for eventing.

The other huge advantage of SWT is that we can easily plug Fan code into Eclipse. Which if we were to target an IDE, that would probably the first one. Most likely I'll be developing some basic stuff that works stand alone to get started, then we can take a look at plugging some of those pieces into Eclipse.

On the .NET side, the APIs will be ported to WinForms (or WPF, or whatever the current flavor of the week is).

I started this work last night and feel like I've got a good design which leverages Fan's declarative style. Here is hello world which I've got working:

Window
{
  title = "FWT Sampler"
  bounds = Rect { x = 100; y = 100; w = 500; h = 300 }
  add(Label { text = "Hello world"; halign = Halign.center })
}.open

Where can we see the source, by chance? On that subject, where is the main repo for Fan? I see the SourceForge CVS is inactive, and I'm fine with that. Just wondering where to follow active development. (And if this is still in the air, I highly recommend using Google project hosting. Whenever I see a project there, I just breathe a sigh of relief that I don't have to deal with a clunky Java.net or SF interface.)

Meanwhile, I should also say that Fan looks great in many ways. Thanks for the good work so far.

Thanks Tom. We currently use a proprietary source control system, but are making plans to move to an open source system (hosted here on fandev.org). We'll post more info once that is complete. Also, the source code is included in the zip download for each build.

Thanks for the info.

Big +1 for choosing SWT for exactly the two reasons you mention.

I agree that SWT is a bit low level but this is a great opportunity for Fan to build a high-level API on top of it (like JFace does) while taking advantage of all the cool stuff that SWT provides.

As was pointed out above, please do your best to make a code repository available as soon as you can...

-- Cedric

I stubbed out a WinForms implementation to prove out the design. It was very clean and straightforward, so the design looks like it will work well.

Sounds great. Thanks for the info.

Just feeling a bit random before bed-time...

Fan <--- Java, C#, ...

FWT <--- AWT, SWT, GWT, ...

FanP <--- WPF, FANP, ...

... FanPire?

... Fangs?!

What I'd like to see some day is a window toolkit that embraces internationalization and a separation between those who design interfaces and those who write the software.

Maybe something like:

Window
{
   name = "settingspanel"
   add( Label { name = "settings" } )
}.open

IOW, the description is entirely structural, and does not specify presentation.

Presentation is specified in CSS-compliant grammar:

window['name'='settingspanel'] {
   width: 500px;
   height: 300px;
   title: loadString("settingspanel.title");
}

John,

Take a look at the localization chapter, you can do that pretty easily already:

loc := Locale.current
Label { text = loc.prop("myApp", "settings") }

The CSS stuff would be nice, but is probably a higher layer. Although I'm not sure how desktop apps like an IDE is really all the well suited to HTML style sheets. In general layout is determined automatically by the layout managers and relying the OS for "styling".

It's true that cross-platform windowing toolkits often use layout managers, but most OS native toolkits do not. The size and position of elements is specified precisely, usually with the aid of a GUI designer, and this approach results in the best-looking user-interfaces.

Web 2.0 has shown you can do a really nice job designing interfaces with CSS and HTML, and desktop initiatives such as Mozilla's XUL attempt to leverage this power on the desktop.

But the larger idea is to pinch off from a windowing toolkit exactly those things that are ill-suited for both software developers and general-purpose languages, and package them into a dead-simple, safe grammar (like CSS) that can be used by non-software developers -- and in the long run, by visual tools, which allow artists and interface designers to work in the language they understand best.

Why do most windowing toolkits structure and present user-interfaces wholly in the target language? Quite simply, because they're written by programmers. :-)

Of course, all this may be beyond the scope of Fan's smaller ambitions for supporting cross-platform user-interfaces. I just hate to see another programmer-centric WTK, even if it looks as surprisingly nice as your examples suggest it will look. :-)

Virtually all my experience has been building desktop UIs that require localization, which definitely are more robust using layout managers to deal with various text widths. But the CSS style is nice, but I still would approach that as a higher layer if we were to do it. At this point in time the future merging of browser and desktop is a bit fuzzy to predict, but I think it is coming. For example I really would like to experiment running Fan on one of the browser VMs like Taramin in which case these worlds would merge (but my time doesn't permit that right now).

One of Fan's primary design goals is to use the same syntax for both declarative data and imperative code. UIs are really well suited to this model so that we can just us OutStream.writeObj and InStream.readObj to serialize a UI form (either hand coded or generated by tools). There is one thing missing from Fan's serialization that I still need to tackle to fully realize this (a future post).

True -- such a layer could always be built on top, although there's something about the declarative nature of Fan that seems like it would beautifully fit a full separation between structure, presentation, and localization.

Anyway, looks like someone stole my idea:

http://tk-ui.sourceforge.net/index.html