Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!bloom-beacon!GOLDHILL.COM!phil
From: phil@GOLDHILL.COM
Newsgroups: comp.windows.x
Subject: Toolkits & User Interface Deevolution
Message-ID: <8906121703.AA01605@godiva.goldhill.com>
Date: 12 Jun 89 17:03:54 GMT
References: <2904@portia.Stanford.EDU>
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 87


> My last count showed there exist 6 toolkits and not one user interface
> builder.  I'm really curious how this  imbalance came to be.  It seems
> people believe there is *no* difference between toolkit facilities and
> user interface builder facilities.  While  I  find  no fault  with the
> toolkit  programming  interface,  I do   not   believe  that every   X
> programmer should have to learn the intrinsic just to be productive.

If they aren't learning the X intrinsics and toolkit then by definition
the programmer is not an X programmer.

> Obviously I am not speaking about a radically new  idea here.  The Mac
> has  ResEdit, the  Amiga   has  Power Windows,  and  the  Next has the
> Interface Builder.  With each of these I can  create a *complete* user
> interface and not wright  one line of  code! Not one.   This is simply
> impossible with the toolkits.

I'm familiar with the above but have not used any of these tools. I have
built menu/dialog layout tools for MS/Windows and believe that there
are many issues that need to be addressed:

	1) What are the objects that are supposed to be manipulated? If we're
	just dealing with menu and dialogs then the list of ojects are
	narrowed down but the list is still long: buttons (square, rounded,
	pixmaps), selectable text (font, location relative to other objects,
	clipping behaviour), non-selectable text (similar issues to 
	selectable text), scrolling non-editable text, scrolling editable
	text fields, popup list menus, checkboxes, and radio buttons
	are all objects that I would want to manipulate.

	I'm not a CAD/CAM user/implementor but I have to believe that
	the primitives that are requires in a CAD interface go beyond 
	the level of buttons and checkboxes. Let's not forget 3D, 
	animation, voice, mixed media, etc... These are all parts of
	a user interface.

	2) What is the behaviour of these objects? How are callbacks
	supposed to be associated with events and objects? There are
	posted examples of tools that will take a relatively high
	level description of a layout of buttons, edit fields, etc...
	and produce toolkit calls to support the appearance. Behaviour
	and actions need to be added by hand however.

>                        [ section removed ]
>
> Lets say you  have an application  that runs on  all windowing systems
> and you want to change or  add to the behavior  of the user interface.
> How will you do it?   Modify  a toolkit by  changing or creating a new
> widget?   Wright this code  for each window  system?  On  a particular
> window system will you  write code for  each toolkit?  Who will QA all
> this work?   How many people  will it take  to add and  maintain this?
> Big and expensive questions indeed!

Big and expensive - yes. But atleast a standard exists and companies that
would never have adopted such an open standard 5 years ago now have.
Programming in an event driven, bit-mapped, extendable window system
is not something that you can do without long hours of learning,
experimenting, testing, etc... Maybe the day will come when the best and
the brightest don't have to spend over 5 years developing standards
and systems and we all know how to program these systems when we get
out of high school

> It is time  to  stop building toolkits interfaces  to X and get to the
> real  productivity  problems  encountered  by application programmers.
> While toolkits do relieve the burden of having to learn Xlib (which is
> all I will use   by the way),  they simply  create a different  set of
> implementation challenges for the application programmer.

Toolkits arise out of an awareness among many peers that there are a set
of common ways of doing things and that an API or protocol might eliminate
redundant methods.

> We  need an Interface Builder.   One that can   compile user interface
> specifications  into various  implementations be   they Xlib, Xt, Xmu,
> Xaw, or  Interviews.  Real  productivity is  only achieved  when large
> numbers of lines of code are eliminated; not reduced, not replaced.

I agree that a menu/dialog editor needs to be built as well as a language
in which to describe the primitive, and it would be great if there was a
public domain version that performed everything that you ask. Perhaps a
group should be formed to address this very problem, but let's not forget 
the spirit of X and how much it has accomplished.

Phil Stanhope
Gold Hill Computers, Inc.
Cambridge, MA.
phil@goldhill.com