[BUG] Halo skips SystemWindow in Morphic (2.8alpha)

Doug Way dway at mat.net
Sun Apr 30 16:22:14 UTC 2000


(Apologies to the list, this was meant to be a private email
reply... sorry.)


On Fri, 28 Apr 2000, Doug Way wrote:

> 
> Stephan, I meant to thank you earlier for this changeset.
> 
> I'm using it with my Whisker browser changeset, since Whisker adds a few
> preferences I wanted to add them in a "whisker" prefs category.  (See
> http://www.mindspring.com/~dway/Whisker-dew.27Apr1647.cs if you're
> curious.)
> 
> Thanks again,
> 
> - Doug Way
>   dway at mat.net
> 
> 
> On Wed, 19 Apr 2000, Stephan Rudlof wrote:
> 
> > Doug,
> > 
> > Doug Way wrote:
> > > 
> > > 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...))
> > 
> > Here is a working quick&dirty solution, but I think it is not in the
> > 'spirit' of the Preferences class:
> > 
> > 'From Squeak2.8alpha of 25 March 2000 [latest update: #1974] on 19 April
> > 2000 at 4:55:11 pm'!
> > 
> > !Preferences class methodsFor: 'add preferences' stamp: 'sr 4/19/2000
> > 16:54'!
> > addPreference: prefSymbol category: categorySymbol default: defaultFlag
> > balloonHelp: helpString 
> > 	self class compileProgrammatically: (#initialValuesAddition ,
> > categorySymbol , prefSymbol) asString , '
> > 	^ #((' , prefSymbol asSymbol, ' ' , defaultFlag printString , ' (' ,
> > categorySymbol asSymbol, ' ) ) )' classified: 'initial values'.
> > 
> > 	self class compileProgrammatically: (#helpMsgsAddition , categorySymbol
> > , prefSymbol) asString , '
> > 	^ #((' , prefSymbol, ' ', helpString printString, ' ) )' classified:
> > 'help'.
> > 
> > 	self absorbAdditions
> > ! !
> > 
> > and then eval
> > 	Preferences addPreference: #testPref category: #testCat default: false
> > balloonHelp: 'test help'
> > in a workspace.
> > 
> > 
> > BTW: What happens if two preferences have the same name, but different
> > categories? It seems to me that only one balloon help is possible
> > then...
> > 
> > 
> > Regards,
> > 
> > Stephan
> > 
> > 
> > > 
> > > - 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
> > > >
> > 
> > -- 
> > Stephan Rudlof (sr at evolgo.de)
> >    "Genius doesn't work on an assembly line basis.
> >     You can't simply say, 'Today I will be brilliant.'"
> >     -- Kirk, "The Ultimate Computer", stardate 4731.3
> > 
> > 
> 
> 





More information about the Squeak-dev mailing list