What is a GUI Engine ?

Because I develop a commercial product which I often refer to as a “GUI Engine”, I thought it might be interesting to discuss not only what I personally feel constitutes a GUI engine, but also some things a GUI should be, while some other things it should not be. I like to browse the internet to see what I can find which developers call a GUI engine and I have found a number of such tools.

First, I don’t think a “Skin Engine” should be called a “GUI Engine”. Call it what it really is !

A skin engine simply displays the same old user interface (buttons, listboxes, comboboxes), but with a different look. I like the results of some skin engines and they can add some “spark” to an application, but they are simply just a skin engine and don’t add anything new to a user interface. A button is still a button, albeit a little prettier.

Now a GUI engine is different !

GUI stands for Graphic User Interface. Consider the word “interface”. Interface means a sort of connection between the user and the software. To illustrate, a steering wheel on a car is an interface. It allows the user (driver) to control and manipulate the machine to make it do what the driver wants it to do. Now does a skinnned button make the user any more productive in any way ? Not really. Now if the button is made to stand out in some way so the user is quicker to realize what the button does, then its appearance does make a difference. Compare a software button control to a real button on a machine. Most machines in a factory have all sorts of buttons. Does making them prettier make them more useful ? Absolutely not! Now there are two factors which make a machines button more useful. One is size (easier to see) and the other is color (colors have real meaning in the real world). The color red on a machines button can have real meaning (stop buttons are usually red).  Green is often used on machine buttons to indicate a start button (or ON). Buttons which are more important on a machine, usually are bigger in size so they can’t be missed.

The point is that in the real world, a user interface benefits from simple things like color or size and some times shape, but they rarely if ever benefit from simply making them prettier.

So why should a skin engine be viewed as a “user interface” engine of sorts. Call it what it is, a “skin engine”.

Now in the real world (ie. machines, electronic devices, etc.) another aspect of a user interface is how things move, feel and visually appear. For example how a control moves (a machine control) can be important. There are sliders, toggle switches, buttons, etc. In software its the same. Notice the commonality among controls, no matter the operating system. There are button controls, slider controls, scrollbars, listboxes, etc. It is how the ‘work” which is important. Also appearance is important if it conveys a message. For example an LCD display which displays numbers (digits) is oh so useful in the real world. We have clocks, timers, counters which all are simple digital displays, but yet very important.

With software a GUI engine must deal with those real world aspects of controls which convey a message to the user or allow the user to convey a message to the computer (software). Its quite mundane when you really think about it, but yet it is very important. A GUI engine should give you complete control over the interface, even over the seemingly mundane things. A GUI engine does more than make an application look pretty, it makes an application useful.

Functionality is the key word here. Its the simple things that sometimes are the most useful. For example, I am working on the 5th generation of my commercial GUI engine and while it has many exciting new features, I was amazed when one user got real excited by a simple feature I added which was private timers for controls. Each control could have its own private timer which would fire an event at specific intervals. It took about 50 lines of code in the GUI engine to impliment this feature. Because I was already subclassing all controls, I was able to add some timer code to each controls window procedure so each control could have its own unique timer. I called them private timers, to differentiate their purpose from normal timers. This concept was not a big revelation in software development. What made it so exciting to the user was that it was oh so useful!

Thats the point!

A GUI engine must be useful, even if much of it seems a little mundane. Functionality is the key.

In one of my videos (see my web site for my video channel) I discuss a key concept to my GUI engine, which I refer to as being “task oriented”. Often developers of programming tools write API’s or wrappers of existing API’s. True their is a degree of functionality in such API’s. But how often do developers of a GUI engine design it based on real world “tasks”. Some tasks are simple and may only require a small amount of code and a few calls to the Windows API. Other tasks may be very complex and may require hundreds of lines of complex code. The key is to design a GUI engine based on “tasks” and not API’s.

Another concept I discuss in one of my videos is the concept of what I call “building blocks”.

A user interface may need to be more than the simple components found in Windows. If software must relate to some real world task, then often a developer will need to be creative and find a way to emulate the real world task in a software model. Once in the old DOS days, I had to write a custom application for a large company which was for tracking a large PBX (phone wiring) system for a really large complex. While DOS limited what you could display on the screen, I found a way to use a bunch of the block characters in DOS to visually emulate a real PBX system with all its patch cords. What the user saw in the real world was simulated on the computer screen. I had to create a unique user interface which was visual. It was not a matter of whether it was pretty or not. It was a matter of whether the users could understand what it represented and whether they could control the interface in a way that made sense to them.

Often user interfaces in the real world are created based on the need and the task at hand. You can’t always use a “stock” interface. Some times you have to create something new and unique.  The same holds true for software! A GUI engine should provide you with a limitless number of possibilities, by providing you with as many “building blocks” so you can build almost anything. Thats the concept behind my GUI engine. For example I added a Sprite engine to a Canvas control which I had written in the GUI engine. Some at first glance thought, “was I now making it a game tool ?” The answer was no! I found that a Sprite engine allowed users to create all sorts of animated controls which could emulate all sorts of real world tasks. In the real world often you need “parts” which can move, change shape or color and which can be tracked in their position or state. Sprites can emulate the same need for software.

So a GUI engine is not a skin engine.

A GUI engine is not a game engine (a game engine is for making games).

A GUI engine sometimes does a lot of mundane stuff.

A GUI engine is for building user interfaces which can emulate real world tasks, so it should provide all sorts of “building blocks” so you can build almost anything.