SystemWindows do make certain features faster to access, but I'm not
convinced that the right features have been extracted:

	1. Resizing is important to all morphs.  I probably resize image morphs
*more* than I resize system windows.  It's also uncommon enough that an
extra click to raise a halo doesn't matter much.

	2. Titles are equally important to all morphs, at least under my usage.
 This is especially true if you use the default color scheme, so that
you can recognize windows by their color.


On click-to-raise versus click-to-grab, I do agree that speed is
important.  However, I don't think the speed is too slow right now, even
on my old K6-3/366.  Furthermore, a much better solution is to give
Morphic special cases for opaque, rectangular morphs.  Click-to-grab is
consistent with other morphs.


Anyway, as I quickly mentioned, I actually have a proposal, although no
running code.  I've attached some quick mockups to show how a system
browser could work with direct manipulation:

	1. ui1.gif.  You start with just the top-left pane of a normal browser.

	2. ui2.gif.  Clicking on an item, pops up a class list pane if there
isn't already one there.  By extrapolation, you can pop up a method
categories pane, a method list pane, and eventually a text area to edit
a single method.

	3. ui3.gif.  Clicking again will replace the class list pane with a new
one.

	4. ui4.gif.  A class pane can be torn off simply by dragging.  Probably
there should be a tab at the top, so it might look a bit like a system
window, but the interaction would be regular direct manipulation.  (I
imagine that dragging on the morph on the left will grab both morphs,
and that dragging on the morph on the right, will grab just the morph on
the right.).
	
	5. ui5.gif.  The new and old browsers are now independent. 
Effectively, the morph on the bottom is a class category browser.

It works for inspectors, too.  Overall, I think that these
direct-manipulation browsers might be a really smooth way to program. 
Or, honestly, it might feel slower, I don't know.  

I should mention that the inspiration for this comes from morphic
wrappers, which has a similar mechanisms for editting code.  The key
concept is that class lists, etc, should be morphs, not just regions of
some other morph.


-Lex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ui1.gif
Type: image/gif
Size: 5221 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20010709/16a06b08/ui1.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ui2.gif
Type: image/gif
Size: 7051 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20010709/16a06b08/ui2.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ui3.gif
Type: image/gif
Size: 7455 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20010709/16a06b08/ui3.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ui4.gif
Type: image/gif
Size: 10067 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20010709/16a06b08/ui4.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ui5.gif
Type: image/gif
Size: 10959 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20010709/16a06b08/ui5.gif