How would I describe today’s GUIs? A mess. — A mess that grew as new features were needed, with lack of proper design, with a desire to keep backward compatibility, and with tools from the past trying to achieve future needs. I propose a new design philosophy for GUIs. We’ll call it Vermaden’s GUI. Note: This is the latest entry in our 2008 article contest.
At the beginning they were designed, but as time passed by they just grew. Most of today’s GUIs use a grid of dots on which other GUI elements are placed: menus, buttons, lists, draw areas, folder lists and everything that you can imagine. Today’s GUIs, such as GTK or QT toolkits can do almost everything we could want from a classic GUI — the problem is how all our wishes are realized under the hood of the interface. Speaking precisely, lots of different types of content, different combo boxes, different margins, borders … Many widgets have a scrollbar included, some need external placing of the scrollbar, or even two of them if we also need to scroll horizontally, like Anjuta’s IDE GUI for example, some scrollbars are outside widget content, some are placed inside content.
Anjuta IDE Created with Separators
Displaying a lack of unification, today’s GUIs are not coherent. They are like a big bag of tricks that try to get the job done. The Nautilus File Manager, which, similarily to Anjuta, uses the GTK toolkit, “prefers” putting scrollbars inside widget content area, where Anjuta puts them outside. Some of you may say “what about QT?” Well, things are not better here; let me tell you why with Konqueror as an example: a widget with folders on the right has a border, a tab with that widget also has border, which also includes a status bar in the bottom part of the window … again with the border, don’t you think that there are too many borders around there? Well, you are not alone. It’s big waste of space and functionality (which border would you like to resize today?), not to mention ergonomics.
Nautilus File Browser
Konqueror File Manager
Of all available GUIs today, Apple’s Cocoa used in their flagship operating system Mac OS X is a jack-of-all-trades and looks better and more coherent then the two I just mentioned from the open source world, but it still has quirks in many places. Those quirks are not its major disadvantage though; the license is. It is a proprietary product that you cannot modify or even use without buying the whole Apple computer and even if you do you cannot use it as a GUI on your favorite UNIX system, like FreeBSD for example. You can only watch from a distance.
Apple’s Cocoa in Mac OS X Operating System
Under the Hood
Maybe these are just minor issues with displaying the content, and maybe these GUIs have brilliant design, but I must disappoint you even here, because there are architectural problems with some GUIs. QT for a great bad example, requires that to change your theme you need to compile it (!) among hundreds of libraries, which makes porting it to other operating systems almost impossible. That is why there are many themes for QT/KDE that work reliably only on Linux, where they were created.
GTK is a lot better here, where with a proper display engine installed, Murrine for example, you can have whole theme and colors in one simple gtkrc file. The idea and simplicity is great here, but as I mentioned earlier, GTK suffers from other display problems, like coherence of its GUI widgets.
Speaking in general, some GUIs use absolute positioning, where for example menu goes at x=0 y=0 position, status bar goes to bottom x=0 y=end_of_window, some use boxes for widgets, boxes with borders, or just plain borders, something like “containers” idea, but very limited and no matter how many methods today’s GUIs use, its all about dividing the window space into buttons, menus, status bars and so on. So why not make it the rule of the GUI, the core of the GUI?
I propose creating a whole GUI by separating the available content in a simple, sensible manner, managed by one simple efficient mechanism or algorithm responsible for efficient usage of available window space, responsible for placing all window items. Does that sound interesting?
Divide and Conquer
The central concept of my GUI is separators: one simple mechanism that can be tweaked to perfection without much hassle and time. An application window is nothing more than a small piece of workspace divided into small places with different roles. An example of this with separators used as GUI formatters is a simple window with buttons on top, status bar, small container on the left for list, and of course a place for main content, for example many window managers use a similar setup. To create that window we need just one recurrent function to draw whole GUI skeleton, one simple function.
Example Window Created with Separators
A well thought-out idea can be ruined because of bad default settings. By default every content that will be placed in any container created by the separators is horizontally and vertically centered, with 1px border of free space between the content and separators, and if the separators are transparent, 0px border between content and separators, but transparent separators themselves serve as 1px borders.
1px Border Between Widgets in Containers
Using this rule there will never be a problem that any of the GUI elements will interfere with each other. As in the image above, these design rules, or should I say defaults, prevent future creators from one of the most common GUI faults: wasting window space with needless borders and margins, doubled borders, big paddings and so on, like 5px margin between content and scrollbar in Anjuta’s IDE.
Sonata with Design Errors
Sonata Skeleton Created with Separators
Sonata Created with Separators
As you can see on image on the right side, Sonata can be easily recreated with separators and containers without losing any functionality. It also leaves a lot of space for options, margins and padding, around text for example, and all widgets are in their place, and, just as with the GTK toolkit, space is just better organized and less exposed to design faults.
So what about those ugly scrollbars that are so hard to place properly? Well it is more simple then you think. Every container has its own scrollbar placed, yes, in right place, and of course it can be turned on or off, or put on any side of the container, maintaining flexibility.
Container with Automatically Added Scrollbar
GUIs are about drawing graphics and text on the screen, and in my honest opinion it would be best to keep all configuration and data in XML format. It is a fast and easy to parse language, and many minimalistic window managers use it to store their configuration, like Openbox or Firebox, for example. XML is widely known and well supported. It has served many times as a GUI formatter so it is also proven to deal with GUIs efficiently. Its also very simple, with no bloat or needless options in it. XML format seems almost a natural choice here.
But enough about configuration, settings and generally storing text data. What about the graphics themselves? Well, the answer is more simple then you can imagine: SVG. Yes, my friends, Scalable Vector Graphics is the best choice here. It has tons of advantages, along with the option of being animated and they are stored in … stored in XML format, another place where we have great unification, everything stored in one format, configuration, settings and all graphics. We just need one tuned parsing engine for graphics, text, separators, settings … everything!
Those who browse web pages a lot know good that increasing web page content size with images makes those images dirty and pixelized, but using SVG graphics we are not limited to one selected or designed size: we can size everything as we want keeping the best possible quality at the same time.
SVG and PNG Files Both Scaled to 400%
Using XML format for everything leaves a lot of places for optimization. Tweaking one engine improves the performance of everything, since everything is parsed through it. That is the whole idea of Vermaden’s GUI — unification of everything with inheritance in mind multiplied by good defaults. By having everything simplified and stored in one format, the optimization process focuses on optimizing one parsing engine and one display/drawing algorithm. Moreover, fixing bugs should be easier since you have to cope with one or two things instead of hundreds of modules like in the Apache Web Server, for example.
But I Want Options
The separators idea leaves a lot of room for customization and settings. For example, we do not need to set every container setting; we just set border to 10 pixels width for one container and all containers that are in that container inherit its settings. If we want to tune some of them, we also have no problems doing that. We can align everything as usual: top, left, bottom, with inheritance of containers it will be simple and efficient.
As you can see we have all the options that all other GUIs offer, but we can do much more in much less time, with coherence and simplicity.
My GUI design concept solves most (if not all) current design and usage problems. It’s fast, efficient, easy to scale and tweak, ergonomic, uses open and well documented standards such as XML or SVG images (also based on XML). This design is simple and clean, everything here is cut to parsing XML and using one simple algorithm to draw a GUI using Separators and Containers. At the same time with inheritance of settings in mind everything can be tweaked for anyone’s preference.
So let’s summarize Vermaden’s GUI in pros and cons:
- Everything based on the idea of unified separators and containers
- All data, configuration and graphics stored in XML/SVG format
- Drawing of the interface involves one parsing engine that parses everything
- Interface is scalable because of SVG graphics and containers idea
- Its extremely fast to parse XML content so its also ultra lightweight
- Ensures that theme/GUI does not have design flaws
- It only exists on the drawing-board. Somebody needs to implement it first
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.
You might want to check out Adobe’s Flex/AIR. Views/components are defined in XML, with CSS for styling (optional, you can also set properties in the XML). Everything is object oriented so you can create fully re-usable components that inherit behavior from a base class. Flex has a built-in vector graphics engine, thanks to the flash player, but also supports SVG natively.
I am not at all sure what you are on about with your “separators” idea. What you describe is simply nested containers with specific layout. Just about any GUI toolkit will allow you to do this. In Flex you can next Box, VBox, and HBox to get just about any layout you’d like – and the scrollbars behave as you want as well. I really don’t know of any GUI toolkit where the scrollbars are external to the content.
If you don’t like the way Flex’s native containers layout, you can simply override the method that is responsible for child component positioning – and create your “separator” – whatever that is.
Additionally much of Flex is open source. It’s cross platform (both the Flash viewer and the Flex development environment run on Windows, Mac, and Linux). AIR (for the most part) is Flex with a desktop installer, HTML widget, local “micro” database, local Flash player, and special classes that allow local file system access.