A Bit of HIstory

GUI programming is traditionally verbose, laborious, tedious and boring.

When I first saw Erlang’s GS interface, it was a revelation. Simple, fast, and easy to learn. Unfortunately, it suffered from LLC (looked like crap).

With wxErlang (wx in R13A as of March 2009) we have an interface to a mature widget set that does not LLC. Unfortunately, it suffers from the fact that coding to it is verbose, laborious, tedious and boring.

GX is an attempt to bring the good stuff of the interface (GS) and the implementation (WX) together to make a pleasant framework to build UIs in. “GS” over “WX” is why it’s called GX (and it’s only two letters to type).

However, there was a roadblock. Complex UIs using vanilla GS means you enter a brace-matching hell. Hand-coding complex terms (at least, for me) very soon becomes a frustrating exercise because of this. Using XML makes this part much easier, so I added GXML as a prototyping/definition language that was easy to write.

To simplify things further from a coding standpoint, I made the GX naming for Components and Options in term format exactly consistent with the XML elements and XML attributes in the GXML markup. HTML event names are familiar and easy to remember for most people, and so I decided to carry over the event type names from HTML 5 into GX.

Having gone down a road or two, it became obvious that the use of named callbacks in the GUI definition fed to GX would make it possible to use callbacks exclusively; calling direct to the core logic functions, instead of requiring the client to maintain an event loop and do that part of the event type filtering. This idea worked out and GX is now on the way to being even simpler to code with than the original GS.

The entire intention of all of the above is to make the learning/relearning time for using GX to build professional GUIs as close to zero as possible. I hope that it will at least come close.