gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stephen J. Turnbull
Subject: Re: [Gnu-arch-users] Re: [OT] Architectural renovation
Date: Wed, 10 Sep 2003 11:56:22 +0900
User-agent: Gnus/5.1001 (Gnus v5.10.1) XEmacs/21.4 (Portable Code, linux)

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

    Bruce> But that particular problem ought not to happen: in a
    Bruce> sanely designed widget system

What sanely designed SINGLE widget system?  XEmacs supports widgets in
some fashion or other on TTYs, Xaw, Xaw3d, NeXTaw, xpmxaw, xaw95,
Motif, MS Windows, GTK+, and Qt.  Mac OS X Carbon (Quartz engine, Aqua
HI guidelines IIRC) is on the way, out there in Macland somewhere.

    Bruce> the widget set can provide a dialog that's just the right
    Bruce> size to contain the whole thing.

Assuming that the toolkit measures things the same way as the widget
set, that works fine.  GTK+ went out of its way to do things
differently from Athena.  They had good reasons for that, but it's not
surprising that generic widget code breaks when applied to a toolkit
the widget writer had no access to.

There are a very few toolkits out there (wxWindows, eg) that try to do
something like this.  But most programmers just say GTK+ RuLez! or
some variant, and stick to one.  XEmacs is a cross-platform program,
and is going to support real widgets on at least Xaw variants, Motif,
and MS Windows.  And probably GTK+, Qt, and Quartz.  

    Bruce> I agree completely.  I was suggesting using the GNOME
    Bruce> canvas, not GTK+.  The GNOME canvas provides a canvas on
    Bruce> which you can draw

That _is_ an interesting idea; I hope you will forgive me for giving
in to my vested interest in XEmacs.

Putting that aside, there are still some areas to be cautious.  The
canvas metaphor suggests that there's a fixed fabric to which the
widgets are attached.  However, editor buffers are by definition very
dynamic.  This leads to the "redisplay" architecture, such as in
Emacsen or Mozilla's (and Galeon's) famous "Gecko".  I have to wonder
if a "canvas" can keep up.  (I'm not even thinking of saying it can't,
because I don't know how it's implemented.  Just that the design and
preliminary prototypes should keep a close eye on performance issues.)

Second, because the Emacs redisplay really amounts to a single
fantastically complex text widget, buffer to redisplay communication
is immediate.  A canvas widget would require an intermediate layer of
abstraction between the buffer and its representation on the canvas.
This could be a disadvantage (performance) but it's also an
opportunity to use that layer of abstraction to improve the coherence
of the overall design.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]