The IBM Reflexive User Interface Builder (RIB) is an application that constructs and renders graphical user interfaces (GUIs) for Java Swing and Eclipse Standard Widget Toolkit (SWT) based upon a descriptive XML document. Arranged in this way, RIB can create and render GUIs based solely upon the information in an XML document. See new developer article on RIB that shows you how to Build Java GUIs simply and quickly.
IBM provides RIB tool for Swing and Eclipse GUIs
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I wonder what advantages it has over Jelly though. i suppose I could read the article.
All very well, but why do Java applications have to look for ugly (see their screen shots)
That’s just what the world needs, another XML scripting language.
Sigh
When will people learn that xml is not the answer. How this is supposed to improve developer productivity is beyond me. It looks like it might be useful if it had a stable API (which is doesn’t since it’s based on reflection) or a tool for generating xml documents. Which is also doesn’t. Most xml tools are not very useful without a dtd/xml schema document except for validating it.
How exactly is this useful?
Looks like a great way to inflate the lines of code you have to write to make a Swing GUI. Good if you’re getting payed per LOC I guess. XML is so goddamn verbose, unless you have a tool to autogenerate all this crap I’m not interested.
If you can’t see the time and space saving qualities in creating an interface using markup rather than complex layout managers and clumsy objects, then you haven’t written enough GUIs in the first place. The way that XML defines and nests components is inherently useful for composing GUI layouts (and requires significantly fewer lines of code).
This is the future of GUI programming folks. Just look at how Microsoft is planning to use XAML in Longhorn.
If you can’t see the time and space saving qualities in creating an interface using markup rather than complex layout managers and clumsy objects, then you haven’t written enough GUIs in the first place.
Actually I have written quite a few GUIs. The advantage of markup based layout is in its flexibility. You can change the GUI, or at least change the way it looks, without recompiling the program.
The fact that you call layout managers “complex” and objects “clumsy” makes me think that you are the one with little experience in GUI development.
The way that XML defines and nests components is inherently useful for composing GUI layouts (and requires significantly fewer lines of code).
How does the structure of XML make it inherently useful for GUI layouts? So you’re telling me that 123 lines (the length of the first sample) is short to make a GUI with two text boxes and two buttons? C’mon, write it in straight Java/Swing and you’ll use half the lines.
XML defined GUI’s have some advantages, but using less lines of code is definitely not one of them.
I remember, vaguely, some product called koala or something that does some of the same things RIB does, XML or some hypertext scripting language to help generate Java swing apps.
Actually, searching on the web i came up with a few links:
http://koala.ilog.fr/kuil/
and also:
http://koala.ilog.fr/kbml/
Leo, Java’s competition (.Net) has XAML so this is necessary, if only for marketing comparisons.
And XML is a good choice because web designers are used to that sort of markup.
I can see several advantages in parsing XML to create GUIs:
If done right, designers can restructure the whole GUI without needing to recompile the application. The approach also encourages to separate front-end and back-end.
Translators can tweak the layout where necessary without recompilation. (Translations are typically done outside the coding company.)
The application can more easily be provided as a web service. Think XUL or XAML.
not only koala, what about the various XUL dialect?
http://xul.sourceforge.net/
Reminds me of Motif resource files. With Motif you have the choice of coding the GUI or specifying it in a resource file – a text file. Or mix as you please.
A resource file contains lines in the format
a.b.c=value
I haven’t looked – maybe the same now looks like this
<a>
<c>
value
All very well, but why do Java applications have to look for ugly (see their screen shots)
<p>
Java SWING is designed to look different from your native GUI.
Thus it is ugly on purpose 🙂
If you build a cross platform GUI toolkit, you have to decide how to behave.
Do you behave like the natives? In that case you can do some things on GUI A but not on GUI B.
If you look like a native, everyone expects you to behave like a native. If you don’t the user gets surprised or even frustrated.
Because SWING does not behave like a native its designers made it look not like a native. You see SWING is different and thus you are not surprised that it behaves different than your native GUI.
SWT of course looks like a native, and behaves like one.
many years on – i still dont’ see why everything has to be converted to xml, other than to please marketing
While it is true that xml has become a buzzword, it is actually really good at describing data with a structure, so it is not strange to use xml to describe guis (after all they are *things* in a layout, just like formatted documents and web pages are)…
…just asking. Why is Swing even still in existence? This would be _SO_ much more useful if it popped up some native widgets instead of swing.
It may have been around 1997-1998, but there was a company that promoted the same thing for Swing/JFC (I want to say the company name was BlueBird or something like that). I tried it out and it worked for simple flow layouts, but when you started to do all the action listener additions and mouse this, mouse that, menu this, menu that, it really became quite verbose and more difficult to manage (the latter could just have been a me needing to get use to it thing). Nevertheless, it’s nothing new (as someone pointed out with regards to motif configs), but it’s always fun to reinvent the wheel in a slow economy.
First off, I am not a Java developer, but this dicsusson extends beyond that. I have experience with (D/X)HTML, Glade, and W3C XForms, and a little XUL for XML-based user interface markup. XML is becoming a *common* serialization format for object graphs. XML for user interfaces is not an XML “scripting” language, and should not be viewed as such or considered for that!
The advantages of XML are that it is common and equally-well consumed by both human and machine. I don’t want to re-orient my brain for each new text format I have to deal with. It’s bad enough with too many lanugages and config file formats. So, I welcome some commonality in config files or the opportunity to not learn yet another language. However, I tend to stress the latter point most with customers or newcomers. I don’t want to use a hex editor to try to directly view or edit serialized objects when I need to figure out what the hell is going wrong and how to fix it because the tool or buggy program is in the way! Therefore, text is more accessible. Now, what text format? Due to the popularity of HTML, humans are generally more comfortable editing a tag-based syntax. Is that so hard to comprehend? Now mix in the simple rules of XML 1.0, and you have something accessible for both humans and computers–a great compromise.
An advantage of a resource-based UI (e.g. XML) is that it provides some separation of presentation from logic. For example, using an OOP binding to Glade (gtkmm, C#, Ruby, etc.), it is very nice to be able to simply edit the gui adding a signal declaration, and then switch to the code editor and add an event handler. (Using Glade’s signal autoconnect functionality). However, it is not always safe to assume you can change the UI XML to your heart’s content after code is compiled because often the static XML definition must be supplemented with some dynamic GUI code (the real world), and it depends upon object ids and/or relationships.
XML for this purpose is typically only as interesting as the tool that generates it because there are plenty of examples of it being verbose and not as succinct as maybe something done in Ruby or Lisp.
See the MyXaml project of an interesting project for object-graph deserialization and declarative programming. Now, I would like to see more discussion over the merits of more direct mappings between objects and their XML schema like MyXaml versus a more abstract schema like XUL or XForms. The former is easier to attain due to automation esp. using language metadata facilities. The latter, abstract approach typically requires much more upfront development that goes into interpretation. As things change, how cumbersome is it to adapt the former approach using adapter components or XSL-T?
I really like using XML to write/layout GUI. It may not be for everyone, so I’m not even going to argue one way or another. I’ve been developing GUIs since 1992 using VB 1.0 and have used every VB up to VB.NET and also Swing, Delphi and of course HTML. In the end I just prefer the XML way – so far XUL has been the closest thing to what I wanted, but still not quite there.
In spite of my interest in XML, I’m very skeptical of any system that is very complex – and RIB appear to be much more complex than is necessary. Their introduction application with 2 labels, 2 textbox and 2 buttons is 123 lines of code and this is not ‘clean’ looking code. One of the things I like about having the document in XML is the ability to easily read the entire layout by scanning the file – in just a second or two you should be able to understand what is going on. I like to keep the scripting separate from the layout. I also think that the layout should provide reasonable defaults so you do have to spend time telling the layout how to look. (XUL does good on both of those points).
Just by way of comparison, I’m working on my own little project as a hobby to try different XML layout techniques. Keeping in mind that I’ve only developed 10 complex forms with this, so it is very new and not fully thoughtout. Even so, my system (called CTML) only took 49 lines of code to do the same thing as RIB did in 123 and it was much easier to read mine.
You may think I’m just being obtuse, but for me text is really easier to deal with than form designers. I write all my own code whether it be HTML, ASP.NET, Java, Delphi or what ever.
why would you use this sub langauge for description when you can use something that totally abstracts GUI creation like XUL so you can plug whatever library you want in? like SWT or SWING without changing anything? hmmm. It just seems strange that you litter your XML with library specific language, etc. That should be done in the translation phase, not the coding phase! Why use Rib and not just dynamically compiled classes? or even property files? You get the same effect. Because you have to do a total re-write of your RIB file if you want to switch from SWING to SWT or any other Toolkit that comes around unlike XUL,AVALON,etc.
They mention testing and debuging but I cant see it being any easier to debug a cryptic xml syntax than the cryptic Swing or SWT java syntax! at least with SWING you get IDE GUI Design tools to help you find problems…seems like a waste of talent.
There is no excuse for SWING ugliness. We have to work with a Java application under windows and it really does look ugly. It’s the only Java app we use, but we have to use it. HOWEVER, all it takes is to add an option to the launch command line and it looks nice again. SWING doesn’t have to look ugly, its the developers who can’t be bothered to do that one last little thing during installation.
As for separating GUI specs from code, I should remid you all that Borland has been doing this since 1995/96 with Delphi. Of course they don’t use XML (since it wasn’t around then). The great advantage for me is not that I can edit the GUI spec files, but that:
1) It doesn’t clutter the main code with all the mess like make button here, make panel there etc.
2) It makes it easier for developers to write GUI layout tools, such as the Delphi IDE
Where is the graphical GUI editing tool ? I am sure a lot of pros don’t need it but it shouldn’t be ignored that the ubiquity of VB and popularity of Delphi is largely due to their easy to use, graphical GUI layout editor.
I agree that the GUI code should be separated from the main code. It can be achieved in Java although Jbuilder and netbeans (the one I’ve played with) don’t really promote that as far as I could tell….