Quote: A meeting is an event...

Saw this in slashdot:
 
"A meeting is an event at which the minutes are kept and the hours are lost."

UI Layout using Constraints

My last post about stdgui was over 5 months ago.  Although family life has been busy I have not been entirely idle.

I have concluded that the existing GUI frameworks don't meet the goals of stdgui.  The project will proceed.

However, a few months ago I sat down with my prototype "SnapLayout" layout system and attempted to layout a simple example.  I was surprised at how much mental effort it required.  Granted, it had been awhile since working with SnaypLayout and I was probably a bit tired but I got the same feeling of tedium I've had in the past trying to mix-n-match layout managers to get the desired look.  SnapLayout is perhaps only marginally better than the status-quo.  I want a true advancement.


I started pondering: what if we could specify exactly how widgets align to each other with some sort of declarative syntax.  I came up with something like this:

---
 lblTemplate
|lstTemplate
|btnShowBanner|
---

CenterV: lblTemplate lstTemplate
Top: lstTemplate txtMessage

lblMessage txtMessage|
lblColor selColor
lblSpeed rdoSlow
rdoNorm
rdoFast
chkReverse

Right: lblMessage lblColor lblSpeed
Left: txtMessage selColor rdo* chkReverse
FillH: txtMessage

lstTemplate fraPreview|
btnShowBanner

fraPreview {
 |lblPreview
}

Here's the idea.  A block such as:

---
 lblTemplate
|lstTemplate
|btnShowBanner|
---

means:

• the top of lblTemplate aligns to the parent window top edge (---).
• the top of lstTemplate aligns to the bottom of lblTemplate
• the left of lstTemplate aligns to the parent window left edge
• the top of btnShowBanner aligns to the bottom of lstTemplate
• the left and right edge of btnShowBanner aligns to the parent window left and right edge, respectively.

I call this an "implicit block".  I think it's a pretty concise expression of intent and fairly intuitive for programmers who read left-to-right and top-to-bottom.

Next we have explicit constraints such as:

Right: lblMessage lblColor lblSpeed

which means: align the right edges of lblMessage, lblColor and lblSpeed.  Explicit constraints are used to express that which cannot be expressed in an implicit block.


The only thing I don't like is having to give a name to every widget.

With this concept in mind I started trying to design an algorithm to render such layouts. After a few fruitless weeks with pen and paper I had to give up.  I was out of my depth.

Thankfully, some lucky online searching pointed me in the right direction.  Such problems are known as Linear programming and algorithms have already been developed for solving systems of linear equations of the type found in user interfaces.  Specifically the Cassowary Constraint Solving Toolkit.

Here I thought I was exploring revolutionary territory.  Not so!  Apparently there have been a wide number constraint-based UI layout tools over the past few decades.  My question is, why didn't they take off?  Why don't we see them in popular toolkits?  Perhaps it's finally starting to take hold because in 2011, Apple integrated Cassowary into their interface builder (see AutoLayout).  Also a new python-based framework called enaml uses Cassowary.

With Cassowary in my toolchest I've begun prototyping a layout system based upon the above syntax.  So far I have the parser working (thanks to Lemon) and I'm able to isolate all the distinct lines which widgets align to.

Quote: the definition of ocean

This showed up on Slashdot's quote of the day.

Ocean: A body of water occupying about two-thirds of a world made for man -- who has no gills.
-- Ambrose Bierce

Quote: money == religion

Feels so true:

"Five hundred years ago, our ancestors started the fight to separate church and state. Now it's time we separate corporation and state."

-- ? Thom Holwerda, osnews

quote: The most dangerous thought that you can have as a creative person...

Interesting quote:

The most dangerous thought that you can have as a creative person is to think that you know what you're doing...  Because once you think you know what you're doing you stop looking around for other ways of doing things and you stop being able to see other ways of doing things. You become blind... I think you have to say: "We don't know what programming is. We don't know what computing is. We don't even know what a computer is." And once you truly understand that, and once you truly believe that, then you're free, and you can think anything.

- Bret Victor's 
(source) 

Can XUL meet the goals of stdgui?

Can XUL meet the primary goals of stdgui?


1. Programming language independent?
No.  UI is written in XML and Javascript.  Must use XPCOM to call out to C/C++.  But if Javascript is your language of choice, you're set.

2. Native rendering?
Yes.  "The main backends are Linux GTK2, Mac, and Windows" (src).  Qt seems to be supported too.  I even saw some Windows 8/Metro stuff in the source which is promising.

3. Rapid Development?
Probably.  After the learning curve I sense that it would be good for RAD as long as your logic can be accomplished with provided Javascript APIs.  The XUL Explorer tool sounds very similar to my stdgui previewer idea.

Summary
XUL really does a lot of things right in my opinon:

• The UI definition is language-neutral by using XML and stylesheets.
• Their box layout model is powerful without being overly complex.
• Native rendering
• Overlays allow reuse of XML snippets and facilitate extensions which tweak the original UI.
• Templates (aka databinding) is a really powerful concept.
• Their widget-set has exactly what you would want.

That said, I have some reservations:

1) Requires bindings to develop a non Javascript application.

2) Is XUL development subordinate to FireFox development?  Will XUL maintain backwards compatibility in the long run?

3) Unfortunately it appears that XUL has some pretty significant memory overhead.  For example, the XULPeriodicTable example, which demos all widgets and layout features of XUL occupies 65MiB of RAM on my machine.  That's more than GIMP with no images open!  And the barebones helloWorld takes 41MiB.

In my opinion, this limits it's uses to "big applications".  People will accept high memory usage for a big application but for little utility programs it's kind of embarrassing.  Since I'm targeting stdgui towards the later, this rules out XUL.

Fork It?
Since XUL is a lot closer to my goals that any other toolkit, should I fork it and try to make it work?  I would make changes such as:

• No Javascript interpreter.  GUI events would be exposed to the host language by simple string IDs.
• Create a minimal C API allowing the host language to communicate with XUL.
• Remove the Gecko rendering engine if possible.  Otherwise try to trim it down and reduce it's memory overhead.
• Simplify the Templates (databinding) approach.
• Generally remove features and APIs not directly benefiting small GUI programs.
• Make some parts of the XUL markup more terse? (eg <li> instead of <listitem>)

Doing this would create a rather divergent project.  Probably little of this work would ever be merged back into official XUL.  I guess it then comes down to this.  Would this approach save time?  More exploration is needed to answer that.

quote: If you own a machine...

"If you own a machine, you are in turn owned by it, and spend your time serving it..."

-- Marion Zimmer Bradley, The Forbidden Tower

Can Tk meet the goals of stdgui?

Can Tk meet the primary goals of stdgui?

My consideration of Tk centered around the idea that it could be used as a native GUI abstraction framework like wxWindows.  There are many scripting languages which have Tk bindings so it must not be too hard to bind Tk.

1. Programming language independent?
Limited.  If you consider wide availability of bindings language independence.

2. Native rendering?
Limited.  I hear that in Tk 8.5 the Windows and OSX got a lot more native looking.  Linux still appears to be custom drawn.

3. Rapid Development?
Limited.  Some may disagree but I tried to do some RAD prototyping with Python Tkinter and it was actually rather tedious and messy.  I couldn't find any decent GUI builders and my hand written code quickly got unmaintainable.

Summary
Perhaps I'll copy some of the native rendering code from Tk if wxWidgets doesn't work out (BSD License).

Can Lazarus meet the goals of stdgui?

Can Lazarus meet the primary goals of stdgui?

First I should mention that Lazarus is a little different than the other toolkits in that it is written in Object Pascal.  I have a warm fuzzy place in my heart for Object Pascal because Borland's Delphi was my first earnest programming language & IDE.  It was a very productive environment back in the day - it's known as a RAD tool.

After installing Lazarus 1.0.10 I got all nostalgic because it all looked so familiar.  The Lazarus team has done a really excellent job of recreating Delphi.

Nostalgia aside, my interest in Lazarus is purely due to their apparent support for pretty much every toolkit I want: Windows, OSX, GTK and Qt.  The question is their support for these toolkits of sufficient quality and, if so, can Object Pascal code be wrapped in a C shared library easily?  This might put it as a contender to wxWidgets as a backend for stdgui.

1. Programming language independent?
No.  It's a big Object Pascal API.

2. Native rendering?
Yes.  Here is the state of support for different "widgetsets"

3. Rapid Development?
Yes.

Summary

I don't think any part of Lazarus will help with the implementation of stdgui.  I asked on their forum how feasible it would be to wrap the Lazarus Component Library in a C shared library.  The response was that it would be non-trivial and there would be some definite technical hurdles.  It had been attempted before but that project stalled.

A different kind of GUI builder?

If stdgui ever materializes there will be motivation to provide a GUI builder.  But perhaps we can take a little different approach.

First, a little background.  I've never been fond of WYSIWYG HTML generators because they always seem to generate unreadable HTML.  This I why write HTML by hand.  And you know what?  It's really not that bad.

If we can keep stdgui markup simple, so that it can be easily written by hand, then many skilled developers will choose to type it instead of point-and-click with a GUI builder.  What would be nice then is a tool that gives you a preview as you type.  Picture this:

1. User opens a stdgui markup file in his/her favorite text editor.
2. User also opens same file in the stdgui-live-preview tool.
3. Every time user hits save, the live-preview refreshes.

The live-preview tool could also have a built-in markup editor of it's own with basic code completion for those developers who don't yet have a favorite editor.

What I like about this approach is that:

• It gives developers a deeper understanding of how stdgui works.  Deeper understanding means they won't get stuck if the GUI builder won't let them do X.
• It follows the Unix philosophy: "Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface."

Can GTK fill the needs of stdgui?

Can GTK+ meet the primary goals of stdgui?

1. Programming language independent?
No.  It's a huge C API.  The latest Glade GUI builder generates mostly language agnostic XML, however, like wxWidgets' XRC, it's still tightly coupled to the toolkit and thus would be rather hard to run on top of anything else.

2. Native rendering?
Limited  (according to this stackoverflow reply).  There is however some ongoing work to make a native OSX/Cocoa port.  (Aside: while searching this topic I noticed that the Tk toolkit has a Cocoa port)

3. Rapid Development?
Yes.  With a GUI builder like Glade.

Summary
Not what I'm looking for.  Like Qt, GTK is built to be a stand-alone toolkit, with a big API.

Does wxWidgets meet the goals of stdgui?

Can wxWidgets meet the primary goals of stdgui?

1. Programming language independent?
No.  Firstly, wxWidgets alone is a large C++ class library.  However, wxWidgets does have a declarative XML file format called XRC.  XRC files essentially allow you to define all the widget layout and properties outside of C++.  This is a very good thing because that is one of the most tedious things about using a traditional GUI toolkit.  Unfortunately you still have to write C++ code to create your application.  For example, event handlers are not specified in the XRC file - it is the C++ code which wires up event handlers.  XRC files are intended to complement the C++ coding, not replace it.

2. Native rendering?
Yes.  This is one of the well-known benefits of wxWidgets.  From their home page:

Unlike other cross-platform toolkits, wxWidgets gives its applications a truly native look and feel because it uses the platform's native API rather than emulating the GUI.

Currently wxWidgets can compile against GTK, Win32, OSX/Carbon as well as some other more obscure platforms.  The upcoming wxWidgets 3.0 will have better OSX support via the Cocoa API.  Notably missing is Qt.

It dawns on me that "native rendering" can be somewhat of a continuum rather than black-and-white distinction.  For example, I think that some widgets which are available on one platform, must be emulated on another.  Although I'm sure the essential widgets like buttons, checkboxes, and select lists would be 100% native which is all that I'm after.

3. Rapid Development?
Yes.  With tools such as wxFormBuilder to generate the C++ or XRC code for you, development can indeed be very fast.  However, without such tools it would be rather tedious.  This has been my experience with nearly every GUI toolkit that I have used.

I had hoped that XRC might be closer to HTML in simplicity but it seems to have a lexicon perhaps too large to hold in ones head.  The XRC documentation says of itself:

"It is highly recommended that you use a resource editing tool, since it's fiddly writing XRC files by hand."

Summary
wxWidgets does not meet goals of stdgui, but perhaps it can help.  I could use wxWidgets to implement the backend.  If this went well I could then add a wxWidgets port for Qt which would be beneficial for both stdgui and wxWidgets.

The markup "density" sweet-spot

While studying the XRC (XML) markup generated by wxFormBuilder, it struck me that there is a sweet spot in markup "density".  Ideally, you could view the entire markup for a typical form on one page and thus see it's entire structure and start to picture the layout of the widgets.  However, this goal must be balanced against the convenience of having all properties related to a given widget specified right there, where the widget lives in the markup.

Clearly this is a trade-off of ease-of-writing vs ease-of-reading.  The same trade-off is found more generally in programming languages.  It's also one of the reasons that CSS is so helpful with HTML - it keeps the HTML short and digestible.

This will be an important consideration when designing stdgui's markup.

Can Qt meet the primary goals of stdgui?

Can Qt meet the primary goals of stdgui?

1. Programming language independent?
No.  At it's core Qt is a huge C++ class library.  There are bindings for many languages, however.

QML is a little more interesting.  To quote their docs:

QML is a user interface specification and programming language. It allows developers and designers alike to create highly performant, fluidly animated and visually appealing applications. QML offers a highly readable, declarative, JSON-like syntax with support for imperative JavaScript expressions combined with dynamic property bindings.

But, unless your writing your whole app in JavaScript you're going to have to call out to C++ code and then bind to your chosen language.

2. Native rendering?

Limited.  According to this 2009 stackoverflow question, Qt tries hard to look native by querying the underlying OS about it's theme.  From the Qt 4.8 doc on QWindowsXPStyle:

The QWindowsXPStyle class provides a Microsoft Windows XP-like look and feel.
Warning: This style is only available on the Windows XP platform because it makes use of Windows XP's style engine.

Notice the "Windows XP-like" phrasing.  This sounds to me like a skinning approach as opposed to true native rendering.  Of course it's much more likely to look right than a hard-coded skin as I've seen in lesser toolkits.

Qt even has a GTK+ theme according to  "How can I theme my Qt app to resemble one written in Gtk?"  They even use the native GTK file-chooser dialog!  Use of a custom/unfamiliar file-chooser is a pet peeve of mine.  However, I think the comments there illustrate the weaknesses of a skinning approach.  Here's what people said:

• "Is there a way to do this that works with GTK3?"
• "This is great except it does nothing to change the icons that the qt apps use. For example, dolphin uses some really ugly icons running on ubuntu unity"
• "Qt apps don't follow the font hinting settings that are set by gnome-appearance-properties. You need to explicitly add an entry to $HOME/.fonts.conf"

In summary, there will always be "leaks" in the skinning approach.  Some people are bothered by it.  Others couldn't care less.  Sadly, I'm one of the former.

3. Rapid Development?

Yes, with QML or Qt Creator.

Summary
Qt isn't what I'm looking for due to lack of true native rendering and requirement for extensive C++ bindings.

Software pessimism

Some quotes I stumbled upon which I sympathize with:

“And folks, let’s be honest. Sturgeon was an optimist. Way more than 90% of code is crap.” — Al viro

“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.” — C.A.R. Hoare, The 1980 ACM Turing Award Lecture

“One of my most productive days was throwing away 1000 lines of code.” — Ken Thompson

“..At first I hoped that such a technically unsound project would collapse but I soon realized it was doomed to success. Almost anything in software can be implemented, sold, and even used given enough determination. There is nothing a mere scientist can say that will stand against the flood of a hundred million dollars. But there is one quality that cannot be purchased in this way -and that is reliability. The price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay.” — C.A.R. Hoare

Quick rant about GUI layout

Just a quick rant about GUI builders and layout managers.  While experimenting with Qt and Qt Creator I'm reminded of why layout can be such a chore:

1. You picture in your mind roughly what you want
2. Then you think a moment and try to choose the root layout manager. (Qt gives you four options)
3. Then you start adding your widgets
4. Then you realize you need to nest another layout manager
5. You do that and continue adding widgets
6. Then you realize that you needed to insert a layout manager higher in the hierarchy
7. All your novice attempts to drag-n-drop or cut-n-paste in a new layout manager fail
8. So you delete everything and start over

It's not just Qt Creator.  I've experienced this phenomenon with Java GUI builders too.  From this I see two truths:

• The mix-n-match-layout-managers model assumes the designer knows exactly how they want their GUI to look and has thought out which layout managers will be needed.  Ha!
• A good GUI builder needs to focus on evolving your GUI, not on building your GUI once.  Change and refactoring are the average case.

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.

stdgui is officially a project!

I've just created a source repository for stdgui on GitHub!

Right now it contains only a prototype of the layout algorithm (called "Snap Layout").  I say "only" but the prototype is a complete implementation of all the features I want out of the layout engine.  It took a rather long time to conceptualize and develop (the many hours spent walking my then-new son to sleep were actually design sessions).  The prototype gives me a very solid starting point to begin realizing stdgui.