Andreas,
   I think you have hit the nail on the head. Rather than having a huge,
time-consuming discussion about which "official" framework should be used, I
think a discussion on how to fit ALL the frameworks in Squeak (not
necessarily at the same time) would be more useful.
Being able to load Tweak or Morphic or headless or whatever is much more
useful to me. 
What happens when the next evolutionary jump in UI thinking comes along? Do
we have this argument AGAIN!?!?! (arrrrrrgggggg :)

UIManager sounds like a good place to start.
As for the cross-framework widgets what about making an abstraction of
widgets stored in something such as XML which can generate a framework
specific version of a widget or window? Note that is just a place to get
started, No Thought(tm) has been put into it. :)

And **MOST** importantly to *me*, this fits into the idea of a minimal Base
Squeak which can have packages loaded into it as required. If I run a
headless image, I load the Headless package (HeadlessUIManager). Morphic
image? Load Morphic package (MorphicUIManager). Tweak? ... etc.

Russell

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org [mailto:squeak-dev-
> bounces at lists.squeakfoundation.org] On Behalf Of Andreas Raab
> Sent: Wednesday, 9 February 2005 4:40 AM
> To: tweak at impara.de; The general-purpose Squeak developers list
> Cc: tweak at impara.de
> Subject: Re: [Tweak] Tweak position?
> 
> Hi Stef,
> 
> > You called for help of people porting tools to tweak. So I imagine that
> > you should be interested by this question.
> 
> Actually not to much. Whether Tweak is the "official" UI framework of
> Squeak
> or not interests me much less than how to fix things so that UI frameworks
> can be swapped in or out. Right now, we have a big mess in all of the
> tools
> which don't allow us to use any other UI framework with what's there and
> while it can be claimed that most of this stuff is messed up anyways, I'd
> rather spend my time elsewhere ;-)
> 
> To that effect, I think it might be useful to get the people who are
> interested in using "alternative UI frameworks" (be that Tweak, wxSqueak,
> MVC, Seaside or whatever else) to get into the same room and look at what
> needs to be done. Personally, I think the solution needs to consist of two
> parts, namely:
> 
> * A way of managing the various UI requests which come from places that
> are
> normally not UI-related. Tweak has a UIManager class for that which
> manages
> these requests and maps them to Morphic or Tweak appropriately. So that
> you
> can use "self inform: 'hello'" and the right thing will happen. (hote that
> it would be trivial to have a UIManager which simply ignores/logs the
> requests for headless support so this takes care of it too)
> 
> * A way of constructing cross-framework widgets. This is going to be
> harder
> than the first since not only does one need a common basis for what these
> widgets are but there needs to be enough of an understanding about how
> they
> work. For example, Tweak abandons the concept of PluggableLists using
> getListSelector, getSelectionSelector and setSelectionSelector in favour
> of
> assuming that the list itself is known to whoever uses it and can be
> directed from that place. E.g., in a Browser today you have something
> like:
> 
> Browser>>selectClass: aClass
>     self classListIndex: (self classList indexOf: classNotMeta name)
> 
> Browser>>classListIndex: index
>     "..."
>     self changed: #classSelectionChanged.
>     self changed: #classListIndex. "update my selection"
>     self changed: #messageCategoryList.
>     self changed: #messageList.
> 
> whereas in Tweak this boils down to:
> 
>     classList selection: aClass theNonMetaClass name.
> 
> Nice and straightforward ;-) I'd be willing to provide pluggable wrappers
> for code that has been written already but given the simplifications that
> the Tweak style allows one must wonder why one would choose the indirect
> change requests instead (yes I know that the theory is that one might have
> different views on the object but practically speaking not a single user
> of
> a Pluggable* has ever been known to have more than one view).
> 
> So anyway. The discussion what the default framework is should be left for
> another day in my understanding (if only because it will be a
> controversial
> discussion to boot and I have ZERO interest in a flame war) but we should
> rather look at the ability to slide UI frameworks in and out have (at
> least
> the cross-ui tools) use them.
> 
> Cheers,
>   - Andreas
> 
> 
>