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

[Tom Lord]

    > From: Bruce Stephens <address@hidden>

    > There seem to be other ideas already implemented, similar in broad
    > outline to the ideas in the "Don't Fidget with Widgets, Draw!" paper
    > you referenced.  

    > I know of a couple of widget sets that include a canvas widget---a
    > rectangular region in which the application can draw things (lines,
    > rectangles, circles, text, etc.), and cause them to respond to events.
    > One can also stick widgets on the canvas.  One such widget set is Tk
    > (indeed, the paper mentions John Ousterhout).  Another is gtk (or it
    > might be in GNOME, I forget), which is basically a copy of the idea in
    > Tk, but significantly improved in a number of ways.  I believe the
    > major part of Gnumeric is actually things stuck in a gtk/GNOME canvas.
    > I imagine Qt or KDE has something similar, too.

    > There's even a Scheme (other than Guile) binding onto gtk,
    > <http://kaolin.unice.fr/STklos/>.

Sure.   There's some ways to improve those, too, with support for:

*) very large numbers of (flyweight) drawing elements
*) hierarchical, mutable, display lists
*) richer compositing operations
*) (mutable) pixmap elements
*) separation of model and view
*) computed-on-demand/cached elements
*) additional incremental display update optimizations

With those improvements, among other consequences, the feature of
embedding other widgets into a canvas starts to become superfluous.

Picture a big (2d) tree, representing (abstractly) a drawing.
Internal nodes are things like coordinate transforms, compositing
operators, and labels.  Leaf nodes are primitive graphical elements.
The redisplay engine can draw views of the picture, caching
intermediate pixmaps and other results to speed up incremental changes
to the tree.   That's how Bartlett's idea can really scale.



    > I must admit, my impression is that, for the most part, widgets
    > in trees work sufficiently well that there's little need to look
    > for something better.  

It depends what your goals are, I guess.   It seems sort of circular,
to me: 

If the driving goal is to make almost-look-alikes for some proprietary
programs that use similar toolkits, then, pretty much by definition,
such toolkits are "good enough" (and nothing else would do, really).

The experience of the proprietary vendors using these toolkits is
telling, however.  They spend a heck of a lot of money to build,
debug, and polish each interface.  They haven't exactly been fountains
of UI or application innovation over the years.  They offer a tiny bit
of scripting, and people have done interesting things with it, but
these vendors haven't produced apps that are especially extensible in
the field.  Proficient computer users often find interfaces built on
these toolkits to be clunky and constricting.

The exceptions to the extensibility and innovation issue correspond
pretty will with cases where the toolkit architecture was pushed well
to the side -- Apple's (Bill Atkinson's) Hypercard comes to mind (and
it's resemblence to a "tiny, soft-edged, plush-toy Emacs" is
interesting).


    > And for structured diagrams (or
    > whatever), one of these canvas widgets works well.

The existing canvases are a bit anemic.    But, anyway, the canvas 
issue is not the primary reason I think we want some alternatives to
the current widget kits and component architectures.


    > My experience of applications which obviously use non-standard
    > toolkits is almost entirely negative: xmms, xine, and mplayer,
    > for example, suck, IMHO.  They're acceptable to me because I can
    > remember the keys I normally use to operate them---the
    > interfaces are awful.  That's not to say it can't be done
    > well---just that it's safer to provide widgets that show text,
    > and scrollbars, and things, rather than expecting random
    > programmers to do something sensible, because you can bet they
    > won't bother to provide (for example) normal text selection (I
    > can't seem to copy the name of an MP3 from XMMS to paste into an
    > email message, for example).

It seems to me that you're comparing fundamentally similar toolkis,
where some are more complete implementations than others.

I agree with you that lots of problems, such as managing text
selections, are best solved once, generically, in a way that all
applications pick up that functionality "for free".

One way to make good progress on that particular problem (selection
management) is the Emacs way: use an extensible text editor for 
many more things.    As an example:

I happen to use a GUI interface to usenet -- one that is considered
fairly polished.   I can select from the body of a message just fine.
I can search for text in the body of a message "the usual way".

The summary window that shows message subject lines and authors,
though, is a different story.   I can't select any of that text at
all.   I can search it, sure, but only by invoking a custom search
function that's completely different from the one I use to search the
body of messages.   Why?  Well, I guess it's because the summary
window contains a "list widget" and that list widget isn't implemented
as an ordinary text buffer.

I don't expect "random programmers to do something sensible" -- you
seem to be reading too much into my suggestion of using canvas-like
entities for all graphical output.  I think that, to empower "random
programmers", we want to give them a much higher-level interface to
programming than the current toolkits, not a lower-level interface.
And to empower users, well, extensible, customizable, self-documenting
applications.   Emacs -- hypercard -- stuff "like that".



-t