Friday, July 5, 2013

Is stdgui really necessary?

So before I begin coding stdgui, I really want to make sure I'm not reinventing the wheel.  I constantly struggle with not-invented-here syndrome and thus I'm suspicious of my motives for creating yet another GUI programming tool.  So here is where I'll exercise a little discipline and actually force myself to experiment with stuff that's already out there.

Let me try to summarize my primary goals with stdgui:
  1. Programming language independent.  Write your app in your favorite niche language.  (Very few C functions to create bindings for.)
  2. Native rendering.  Your GUI looks and feels at home.  Widgets are implemented by the native toolkit (GTK on Gnome, Qt on KDE, OSX, Windows).  No recompile necessary if OS+architecture stay the same (very important for ease of distribution on Linux) .
  3. Rapid Development.  I'm lazy.  I don't like boiler plate coding.  I want to focus on my application logic, not the idiosyncrasies of the native GUI toolkit or bridging from the toolkit to my chosen programming language.
And what am I willing to give up for something so broad?
  • Power and flexibility.  Just the essential widgets.  No support for tweaking fonts, colors, pixel sizes, etc.
So, does anything out there come close to this?  Perhaps these:
  1. Mozilla XUL?
  2. wxWidgets using XRC files?
  3. Lazarus?
  4. Tk?
  5. Qt using QML?
  6. GTK with Glade XML?
So I'm going to experiment with the above and report my findings.  Others that were ruled out were:
  1. UIML: excessively abstract. Nobody seems to be using it - only a java implementation was found.
  2. UsiXML: "The UsiXML Project has ended in March 2013".
  3. Microsoft XAML.  Windows centric.  Tied to .NET.
  4. Here's a helpful comparison of user interface markup languages.

Stay tuned.

No comments:

Post a Comment