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

Stephan Rudlof sr at evolgo.de
Wed Apr 19 15:02:45 UTC 2000


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