After Joshua's posting, I realized that it must have been an intended
feature... I noticed that Transform morphs and others are also skipped.

I guess it does make some sense, so I'm not really opposed to the change.

(By the way, I like the new factored Preferences window quite a bit.  A
nice enhancement would be the ability to easily (remotely) add a new
Preference with its own new category, rather than having new prefs always
fall under "uncategorized".  (I s'pose I could try implementing this
myself...))

- Doug Way
  EAI/Transom Technologies, Ann Arbor, MI
  http://www.transom.com
  dway at mat.net, @eai.com


On Mon, 17 Apr 2000, Scott Wallace wrote:

> At 8:23 PM -0400 4/17/00, Doug Way wrote:
> >I meant to post about this earlier, as a possible bug in 2.8alpha.
> >
> >For some reason, the SystemWindow morph is always being skipped when you
> >cycle through the various submorph halos.  I don't think this was
> >intended... I'm guessing this is a bug.
> 
> Actually, it *was* intended.
> 
> I'm sure that most users will have observed that SystemWindows have 
> an uneasy and often misleading relationship to halos.  Unlike other 
> morphs, SystemWindows come armed with their own controls for moving, 
> resizing, labeling, dismissing, and menus -- and these controls are 
> very different from the corresponding halo controls.  For example, 
> the way you resize a regular morph and the way you resize a 
> SystemWindow differ radically, and if you try to use the halo to 
> resize a SystemWindow you'll get something very strange.  And very 
> few of the standard halo-based menu items are appropriate for 
> SystemWindows.
> 
> A key goal of the halo rework was to make the standard halo-gesture 
> do what people most of the time want (and to support, by way of a 
> general "escape", a "shifted" halo gesture that allows the halo to be 
> appear on *any* object.
> 
> When working with "naked morphs" (i.e. morphs not in SystemWindows), 
> it seemed that most often the initial halo should be brought up on 
> the entire outermost naked morph, making it easy, for example, to 
> dismiss a RecordingControlsMorph (formerly this required numerous 
> successive cmd-clicks).  But that same philosophy, if applied to 
> SystemWindows, would result in users' frequently getting halos on 
> windows with their first cmd-click.
> 
> These two worlds of controls -- SystemWindows vs. 
> halos-on-other-morphs -- are so different in flavor that in the halo 
> rework, a conscious decision was made *not* to make it that easy to 
> get a halo for a SystemWindow -- though it is indeed possible, via 
> successive cmd-shift-click gestures.
> 
> Perhaps this was a wrong choice, but in any case it was made after 
> listening to many suggestions and trying out many alternatives.  I 
> still consider the choices settled on to be worthwhile improvements, 
> and I will be interested to hear other opinions on the subject -- 
> especially after the initial shock of unfamiliarity wears off.
> 
>    -- Scott
>