Lex,


> Honestly, my usual idea is to kill SystemWindows.  :)

I'm not against this.

> All morphs have delete, menu, and
> minimize options nowadays.  All morphs have a title nowadays.  So why do
> we have SystemWindows?
>

As far as I can figure, SystemWindow have frames, which include the buttons
(close, min, max, menu),  title and frames for resizing. In some sense, the
buttons themselves provide shortcuts for regular morph window menu items, so
that (in their defense) they organize the most commonly used shortcuts into
an easier to use interface.

Part of the problem of using the regular halo type interface with a
SystemWindow is that, over the years, the interface is not such a very happy
place. There are 32(!) main menu selections when you bring up the menu from
a red halo on a system browser. (I've been told a pop up menu should be 7
items +/- . I don't think +/- means an extra 25 ;-) In some limited sense,
the SystemWindows menu button allows a more reasonable subset of options to
be presented.

Resizing a morph, an often used function for the current SystemWindows,
requires bringing up the handles and then using the yellow halo which
provides a limited subset of resizing compared to what's currently
available.

There's a slew of handles, I'm not even sure what some of them do. I know
that most of the handles don't make for a happy, happy experience. As an
example, the blue handle is pretty much the wrong thing using a browser or a
file list. While I'm a believer of "Everything, all the time", I think
having all 12 handles available is a little excessive in the normal course
of life.

While the morphs all have titles, they seem rather shy about showing them,
you rarely see titles on the screen.

Another thing that the SystemWindows do is hold a place for the model. I
notice that the FileLists subverted the use of the model in SystemWindow,
but it seems rather important to the browsers.

In summary, that's why we have SystemWindows. You already know that all
that, I'm just outlining some of the issues. One of the problems that I have
with SystemWindows is that while they look like windows, they don't have the
underlying sophistication of a 'modern' OS windowing system. We haven't
exploited any of the inherent layering now built into morphic to allow
things like dialog boxes or tool pallettes. I'm currently of the opinion
that floating pallettes should float, not sink into the layering quagmire.

> In addition to being unnecessary, they have some annoying problems:
>
> 1. Click-to-raise is currently buggy, and of questionably value IMHO.
> Why not just have click-to-pickup as normal?
>

Well, the hand tries to cache whatever it's picking up. On a window let's
say 900x600 it takes a while to 'pick it up', even on a fast machine. It
tends to be less than interactive. Usually when I click on a morph, I just
want to 'bring it to the top' anyway, not pick it up. The MPEG player morph
is such an example. Uusally I'll click on it when it's "in the background"
underneath another morph. At that point, it's in the hand, and then I have
to click again to drop it. It doesn't seem very intuitive coming from the
regular OS world. I know that shift click addresses that, but it seems to me
rather unnatural. I guess I'm more of a click to select type of guy.

If I click on a text pane to edit, I usually don't want to pick it up. I
notice when I'm using regular OS apps, the first click just selects the
window that I want to work in, brings it to the top, and then subsequent
mouse clicks do an operation. Squeak just cuts straight to the operation.

Here's a case where I think command-click-drag is a better metaphor than
click-to-pickup, though in practice right now it's impractical because the
command-click brings up the halos and causes the drag time to slow
considerably. I would much rather have shift-click drag a morph, than to
have the default behaviour be click-to-pickup.

>
> In all of these cases, it would work to have a list plus a display area
> to the side of the list.
>

How does a five pane code browser work in this scenario? I'm hoping that you
will tell me that we don't need it, that there is something much simpler and
more elegant. More importantly, you'll describe how to trim down some of the
100+ menu items (!) that are used to operate the thing. I'm not sure
overwhelming is the correct term for this amount of fire power being
available all the time.

> This is admittedly a lot of work, and so it's not going to happen soon.
> But in general, once you replace file list's, browsers, inspectors,
> debuggers, and celeste's current UI, there aren't too many system
> windows left to worry about, are there?
>

Well, I don't like the inspectors, I always use an explorer given the
choice. I wouldn't miss them. The explorer and the debuggers need a
different, probably more lightweight, shell to hold themselves in. The
Celeste UI needs an overhaul anyway. I would suggest that the debuggers at
the very least need a "stay on top" behaviour. At this point it's not easy
to go hunting for a morph once it is covered up. For example, using the
current windowing implementation, you have to go through three menus to
select a debugging window from a list, that is if you can bring up a World
menu. I'm sure that there is a keyboard shortcut available, maybe I'll run
across it within the next few years.

My guess it that it is more work *not* to start fixing the UI. (whether it's
this design or not is another matter). After you're done, how much easier is
it to develop in? 10%, 20%, 30%, more? 10% is probably not worth doing, but
if you can get 25% and spread that gain over a lot of folks, I would be
willing to start working on it

It's like what the coach tells you the first day of training camp. "It
doesn't matter if you win or lose. You're going to work just as hard all the
same. So you might as well just win".

Jim