On Sun, Jul 08, 2001 at 10:09:23AM -0700, Jim Benson wrote:
> Joshua,
> 
> >
> > 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.
> >
> 
> Any ideas on how you are going to achieve this?

>From a UI point of view?  I'm thinking of separating resizing and rotation
from the other halo functionality.  They are direct manipulation, whereas the
other halo menus access data that is not manipulated directly.  Resizing will
be done from any of the 4 corners; perhaps shift-drag will make the resize be
either horizontal or vertical, depending on which axis the drag is closer to.
Rotation will be by grabbing a handle at the midpoint of any of the 4 sides
and moving it circularly.

I'm hoping to essentially have 2 "rings" of halos: the inside ring for resizing/
rotation, and the outside ring for the rest of the halo functionality.  One of
the main problems that I see is coming up with a layout and look for the halo 
handles that clearly expresses their purpose without taking up too much room.
This will take some work with the GIMP, probably.  I'm not sure I explained this
adequately; it would be much easier with body language.

> 
> >
> > 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?
> >
> 
> My bad.
> 
> I *really* meant to say ;-) that when you click on a morph, it exhibits the
> unintended side effect of moving the morph (for me this is around 25% of the
> time).
> 
> Here's what happens:
> 
> Click on morph to 'raise' : ( on a large morph nothing appears to happen for
> a beat so user doesn't release mouse button immediately)
> Hand caches morph and draws shadow around morph
> User sees something has happened and releases the mouse button.
> (  depending on a lot of factors, sometimes the mouse has moved before the
> button has been released )
> The morph is redrawn in the world ( without shadow ).
> 
> I think here that when a morph is in the background, I am only clicking to
> select it. In regular use, I don't try to pick up something in the
> background and move it one fell swoop. Most of the time I just want to bring
> it to the top (and need a little bit of leeway even then), and I do not want
> it to move upon selection.

Hmm.  You have a point worth thinking on.  I'll have to reflect on this.

> 
> > >
> > > 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 guess that my Pentium IV is a factor of four off, so it would appear
> to be 2 to three years before this would iron itself out. 

You're right, that is a significant time span in Squeak Time.

> Hardware assist on
> the graphics side is tough for other reasons (portability between the main
> platforms being number 1).

That's true.  However, Andreas has managed to hook up hardware rasterization
for 3d graphics in a cross-platform way, with a software fall-back.  I can't
imagine that it would be any harder for 2d.

> 
> I would make the case that you don't want the halos up when you move a
> morph. It gives a false impression as to the real size of a morph, and gets
> confusing when you reach the sides of the screen when the halos start
> bumping them. For the black and brown handles, they hide the other halos
> when they start moving things around.
> 

I'll think about this as well.

Joshua

> Jim
> 
>