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