Re: [Gnu-arch-users] Re: [OT] Architectural renovation

[Stephen J. Turnbull]

>>>>> "Bruce" == Bruce Stephens <address@hidden> writes:

    Bruce> I should have been more explicit.  It wasn't just
    Bruce> aesthetically wrong---it was obviously buggy.

Yah, but many apparent implementation bugs are actually
"overconfiguration issues", for example, this one:

    Bruce> It had what looked like a button which the dialog wasn't
    Bruce> tall enough to display,

Evidently it's wrong for GTK+ for some reason.  But _this is user-
configurable_ on the fly in the normal configuration language for the
application.

Isn't that a _conceptual_ improvement over a broken composite widget
coded in C, which not only requires a restart, but a full rebuild?
And although a well-planned libglade application would allow you to
fix this, even on the fly, it wouldn't allow you to add another button
and wire it to new functionality on the fly.

    Bruce> and the whole thing flickered constantly.

This _is_ probably an internal bug.[1]

But once again, you've missed _our_ sandbox by a dozen yards or so.

(0) W.r.t to the button clipping bug, it's ugly, it's broken, but you
have the technology and _you_ (or somebody like you) can rebuild it,
and it won't cost $6,000,000, or even a recompile.  This is my main
point in proposing XEmacs as an experimental platform.

(1) GTK+/GNOME is _not_ a supported platform for XEmacs.[2]  The point
is _not_ that XEmacs has a slick GTK+/GNOME port, it doesn't (although
apparently a lot of people use it).  In fact, the point was to
contrast the Lisp + Athena version with what you might see in a mature
GTK+ app, not to point out XEmacs's GTK+ port.  The point is that it
has ways to support similar functionality without programming in C (or
using GTK+ for that matter; it's cross-platform functionality).

It _could_ be useful for prototyping Tom's proposal.

(2) For what Tom and I are talking about, GTK+, and especially GNOME,
is possibly the _worst_ platform not designed in Redmond.  It's not
"policy-free," it implements strong (and by current standards, good)
recommendations about the "right" way to design a UI.  But these are
fairly likely to get in the way of implementing a whole different way
of thinking.

So this is a real problem for the free software industry.  Users
demand slick GUIs.  In fact, slick GUI is more important to them than
functionality.  Heck, even you are much more interested in the pretty
face than the muscles and bone that do the work, and I have every
reason to presume that you do "get it" in general.

But slick _and_ coherent GUI, as currently implemented under toolkits
like GTK+, is very expensive in programmer effort.  Even small
imporvements are expensive, because they require a rebuild, regression
testing, etc.  And getting to market with something slick gets more
financial support and user approbation than providing functionality.
And even less applauded is providing new architectures that delegate
more responsibility to users while providing them with the power to do
what they want in a reasonable amount of straightforward code.

One of the radical things that Tom is saying is that there's plenty of
creativity in the community, there is no need to chase MSFT's
taillights.  But if we want to take advantage of that creativity as
something more than a hobby, we need to work smart.  We need to
leapfrog the technology MSFT can put in place, to something with the
expressive power to allow "two guys in a garage loft with an ISDN
connection" to once again hack up Something Important.

We can afford to do that; we are many, at any given time some of us
have time to do blue sky stuff (even in this economy), it requires
exactly the kind of inspired hack that we all love to see.  Then (in
Tom's view AFAICT) the FSBs should be arranging "pinball contracts"
with the Inspired Ones ("keep playing for free as long as you can win
`free games'"), and funding the mundane work of cleaning up the
details, as well as supporting the different kind of creative work of
creating "elegant" user interfaces.  _That_ no longer requires
high-level programming skills because the architecture now supports
hands-on "artistic operations" on the UI structure.

MSFT can't do that; it must followup a blockbuster with a blockbuster.
Look at the movie industry: is there anybody there who can do that?
Nope.  MSFT can, because (1) it can create lock-in and (2) it can
advertise the users into a stupor.  But even so it cannot afford a
mistake.  It must polish all the details, continuously.  So, New
Technology?  Yes, I would presume so---when it was specified.  A
decade (!) of refinement later, it's finally ready for the user's
desktop, and it doesn't even offer access to the equivalent of
Spamassassin, MIMEdeFang, AmaVIS, and procmail (at least, my
Windows-using colleagues don't know anything about it, they depend on
Windows and Norton Update, and CD-RW distributions, of software with
much less power).

So free software can't compete with MSFT on lock-in, refinement, and
marketing, and MSFT can't compete with free software on blue-sky
innovation (done right).  So why are we competing on the stuff that
MSFT will always do better (details details, the Devil's in the
details)?  Why are people who hang out on arch-users looking at the
superficial stuff?


Footnotes: 
[1]  I suspect it's due to "MS Windows thinking"; instead of reacting
to events and repainting what's been exposed, a fair amount of code is
devoted to guessing what Expose events have been induced by our own
rearrangements, and _not_ responding to them.  Quite likely the logic
is buggy.  Probably the GTK event model and/or widget tree is
different from that of Xt, resulting in Expose loops that don't appear
under MS or Xt.

[2]  It's explicitly labelled experimental.  It's in there because
it's been often requested, it was funded (6 man-months worth,
BeOpen.com via sourceXchange) to the point where we had a fully
working XEmacs including decent demo of GTK+, GNOME, and libglade
capabilities, and we thought if we put something out in front of the
users, we'd get bug reports, patches, even some volunteers dedicated
to that port.  Bu-wha-ha-ha!  Ha!  No volunteers, no patches to
improve functionality, a very few config patches (all via the Debian
BTS), and only a few more bug reports.

GTK+ users don't contribute as far as I can tell.  Even Mac users are
more involved.  YMMV, but that's been the XEmacs Project experience.

My hope is that Tom's Brave New Architecture proposal can remove all
excuse for that.  XEmacs, even though fairly configurable from Lisp,
is still far too awkward, and not just because of clumsy
implementation.  The architecture needs rethinking.  We need to make
it possible for typical users to look up common methods in the
"Customization" node of the User's Guide, and not need to root around
in the C sources and Internals Manual.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.