From: feit@era.com (Mark Feit)
Newsgroups: fj.mail-lists.x-window
Subject: X: User simplicity vs code complexity
Date: 25 Jul 92 04:35:04 GMT
Distribution: fj
Organization: Engineering Research Associates, Vienna, VA

Date: 24 Jul 92 14:50:08 GMT
Message-Id: <1992Jul24.145008.1028@ERA.COM>
Newsgroups: comp.windows.x

On comp.windows.x, tpaquette@ita.lgc.com (Trevor Paquette) posts:
 > I was talking to a cohort at work and we got to the subject of X and
 > how many lines of code it takes to do things in X etc..  I came up
 > with "X is the perfect example of User simplicity is directly
 > proportional to code complexity." Do you agree/disagree with this
 > statement and why?

Gawd, this discussion seems to come up once every three or four
months.  FAQ #294: "Why is X so complex?"

I agree that making the user's life easier requires greater complexity
of code, but X is by no means the culprit.  All of the extra functions
need to have code behind them, and it doesn't matter if you're writing
programs to run under X or on a Teletype Model 33.  That VCR with
on-screen programming you bought last month makes it considerably
easier to tape something than early models, but you can bet your
bottom dollar the innards of the new one are more complex.  Like your
application, SOMEBODY had to sit down and build it.

 > To open up a window, create a button, attach a callback to that button
 > when pushed, released and held, while tracking the mouse, takes up a
 > alot of lines of code. (Granted that will take alot of lines in any
 > GFX system but most likely more in X then any other)

That's true, but your example isn't a good one.  A few lines from Mark
Langley's editorial aside in O'Reilly volume 4 say it better than I
can (posted without permission):

	"You've just seen an X Toolkit equivalent to `hello world,'
	and it is nearly 30 lines long.  But it is node-indepednent,
	does device-independent graphics and can be customized by the
	user to control what font to use, and what colors to use for
	the border, background and text. ... Most people write
	complicated applications, not trivial programs like `hello
	world,' and it is the ease with which a complicated program
	can be written that is the true test of a language."

Langley goes on to mention that a basic text editor with some of the
same features of `hello world' (device-independence, user
customization, etc.) can be put together in under 200 lines using the
X Toolkit and the Athena Widget set.  In that you have a program
that's more complex by at least an order of magnitude with less than
that much in increased code.  Is the toolkit's complexity worth being
able to plunk a full-blown text editor into an application with
minimal effort?  You betcha.

 > To know X and all the in/outs of it takes about 8 700 page manuals
 > (O'Reilly & Associate) to learn.

The only thing that really is "X" (IMHO) is the way the server should
be expected to behave and the protocol that clients use to talk to it.
Everything else was written for the sake of utility, and there's
nothing that prevents you from writing your own low-level library and
toolkits to sit on top of it.  You can really shave those 8 O'Reilly
books down to volumes 2 and 5 plus an extra for any widget set you're
using (i.e., Motif or OpenLook).

I don't really see any need to devote my life to learning "all the ins
and outs," because there's simply too much there.  There are things I
know exist but rarely use, and when I use them I dig out the book and
refresh my memory.

 > Is there ANYONE out there who knows EVERYTHING in these manuals?

Aside from the people who wrote them, I'll second the vote for der
Mouse, but I suspect that like the rest of us, if he doesn't remember
something he looks it up.

 > There are many calls
 > that do basically the same thing (XAllocColor vs XAllocColorCells).

Yes, and there are reasons for things like that.  Those two particular
functions serve different purposes, and a thorough reading of the
manual pages for both will reveal that.  The reason for most of the
other function pairs (i.e., XDrawLine/XDrawLines) is to keep traffic
between the client and server to a minimum.  The former is for those
cases where you only need ONE.

 > How big is X going to get? When will it stop getting bigger? Who
 > created this monster in the first place? Oh well.. back to those
 > manuals..

X will get as big as people need it to be.  Yes, there are some things
that could probably have been done better, but for the most part Xlib
and the toolkits (what I presume you're complaining about) are fairly
well-organized.  The complexity is there for those who need the extra
horsepower, and there is a (sometimes steep) learning curve.  Once you
get over the curve, though, you more than recoup the time spent
learning in time saved while building your applications.

						- Mark

 ................................. .................................
: Mark A. Feit, Software Engineer : Internet: feit@era.com          :
: Engineering Research Associates : USENET: ...!uunet!era!feit      :
 ................................. .................................
 "Software development is 10% science, 25% ingenuity and 65% getting
	       the ingenuity to work with the science."