Non-intuitive target for halo button

subbukk subbukk at gmail.com
Sun May 27 17:49:56 UTC 2007


On Saturday 26 May 2007 7:28 pm, Bert Freudenberg wrote:
> On May 26, 2007, at 15:09 , subbukk wrote:
> > Hi,
> >
> > When I press red button on a collection of Morphs, the top-most
> > morph is
> > targetted, but when I press blue button, the halo appears on the
> > outermost
> > morph. This runs counter to how we 'pick' stuff in real world and I
> > find it
> > very annoying. Shift-blue gives the right behavior but I wonder how
> > many
> > people know it.
> >
> > I wonder which use cases drove the decision to switch the order?
>
> I'd be very surprised if I halo-click a button and it would select
> the embedded label instead of the button to be able to move it. In
> most cases I am not interested in picking up the components of a
> morph, but the morph itself. "Embedding" is considered an advanced
> operation in Etoys, so the default is to narrow down the selection
> with repeated clicks rather than the opposite.
By collections I meant morphs in a book/playfield/holder etc. Here is an 
example:
I drag a curve morph onto a book. I can use redbutton to pull it out and it 
works as expected. But bluebutton halos the whole book. Since most books have 
lots of blank area to pick, this behavior is counter-intuitive. The morph 
which responds to red should also be the morph which responds to blue. Morphs 
placed in playfield work as expected. This is in 3.10 and also on 3.9.

BTW, I overheard my kids distinguish embed and drop ops thus:

 'embed' is like pasting pictures onto a sheet. It sticks and becomes one with 
the sheet. 'drop' is like placing blocks on a tray. When you move the tray, 
the blocks also move with it, but they are not one.

How's that for 'advanced' :-).

Regards .. Subbu



More information about the Squeak-dev mailing list