Hi Jim'n'Lex,

On Sat, Jul 07, 2001 at 09:44:10PM -0700, Jim Benson wrote:
> 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.

Yes, something eventually needs to be done to address this.  I suppose that
gradual refactorings can move us in the right direction.

> 
> 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.
> 

Improving control over resizing happens to be one of my current mini-projects;
the current reliance of a single halo handle that can only resize at the bottom
right corner is getting in the way of my integration of Cassowary into Morphic.

> 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. 

I don't know exactly what you're talking about here.  You click on it to pick
it up, and release the same click to drop it.  A quick click has the effect of
raising the morph to the top.  What is the second click you are talking about?

> 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. 

Yes, although this problem will eventually go away with faster CPUs and 
hardware acceleration of 2D graphics.

> 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

Even a 10% improvement (in whatever metric you choose to quantify "improvement")
is pretty significant for an aspect of the system that is so fundamental.  For
example, a 10% increase in VM execution speed is significant.  25%+ would be
nice, though.  And it's probably achievable.

> 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".

True.

Joshua


> Jim
> 
>