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: Bruce Stephens
Subject: Re: [Gnu-arch-users] Re: [OT] Architectural renovation
Date: Tue, 09 Sep 2003 11:18:16 +0100
User-agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3 (gnu/linux)

"Stephen J. Turnbull" <address@hidden> writes:

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

But that particular problem ought not to happen: in a sanely designed
widget system you ought to be able to say how you want the widgets
arranged relative to one another, and give some indication of their
minimum sizes, and the widget set can provide a dialog that's just the
right size to contain the whole thing.  That kind of layout automation
is part of why widget frameworks are useful.

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

Yes, presumably.  Might be some interaction between the gtk theme
engine and XEmacs or something.

[...]

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

I agree completely.  I was suggesting using the GNOME canvas, not
GTK+.  The GNOME canvas provides a canvas on which you can draw
things, embed images (and widgets), and get events from any of them.
And I think it would scale well enough for the sorts of things Tom
wants to do.  I believe it's used for all the cells in Gnumeric, for
example, which suggests some level of scaling.

It also has at least a couple of Scheme bindings, and (possibly)
XEmacs lisp support, so there's a choice of lisp-like languages to
play in.

[...]





reply via email to

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