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
On Mon, 17 Apr 2000, Scott Wallace wrote:
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.
Really? It seems to do the same most of the time. And sometimes the little yellow handle in the lower right won't appear. For example, if you make the pref window smaller than the tabbedPalette.
That playfield thingy in the prefs behaves odd anyway ... It eats all menus because it's open to d&d. But even if I seal it, a menu that I place over it animates to it's former position. Also, If I bring up the red halo menu for it and make it stay up, I can't open the playfield options menu from there. Perhaps playfields shouldn't be used in normal windows at all?
But back to halos: I find it distracting that the halo is brought up for the full bounds even if the morph causing the wide bounds is clipped. Or is this a bug and fullbounds should only enclose the visible part of all submorphs? Also, a morph's control menu is brought up via fullContainsPoint, so even if I click into the void it is displayed. You can try this by making a browser with opt buttons smaller than the button row (so that it sticks out to the right), and click outside the browser but within it's full bounds.
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.
IMHO it's still too easy to get a halo. With a real mouse, it's only one click and you ripped a pane off a browser.
Sorry, no fixes today.
-Bert-
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@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
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
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@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@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@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
(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@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@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@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
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Doug Way -
Scott Wallace -
Stephan Rudlof