Emile van Bergen

About me

Software
   RADIUS for pppd
   i386 debugger
   HTML menus
   OpenRADIUS...

Technical articles
   Configuration data
   Non-recursive make
   Signals and Select
   Linux GUIs
      Library problems
      The GUI terminal

Work
   E-Advies...
   CV (NL, pdf)...
   Resume (pdf)...

GUI library problems


Why the current GUI libraries don't appeal more

This is the first article I posted publicly on this topic, on the Debian Developers mailing list, which I frequented in 2002 and 2003. It's archived at http://lists.debian.org/debian-devel/2003/01/msg01272.html. The discussion that provoked it and the follow-ups are also interesting. The DD list hosted an excellent group of people in those days, and it probably still does.

Hi,

On Fri, Jan 17, 2003 at 03:10:01PM +0100, Jose Carlos Garcia Sogo wrote:

> On Fri, Jan 17, 2003 at 10:36:08AM +0100, Emile van Bergen wrote:
> 
> > Using XML to specify, in an awk-like manner, that some configuration
> > setting should be changed. How criminally indirect can you get.
> > 
> > I never liked Glib, GDK, GTK+ or Gnome, for their thorougly un-unixy,
> 
> Then purge it. But don't troll here.

Ok, I'll drop it. But I wasn't trolling. I am truly, honestly
disappointed with the direction in which the Free Software GUIs are
going.

They suffer from creeping featuritis, lack of elegance and simplicity,
and are definitely not fun to develop for, much less encouraging people
to make beautiful software (beautiful in both senses of the word). And
they are not innovative at all, not in human interface principles nor in
their technical design. Most of the windows concepts are copied one by
one, including the GUI component model: binary objects linked randomly
together using whatever ad-hoc function call interface they expose.

I never got much into writing GUIs for Unix stuff, even though I did
lots of it on DOS, using my own toolkits. It's just too big, fat and
ugly. Xt is, with that ugly X resources model. Motif is (was). XForms
is. Qt is. Gtk is. And all of them take complete charge, leaving you a
tiny corner of the framework to put your application into. You may ask
the toolkit kindly to call some application routines if something
happens, but the toolkit is what's in control. You figure out where you
can keep your state yourself. And all of them try to reinvent parts the
OS, badly, polluting Unix' elegant model of small APIs, of processes and
IPC.

If Unix' IPC features are to primitive for GUI components, then let's
work on that. But let's not drop the concept of standard, well thought
out data messages between applications and switch to COM or Corba all
the way, so that interfaces can be as wide as convenient. That's just
not the Unix (or the internet) way, IMHO. That's the Windows (or telco
standards ;-)) way. If we need a new kind of pipe for the 21st century,
then let's build one. But please let's not toss Unix' model. It's not
needed.

Even with what Unix currently offers, I think GUIs can be done
differently. 

What if applications could use simple terminal I/O to build their GUIs,
talking to a new, extensible type of graphics terminal? Why end that
good, proven, concept at the VT520 and the Tektronics? 

Put in some good graphics commands, for drawing and blitting in
arbitrary buffers, managing views to those buffers, defining clickable
and draggable areas that send certain codes to the host when
manipulated.  Add a way to address external extensions (extension X
version Y or higher), which are either connected via a set of pipes or
linked into the terminal emulator process in order to access the
graphics backend directly. 

These extensions can implement rendering of fonts, postscript or PDF
data, vector graphics, bitmaps, and manage complex widgets (possibly
native ones on MacOS or Windows), and so on. Extensions receive the
commands addressed to them and can send back command sequences either to
the host or to the terminal input again, so that each extension can use
every other.

It's oldschool, simple, host-based computing: the connection can be
local, serial, through telnet or ssh, but the GUIs can be as beautiful,
friendly and versatile as today. I think that such a concept, if done
well, could possibly beat X, VNC, Citrix, Terminal Server and HTTP+HTML
both for exporting GUI applications on the network and using them
locally, because commands can be very high level, without forcing a
restrictive document model (HTML) on you.

At least the programming model for GUI applications could regain some
sanity. It is patently absurd, and there is no /real/ excuse in my
opinion other than the endless layers of abstractness to hide broken,
complex programming models, that we need gigahertz machines simply for
wordprocessing and webbrowsing these days, and hack upon hack (see
prelinking) to keep the mess perform a little.

So sorry if this rant comes across as trolling, but it is an honest,
heartfelt emotion here. I'll stop bothering you people with it now and
will try to refrain from commenting on GUI topics here, until I've got
some code to show.

Cheers,


Emile.

-- 
E-Advies / Emile van Bergen   |   emile@e-advies.info
tel. +31 (0)70 3906153        |   http://www.e-advies.info

Generated on Sun Feb 23 17:20:55 2014 by decorate.pl / menuize.pl