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@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