Hi fellas!

"Andreas Raab" <andreas.raab at gmx.de> wrote:
> Hi Cees,
> 
> > Short of flying to one central place on earth and hacking it all up in a 
> > week, what sort of room shall we choose? A mailing list? Special subject 
> > tag on squeak-dev?
> 
> No Squeak-dev please. This single thread is already exhausting me. And we 
> haven't even started *doing* anything yet.

Yup. This task/project should probably be better off with a Swiki space.
Perhaps.
At least start by listing who is in this Abstraction team and let them
take the rudder.

> >> I just need TSTTCPW.
> >>
> > Array specs, probably. We can steal some code from VW in return from them 
> > stealing code from us (just kidding, you do NOT want VW UI code ;))
> 
> Fine with me.

Regarding that - I don't care either. Array specs are fine. The
parser/format should be built separated from the rest anyway. But more
importantly - see my little idea below.

> > TSTTCPW is also: limit the scope of the project to A) UIManager (easy but 
> > a nice chance to have a quick result in the update stream, good for 
> > motivation),
> 
> Agree.

Definitely.

> > B) UIBuilder *just* for tool support (Browser/OB, Transcript,  Workspace, 
> > Method Finder, File List, Monticello, SqueakMap, ...). Which  means that 
> > any widgets not used by the tools chosen to be worked on, will  not be 
> > representable by this first cut of UIBuilder.
> 
> Agree. Shall we do it driven by the five "most important tools"? Browser, 
> Debugger, Monticello, ChangeSorter, SqueakMap (in that order)?

Sounds fine by me, plus minus any forgotten tool.

> > (and then I'll stop - TFNR and this is enough on my plate. If I volunteer 
> > for anything else, please start laughing and give me the proverbial kick 
> > in the butt)
> 
> Heh. We need a place to discuss a few issues in private. Including, for 
> example, how to represent button groups (like the browser buttons), layouts 
> (at least we need a common concept), which "runtime-messages" we must 
> support and then some.

I am not signing up for this team - I am already laughing hysterically
with everything on my plate.

> Also, we'd at least need to come up with a concept of for how to choose the 
> ui policy appropriately (for example, does a tool need to remember the UI 
> builder so that it can request an appropriate dialog box?).

Now, here is my little idea:

All of the tools/approaches I have seen over the years in this area keep
mixing two things up:

	- The wiring of events/actions to the model and (lack of better term)
"interaction model"
	- The layout and choice of widgets, all from silly details like fonts
and colors and up.

Wouldn't it be really nice if we could separate these two? I am not
sure, but perhaps Mewa has something to do with what I am talking about
- but for the web (just a guess, may be wrong).

An example:

An app wants to present X objects to the user in the main tool area and
1 or 0 of thse can be selected at any given time. This is like the class
category list in the system browser. Does the underlying tool code
really have to know if it is a list? Or could it be a drop down menu?
And where is it located in the window - does it really care if it is to
the left side, or below or whatever?

It seems to me that if we separate these two things (somehow) then
different UI frameworks can actually use different widgets (given what
is available) and even different tool layouts. The tool layoug could
even be end user configurable to some extent.

Ok, enough blabbering.

> Cheers,
>   - Andreas

regards, Göran