Home

NOTE: Development on this has been stalled by other projects. It WILL resume, but I can’t be sure exactly when.

It’s probably best to read A Bit of History first…

Experimental!

This is purely a POC/Experimental repo so far. GX aims to be:

• Easy to learn
• Fast to develop with
• Fast in use

Since GX runs as a fairly thin facade layer over the top of wxErlang/wxWidgets, it’s mature, cross-platform, and has 100% native look and feel (Windows: ok, well it will in R13B as werl 13A and prev was missing a crucial windows resource file).

Issues

There are a few major issues left to resolve:

• Some composite components are missing from wx, and so are not available in gx. e.g. split windows.
• Need to add most of the property getters/setters, aka read and config for dynamic interaction.
• Now that gx is a gen_server, I’m wondering why not talk to the port direct?
• GX requires SMP enabled as the underlying wxErlang graphics server needs it. Apparently, this is owing to the fact that wxWidgets has to run in a separate OS thread, a bit like Java Swing’s single-threaded rendering model that forces you to schedule your UI updates on the “Swing Thread”. Maybe every app will end up being SMP…
• Frame furniture must be defined first (menubar, toolbar, statusbar) or the wxSizers simply don’t work right. No amount of coaxing of the top level window appears to make the “special sizer” of the top level component understand that it’s got more than just the virtual window size to cope with – hard to tell whether this is the erlang wxe port or in wx itself right now…

Some ideas

• GXML is by far the easiest way to code up an interface. To make this familiar, I have, perhaps controversially, based the xml syntax logic and attribute naming on HTML 5.0 (but with different elements of course). To “hide” the definition from prying users for a release application, it’s simplest to just generate the equivalent term defined by your GXML and copy/paste that into the code. To get the term use gx:gen(XmlFile), which writes a GUI term file to the current dir.
• I may create a “gen” function to write a skeleton erlang source file that has the event stubs in there too.
• It may be possible to check at load/create time that all callbacks defined for the declared UI components are implemented in the module. Currently this check is done late, on the fly, when the event loop needs to check for any callback handler.
• An XUL interface? Hmm well ok maybe. I don’t like XUL/XUI/XRC too much though as they are overcomplicated because they don’t respect the value of the element/attribute boundary; and they are hard to use as they breach the fundamental contract of human/machine “readability equivalence” that markup is supposed to bridge.
• I’m tempted to explore using erlang:make_ref() to provide consistency over remote connections…