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

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

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


From: Tom Lord
Subject: [Gnu-arch-users] Re: [OT] Architectural renovation
Date: Mon, 1 Sep 2003 21:27:42 -0700 (PDT)


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

    > I suspect that attempts to mirror the "global awareness" of the active
    > user in the application's state are precisely the root of concepts
    > like "keyboard focus" on parent widgets, and of course of event-driven
    > programming.  

Not so much.  I was there for a large part of the development of the
architecture you find yourself subjected to in today's toolkits.   I
was there for the very toolkit that MSFT came and ripped
of^H^H.... "technology transfered".   I was there for the meetings
where that transfer was initiated (and I'm still washing my hands when
I think about it too hard).

Sorry to tell you but, no, nothing so lofty.  The canonical
view-tree-architecture input processing was designed, in essense, this
way:

        "Uh....I dunno.   I guess this'd work.  Here, I'll bet I can
         get something working in a day or two."

and after that, it was elaborated.   "Hey, look -- nifty -- I can
squeeze such and such feature into this...."

(There's also an element of (unpricipled) generalization of the more
reasonable concept of top-level window keyboard focus .... mixed in
with the idea that UI components are either windows or
kinda-like-windows.)


    > Attempts to force that back into "(point)" are the root
    > of such brain-damaged standards as the Motif keyboard traversal model
    > which doesn't grok that some interfaces involve preparation and then
    > repeated invocation of an action (search, replace) and others do not
    > (a file selection widget should not leave focus on "OK" just because
    > that's the last thing that was done).  Or Windows, where the keyboard
    > focus is ALWAYS several <TAB>s aways from where I want to type.  Even
    > the Mac.  :-/

The bogosity plays out in a gazillion stupid ways, yup.   In my
experience, trying to explain that to people who are making the
decision "should we let that guy do what he wants or require that he
just work in this framework" is a pointless exercise.   Eyes gloss
over, etc.

It's beautiful, and subtle, and multidisciplinary to consider how the
architecture plays out economically, in human factors, and so forth.
It's also so esoteric that, oh, there's maybe about, um -- well, I
could count on the fingers of one hand the number of people who care.


    >     Tom> Yup.  Part of why I'm participating in this thread is that
    >     Tom> it's working both ways.

    > Whew!  I feel better now.  :-)

RMS is good at this too.   He'll decide, for various vague reasons,
that no, certain things can't be done certain ways.   He imposes what
I can only describe as an aesthetic judgement and, if you want to get
anywhere, you have to get a feel for the aesthetic or fail.   And the
funny thing is, and I think this is mostly just an N-times removed
reflection of the topology of various design spaces: "suffering" under
the aesthetic constraints plays out nicely.   Stupid, arbitrary,
aesthetic constraints, when honored, lead to a consonance that's worth
a lot.


    >     Tom> In other words, why don't "we" (for some value of "we") grab
    >     Tom> a Scheme (because, hey, why _not_ a Scheme) and make a
    >     Tom> really, really minimal, yet really really clean/portable/
    >     Tom> tractable text-only emacs.

    > Right.  

Thinking.....


-t




reply via email to

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