Quote: always pick the choice that scares you a little

"One of my philosophies is to always pick the choice that scares you a little. The status quo, the path of least resistance, the everyday routine — that stuff is easy. Anyone can do that. But the right decisions, the decisions that challenge you, the ones that push you to evolve and grow and learn, are always a little scary."

- Jeff Atwood (link)

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.