Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!rws
From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: Re: where X went wrong
Message-ID: <9009091549.AA21182@expo.lcs.mit.edu>
Date: 9 Sep 90 15:49:43 GMT
References: <141973@sun.Eng.Sun.COM>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 104


    Where things broke down is not
    taking a higher view of the interface creation  process  and  building
    systems which generate and manage the interface at a meta  level.

If you talk to the designers of Xt, I think you'll find they assumed from
the start that there would be higher-level interfaces (e.g. an interface
builder at a minimum) wrapped around Xt and the toolkit.  Prototype
interface builders for Xt toolkits were done years ago, I believe.  But
their absence doesn't really negate the utility of having an Xt-like layer.

    The
    addition  of  Xt seems like adding macros to assembly, metaphorically,
    rather than building high level  structured  languages  and  interface
    generators.

I would think that many existing systems have an "intrinsics" kind of layer,
although it might not be cleanly factored out as such.

    Building from this base simply has created  a  really  tough  learning
    curve, compared to providing systems at the  level  of  HyperTalk  and
    4GLs.  There is simply too much  the  application  programmer  has  to
    understand to get to first base.

Most people will agree completely with you.  But the problem is not a simple
one.  Xt serves as a common base for multiple vendors with competing products.
While it is conceivable to think of some variation in history which would
have resulted in a single high-level API (and perhaps a single GUI) in the
UNIX market, it is rather difficult to think of a realistic one.  If you
have ideas on how it could have been accomplished (at a political level,
not just a technical level), I'd be interested in hearing them.

    Considering we have some of the brightest minds out there making these
    strategic decisions, I'm really surprised this is the current situation.

Perhaps because the goals and requirements of the decision makers didn't
match yours?

    With a central server  mechanism,  issues  currently
    handled inconsistently by the toolkits and window manager would become
    moot points.

And other major problems solved by the toolkit/WM method would in turn
become major problems again. :-)

    Additionally Internationalization would be consistent and easier...

My experience so far suggests that nothing makes internationalization
easier. :-)

    To me it isn't any surprise that the existing systems in use by  large
    numbers  of  end  users are the Mac and Windows 3.0.

Not surprising to me either, since the hardware platforms they run on
constitute by far the bulk of the market. :-)

    Although I don't
    program either, both systems seem to have  higher  level  interactions
    between  the user and the applications in manner of environment.

Hmm, I'm not sure I see this.  Perhaps you are comparing a "complete system"
on the Mac or PC, with the "X standards".  Not exactly a reasonable comparison.
The X market is quite different in structure (multiple vendors competing at
the GUI/API level) from the Mac/PC market (single vendor with dominant control
of the GUI/API).

    X is dealing at granular levels, fighting upward.

X standards have progressed bottom up, true.  Because that's where it has
been possible to obtain agreement.  The upper layers, where end users care,
are fraught with politics (just consider what has happened in the IEEE P1201.1
group).

    The solutions  out  there
    for  the masses give the end user a top-down approach, and therefore a
    more   warm  fuzzy  feeling  of  security.   They  are  consistent  in
    appearance, and plug/play correctly. And are easy to setup and modify.

I find the Mac quite difficult to deal with, but then perhaps I'm weird. :-)
I find quite often that I simply accept the inability to modify.

    It would be nice if that was more the norm in the X world.

Sure it would.  How would you propose to solve it?  I'm sure OSF and UI and
NIST and X/Open and IEEE and ... would love to know what the solution is. :-)

    There is no reason that X could have not gone  on  this  path  in  the
    past.

Perhaps you'd like to write a paper on the subject, I'd be interested to
read it.

    Hopefully there will be lessons learned from
    the premature introduction of standards in the creative  process.

This is an interesting statement.  X did not introduce high-level
standards early on.  This was supposed to help the creative process
(permit exploration of different user interfaces).  In that regard
I think it has succeeded rather well: if there weren't so many options
to choose from, it wouldn't be so hard to get a standard. :-)  It would
be interesting to know more about how you think things should have
progressed, and whether it would have enabled the same level of
creativity in toolkits, UIMSes, window management styles, desktop styles,
GUIs, etc.