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

[Bruce Stephens]

Tom Lord <address@hidden> writes:

>     > 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

Yeah, the Tk canvas pretty much doesn't have any of that.  It scales
relatively poorly, and (if you're using Tcl, you've got a language
which really doesn't do abstraction well).  And so on.

However, I believe the GNOME canvas is well designed, and ought to do
what you want, especially if you use a good language to access it.
Probably Guile or STklos would work well.  They're both interpreted,
but there's bindings for bigloo, I think, and that can be compiled.

So if you wanted to play with something and build a proof of concept
cool thing for people to play with, then that would be a good place to
start, I think---three choices of scheme using an already widely used
fairly robust canvas widget.

I looked at the GNOME canvas ages ago, and here are some features that
I think match what you want: it's intended to support complex diagrams
and things (so thousands of elements); there's definitely a tree-based
mutable display list (this is one of the changes from Tk, which has a
list display list); you can do things with subtrees of the display
list, and subtrees are used to optimize event detection (which object
is closest to the pointer, for example), and display update; IIRC, you
can also add arbitrary lists of tags to objects, and group them in
that way (you can in Tk, and I'm fairly sure the GNOME people took
that idea too).

Separation of model and view, I'm not sure about.  It may be there.

It's probably good enough for a demo; I'm not sure whether it would be
better or worse than what's in XEmacs.

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

Sometimes.  On the other hand, those widgets have lots of useful
behaviour, like text selection and so on.  And when I upgrade the
widget set, I can get new features (like mousewheel scrolling), and it
works in all applications.  Well, in theory, anyway.

> 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.

Yeah, I understand.  I just think the places where you need that kind
of flexibility (rather than an off-the-shelf scrollable text widget,
or whatever) are fairly limited.  However, there certainly are times
where you want something just a bit more than what's easily available,
and then the limitations of existing widgets really sucks.

>     > 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).

There is that, sure.  Sometimes it's necessary to look and feel like
the other applications on that platform.  But often it's just that the
application has stuff that's reasonably shown using an interface
that's similar to what widgets sets were designed to do.  (Although
it's often true that there's this one thing that could be done so much
better if only it were convenient to tweak some existing widget, or
blend two in an unusual way, or whatever.)

> 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.

All true.

[...]

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

Yes.  

> 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".

My example was a caution against encouraging programmers to design
everything themselves.

> 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.

Sure.  One way is to encapsulate useful behaviours in widgets, and
then to arrange these widgets in relatively limited ways, so it's easy
for designers to get a text widget and a scrollbar widget, and join
them such that the scrollbar and text widget are always the same
height, and so that they both operate in the expected way.

> 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.

Yuck.  And yet it's easy to see how it happens, as you say.  Someone
didn't think of a list of text as text that might want to be searched,
so searching had to be added by the people who built the application.
It's even possible that they wanted to do the right thing, but found
it awkward given the limitations of the widget set.

(Of course, usenet is basically text, which is why Gnus is so nice.
There are some things that clearly want an interface that's not so
easy to do in Emacs, so even in Gnus there's space for a nice tree
display, and things like that.)

[...]