Slashdot Mirror

UIML is a subset of the XML-language for implementing platform- and programming-language-independent user-interfaces.

Maybe you should have a look around, whether there is a good UIML-renderer for Java.

If your research is into this topic, you may even want to develop a UIML-renderer for Java yourself! I'm sure many people would be interested in an open-source project with this aim.

I am using Qt (with C++) and qt-designer myself, which is using a proprietary XML-format for rendering user-interfaces (ui-files).

References:

UIML-tools

Qt-Designer

Qt user-interface renderer

Mozilla user-interface renderer

Yes, this is a key area where I think de Icaza has a problem. He's clearly planning on implementing Winforms (I checked on the Mono site) and those are not part of the ECMA C#/CLI/CLR spec. Microsoft will not permit those classes to be cloned - its already dropped strong hints about it.

Hmm... If I was Miguel I would take a different route to avoid this problem - I would create a UIML based tool that would generate code for both Winforms (on Windows based platforms) and Mozilla XUL for everywhere else (and your little Windows too, deary!) Plus UIML is a handy intermediate form for other forms-based UI platforms, such as Java Swing and HTML. Just standardize on Javascript for the local scripting needs...

Personally I think UIML is a damn good stab at creating a standardized common syntax for cross-platform UI design. Given a couple of revisions to add scripting capability and a decent event model it would rule (if enough tools supported it). And I like this kind of general approach a lot more than I like the idea of emulating MS Winforms.

Jack William Bell

The XML implimentation I was thinking of is UIML.

There are a couple of systems that already exist. XwingML builds Java Swing interfaces from an XML specification. XUL is a similar XML-based markup supported by Mozilla. XForms is the W3C's draft standard for the next generation of web forms.

Most particularly you may want to look at UIML, which is intended as a cross-(viewing-)platform markup, supporting PCs, PDAs, etc. There is a Java viewer, and the new version seems to have some renderers for WML and HTML, but a text renderer should be possibe (if not already available).

There are several other lesser-known XML-to-GUI toolkits, such as KUIL and AUIT. Most of these are implemented in Java and map the Java Swing classes into XML (as with XwingML).

To suggest LaTeX or other page layout that is not as complete as postscript or pdf, is to trade the language, not the problem.

The popularity of HTML is that it is easy to learn the basics and rich enough to do very complicated formatting. Eventual HTML standards may approach TeX 3.14159 with things like MathML, Style-sheets, etc. However, there will always be vendor specific problems. For those who look at my web page, I made it in 30 minutes with vi. I do have a very good working knowledge of HTML.

XML may be a way to go. As an XML programmer, I enjoy the fact that I have lex and yacc built in with XML, though I don't like the bloat. The project UIML makes the point I am trying to make. The interface should be easy to use such that any graphic designer can use it and those of use who code and hate doing UI can go about coding something real. Keep it simple yet rich. Avoid scripting et al.

Anyway, back to work on what my web page describes.

PerES Encryption

User Interface Markup Language is a device independent way of creating interfaces. For instance, UIML intefaces would display as well on a Palm as a desktop. XUL (Extendable User-interface Language) for Mozilla is another effort. Orbeon is working on a project called Albatross which is to be a GUI for all browsers. Thanks to the folks at ShouldExis t for these links.

My Company has been considering UIML. UIML is an XML dialect, designed for specifying interfaces for multiple different platforms, machines, etc. It is then either compiled to native code, or loaded at run time and interpreted. Similar to libglade, and such, but potentially much more powerful.

Potential drawbacks are that it is still young, and may not develop enough momentum to carry on. Also at the moment there is only one Renderer, which is java based. What we have been doing is rendering the gui in Java/AWT and then using JNI to call our existing C++ code. It has been working fairly well, although I wish the renderer offered more complete support for the spec.

All in all though, I think it is a good way to go.