Slashdot Mirror
Resource-Based GUIs Vs. Code Generators In Java
Java Fan writes, "There is a good debate about GUI generation tools for Java going on at theserverside.com: 'Almost every platform has a visual designer that serializes the GUI to resources (some XML, some proprietary binaries) and then attaches it to the controller at runtime. Apple has had this for years with Interface Builder, Vista has a similar philosophy now as well. Java developers though are left with either hand coding of GUIs or potentially messy and brittle code generators. Neither of which promote good MVC separation. In fact they tend to encourage violations unless you are a very disciplined coder.' Personally, I am partial to BuoyBuilder as a great solution to this issue."
Who can smell the coffee?
We started a project along the lines of Interface Builder with a Java Swing implementation for our master's thesis in 2005. It's called GINAC, as in GUI Is Not Application Code.
As I really hate designing GUI's in code, I've started working on it again lately, currently implementing something along the lines of cocoa bindings. If anybody is interested in helping out, let me know!
I've never been a big fan of run-time loaded UIs, always preferred the code-generators instead. It just feels better if you can see the code that's going to run, and if you're using a lot of custom components it's more flexible.
Juce and its "Jucer" UI builder is my favourite for this stuff - it generates c++ code with comment-tags for squeezing custom code into the generated sections. A particularly cute feature is that a Jucer document is just a compilable cpp file, with all of its UI metadata stored discreetly at the end in a commented-out block of XML.
Possibly Java's greatest strategic feature is the classloader that can dynamically retrieve classes across the network at runtime and safely instantiate them. If Java had a standard API and data format for de/serializing UIs that accommodated their remote contexts, applets could become much smaller and dynamically bound to the UI facilities of their arbitrary runtime platforms. If these mobile UIs were componentized with a consistent internal API, applets could share UI elements among themselves on the same host. That architecture would not only reduce distribution size and increase flexibility, but it would promote reuse of the same UI components across applets, increasing user productivity with fewer learning curves.
If those APIs don't already exist, reusing an existing one, especially Flash, would offer possibilities for reusing existing components or patterns already populating the Net.
Java could increase its stature among distributed architectures. And make our lives easier.
--
make install -not war
> Apple has had this for years with Interface Builder
Presumably NeXT has had it for even longer, a couple of decades or there abouts. IB was written by a brilliant French coder as I recall... he was a friend of a colleague. Short of firing up my NeXTBox does anyone remember more of the history?
I find IBM's AUIML to be an amazingly good solution. You can design the GUI with a visual tool and write code that runs in Swing as well as in a web server (as a web or portal application). Here's a link to AUIML page on AlphaWorks: http://www.alphaworks.ibm.com/tech/auiml Download seems to be outdated at this time. Look for version 6.x if you want to give it a try.
The Java-Gnome Project uses Glade to build a serializable (to XML) GUI.
I'm guessing you really mean GridBagLayout, since GridLayout is a different and very very simple layout.
I realize GridBagLayout is hard to learn, but over the years I've learned that you cannot avoid it.
Sun has tried three times to make a "simple" replacement for GridBagLayout. Each attempt utterly fails as a replacement (but each is useful for some other rare types of layout needs).
I've tried to make my own "simplified" version of GridBagLayout too. In fact, I suspect nearly every intermediate Java GUI programmer tries this at some point; it's almost a rite of passage. And it's always a failure. The reason is that UI layout simply is that complicated, and there's no way around it. If you think it's simpler, then you probably aren't aware of all the issues involved.
A UI builder won't make it any simpler. It will just make it easier for you to ignore the issues. The usual result of such "freedom" is that the resulting UI looks acceptable, but doesn't have acceptable behavior. For instance, to pick a simple case, a scrolling list doesn't resize when the window containing it resizes.
The Internet is full. Go away.