I would like to make some observations about what I see happening with this
discussion and suggest some ways forward. I am fairly ignorant about the
details of the various UI "paradigms" so forgive any naivety :)

And sorry it's a bit long ;)

I was always taught that to develop good software you must have at least a
simple design. Where is the design for the UI abstraction? (I realise it has
only just started but I think it is VERY important).

What is the MINIMUM a UI abstraction layer has to do? Not the ideal, the
MINIMUM! I say this because I see a lot of messages to the list talking
about an end result and then stall because the task is so big that no one
wants to get started.

Where is this going to be documented? Let's have one place and preferably a
few people to update that place. I say this because as someone who doesn't
always have a lot of time to read the list, I find it very hard to "catch
up". If there is a summary and explanation of how UI abstraction will work,
many more people will be able to be involved by knowing how it will work
without having to wade through huge amounts of messages! BTW thank you Goran
for your summary. Something like that for this very critical part of Squeak
would be great (doesn't mean Goran has to do it either).

As I (and I am sure others) don't understand every UI; can the "owner", or
somebody in the know, post a summary of how each UI works? This would be
useful in trying to understand the issues and help distil common parts of
each UI. 

It would help also to have a discussion on the methods of communicating
through an abstraction layer (events, callbacks, etc). I would love to help
but I need more information and lots more experience :) I am sure there are
lots of people in the same boat lurking. These people are Squeak's USERS and
will have valid things to say.

To start with, I suggest concentrating on a limited set of widgets. Let's
make it enough to create the basic tools in each UI. I see the list starting
with at least: Window, List, Button, Text Box and CheckBox. 

How does each UI create and use these widgets? What common method can we
create to instantiate each of these in every UI? Note if at first we lose
functionality in a particular UI, that's fine, note it and move on. Squeak
wasn't built in a day and neither will this!

Let's come up with a way to describe the layout of a tool which can be used
by the abstraction layer. Avi said "... you have to recreate the layout for
each UI paradigm, which is a shame". Is there a way where we DON'T have to
recreate the layout? I would have thought there was.

There will ALWAYS be apps which only work in one or more UI's. Accept this
and move on. I do not see the UI abstraction layer being able to cope with a
3D scrolling platform game and nor should it. I would expect that browsers,
package loaders, Monticello, debugging tools, unit testing tools and other
similar tools would be able to be used in each UI. There may be "better"
ones for a particular UI, that's fine too. If you want it in another UI,
port it. However it should be relatively easy to develop a new tool which
works in most or all UIs.

I am sure I am teaching a Granny somewhere to suck eggs! BUT
I think it is important to go back to basics with designing this very
important layer. It seems to me that the people who are Guides and mentors
should be guiding this process. IMHO this does NOT mean coming up with the
solution or building it, but guiding the conversation to ensure all areas of
the design are discussed and covered off. They can be the referees when we
fight and you know we will :)

Thanks
Russell