Occasionally, I have a good idea. I think this was one of them.
The idea is simple: integrate the ease of traditional graphical gui development (ala Glade, QTDesigner, Visual Studio, Delphi, etc.) with the rich, mediagenic, magazine-like layout of the web. Right now, developing a GUI application for the web takes on one of two flavors. (1) By far the most common approach is to have a designer roll out a GUI and then let the programmers slice it up into tables and hand code each button painstakingly (if not downright lovingly) into the layout. (2) The other approach follows Google's AWT concept (although there are other toolkits that do this), where the programmer can build the layout off of a designer's template. Naturally, each design flow has its problems.
Before we get deeply into analysing the current state of web GUI development, let us ask a harder question. Wouldn't it be nice if I were able to develop an application to run on the desktop that could be trivially ported to run "on the web" in a user's browser? I certainly think so. The framework that I have designed and started work on will allow exactly this to happen when it is complete. Keep this end goal in mind -- it would be a good place for web technology to reach, and the means to do so is within our as-of-yet stubby grasp.
Keep in mind that the two web GUI development methodologies in frequent use do not really eschue the good practices that desktop developers have painstakingly acquired. The most galling problem with these methodologies is that neither tends to integrates the designers and coders well, frequenly leading to critical failures in the final product. The key problem with (1) is that it is difficult to make changes to an existing layout. This will cause problems when it becomes impossible for the designer to make changes to the GUI to reflect current user feedback. Moreover, it is cumbersome on the programmers because making changes involves essentially re-doing all the work we did in the first place, but with a slightly different layout. The main problem with (2) is that it cannot effectivly integrate with normal web layout. Users expect to see a smorgasboard of media-rich content when they view a page -- with a traditional 2D gui, it is incredibly difficult to fulfill this expectation. Besides, who actually codes up GUI's by hand anymore? Hard-coding GUI's is both incredibly tedius and extremely difficult -- much like gouging a spoon into one's own eye.
So, the case is clear: writing a good GUI for the web is both difficult and innefficient. We know what would make the situation better -- the tools are sitting there in the GUI developer world, scoffing unbelevingly at the web developer world. All we need to do if figure out how to leverage those tools to the best effect; this I have done.
As an example take the Glade->GTK->GObject->GDK development flow. Glade produces a portable xml description of the GUI, independent of programming logic -- the ideal designer's playground with all the sharp edges rounded off and dangerous programming logic sheparded gently away. GTK implements the GUI, independent of layout, protecting the developers from the savage reality of user interface. GObject mediates the discourse in whatever language the developer chooses -- the application logic dangles off of GTK like a ripe fruit; not some specific fruit, but whatever fruit most pleases the developer's discerning eye. GDK sits at the bottom, doing all of the hard work: handling events from the user and handling output from the program, everyone's new best friend.
At this point, you are probably saying to yourself: "You fool! The Model, View, Controller topology solves all of these problems!" You would be correct: however, I would reposte that the View part of this topology is essentially optimal for "web layout" -- the magazine-like picking and placing of content. Integrating a GUI in this framework, as we have learned, is a painstaking process.
So what do we need to do to our View to be able to embed a rich, featurful GUI experience into our already rich and featureful media-zine experience? First, we should expound on how we can implement the GUI development cycle.
Glade is good, we will leave it alone: it is portable and, most importantly, already implemented. On the other side, the "GDK facsimile" renders to the browser itself -- it already has a richer and more featureful text, rectangle, and pixmap rendering environment than X. Although the event loop has been thoroughly borked by history, it certainly provides us enough functionality to eak out an interactive experience. Certainly, there are portability issues between platforms, but these are nothing compared to what the real GDK deals with: it runs on Windows and X with the same source base. So the new GDK becomes essentially a few small wrapper scripts around basic browser functionality.
GObject is trickier. As a first iteration, it is trivial to just dump your event handlers in javascript on the page -- this will "just work" and is more than enough to implement a new application. However, when we leverage AJAX, we will be able to do much more; specifically, we will be able to remotely control any glade based GUI application, our stated goal. This work is still a ways off, but it is most certainly coming.
We have yet to discuss the real meat of the issue -- GTK. GTK provides the widgets that build our user experience. The question I have asked myself: is there a way to leverage GTK directly? Unfortunatly, there is not; however, we can take advantage of one thing -- their proven good design. Thus, the toolkit I have been working on leverages the same widget hierachy that GTK uses. There are some very interesting technical details of doing this in Ecmascript -- I will go into them as I have time later.
This work on implementing a GTK-like system on a browser is worthy of note in its own right. Consider the following code snippet from my "hello world" application:
function on_hello_click( data )
{
data.SetText( "Hello, World!" );
}
var g_window = new StkWindow( 'g_window' );
var g_buttonHello = new StkButton( 'g_buttonHello' );
g_buttonHello.SetClickHandler( on_hello_click, g_buttonHello );
g_window.Add( g_buttonHello );
g_window.Show();
Building a gui app with these tools should be pretty easy. Moreover, it has the advantage over other tools, like Google's AWT, of not needing to be compliled from another language. The feature it losses is the syntax checking from some other language with a stricter grammer. I think many people will appreciate this method more because it simultaneously: has zero tooling, can use all of your favorite javascript hax, and integrates with your site as easily as any other snippet of javascript. When we add Glade to the mix, no longer strictly needing to write our own widget hierarchies, the combination is almost unstoppable.
At the moment, I am calling this project STK in homage to SophistMonkey - our web layout framework from whence it grew - and GTK, the project that has inspired its design. The translation layer between Glade and STK, naturally, is called Slade. These projects do not have a web presence yet - they will be located on http://www.trainedmonkeystudios.org/ as soon as I get around to setting up a virtual domain, not that they are ready for any serious public consumption yet anyway. For now, drop me an
email or leave a comment here, if you are interested. I'm curious to see what people (and you in specific) think of this idea.
-Terrence
