Light at the end of the tunnel

Here's something I learned this week in the aftermaths of the (rightful) Gnome-bashing flamefest. KDE these days has XMLGUI that lets one give names to actions in C++ code, and build menus and so on that call those actions in an XML stylesheet, thus separating semantics from presentation — at least partly. In fact, Gtk has something like this too and Microsoft's XAML among all its bloat includes this kind of functionality.

To not get too excited, few projects actually seem to use these tools, and they are very far from my Vision. They are, however, the closest things to Vis that I've seen that are anywhere near "production" stage, and it is strange to note that nobody has mentioned them to me before, although various other things very far from Vis have been suggested, including even Glade, which (so I was told) does not support GtkUIManager. How GUI builders like Glade work now are of course the polar opposite of Vis, even if Vis were just a puny WIMP GUI tool, which it wouldn't be. These GUI builder tools work on the principle that the program connects to the widgets of the GUI design, while the idea behind Vis is that the program provides commands and data for the UI to connect to.

So how do these stylesheet-based tools differ from Vis? With the exception of XAML, only simple "actions" are supported, not data. This means you can only use them to build simple menus and the like, not real input that would trigger modification of program variables with values entered by the user, or display the values of those variables. (At least KDE does, however, include some special-purpose system for configuration dialogs, but I haven't analysed it at this point, and apparently it doesn't cover all cases of such input.)

Secondly, at least XMLGUI and GtkUIManager do not fully abstract out the UI from the program. They give access to widgets. That's a big mistake. Needless to say after this failure, they do not have alternate UI backends, and can't possibly properly support e.g. running programs in a text terminal.

These tools are also lack a standard naming convention, and thus it is not possible to semi-automatically generate common and simple parts of the UI. XMLGUI at least also allows specifying too many aspects (accelerator key, label) of actions on the C side.

So, while Vis is still a long way from losing its vapourware status, there's light to be seen at the end of the tunnel. It is faint even with light-amplification goggles on, although the light outside is extremely bright, for the remaining tunnel is very long. But, there may after all be some hope of the dark ages of UI design coming to an end eventually.

And, yes, XML syntax still stinks.