UI abstractions "task force" (Was: Re: [Tweak] Tweak position?)
cputney at wiresong.ca
Thu Feb 10 03:04:29 UTC 2005
On Feb 9, 2005, at 10:37 AM, Cees de Groot wrote:
> On Wed, 9 Feb 2005 13:09:40 +0100, Avi Bryant <avi.bryant at gmail.com>
>> Along those lines - I'm not sure how wxSqueak handles this, but
>> Seaside definitely needs "UIManager default" to be some form of
>> dynamic variable (process-local, or walk the stack), rather than a
>> global. I'm surprised Tweak doesn't need that too; don't you have
>> cases where Morphic is running in one scope and Tweak in another, and
>> you'd want to pop up the right dialog depending on where you were when
>> you sent #inform:?
> More complicated than that. I want "self inform: 'foo'" to pop up a
> dialog in whatever environment is running (process-local, probably);
> but "'foo' inspect" to pop up a dialog in the environment I as a
> developer told the system I like. So no Seaside inspectors if I'm
> quite happy to go to my image's window and do the inspect there...
I'm pretty happy with the multi-UI solution I came up with for
OmniBrowser. It uses Notifications to request user interaction.
For example, when you call #confirm: it raises an
OBConfirmationRequest. The default action on that exception is to open
a Morphic PopUpMenu with 'ok' and 'cancel' items, and then #resume:
with true or false depending on what the user selected. There are
similar notification classes for opening menus, FillInTheBlanks, and
I think if we can generalize this so that the default action isn't "use
Morphic," we can get what we need in a pretty clean way:
* Dynamic scope: multiple UIs can run concurrently as long as they're
in separate Processes.
* Ability to easily intercept UI requests and deal with the
programatically. The OmniBrowser tests
do this to simulate user actions. You might also want to do this when
that would normally done by a user - installing a bunch of stuff from
SqueakMap, for example.
* Ability handle different types of interactions in different ways.
Different notification classes can implement
different strategies for deciding which UI to use. So
developer-oriented UI like inspectors and debuggers
can appear in a different interface from user-oriented UI.
For my 2 bits, I applaud Andreas for turning the discussion in this
direction. He's absolutely right: who cares what the "official" UI is
if we can all use which ever ones we want?
I'll commit to making OB multi-ui-enabled, and pitch in whatever help I
can give to task force with one caveat - I'll be offline next week, so
I won't be able to contribute much in that time.
More information about the Squeak-dev