Hi All,
if the Transcript is open and reasonably full of text and scrolled os that the scroll bar is at the bottom right corner of the window one cannot (at least I cannot) grab the scroll bar to scroll the Transcript contents because the cursor is cooped into window resizing (the window resize cursor is shown). :-(
_,,,^..^,,,_ best, Eliot
On 23-03-2016, at 5:21 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All,
if the Transcript is open and reasonably full of text and scrolled os that the scroll bar is at the bottom right corner of the window one cannot (at least I cannot) grab the scroll bar to scroll the Transcript contents because the cursor is cooped into window resizing (the window resize cursor is shown). :-(
I think that’s a relic of the old Mac window code where one had to manually fake in a grab handle for the bottom-right since there was no place for the Mac UI to include one. It’s been unnecessary (I think) since OS X added pseudo-handles on all sides.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim There can never be a computer language in which you cannot write a bad program.
Hi Eliot,
this was a bug at the time of the 4.6/5.0 release. I fixed it in the 5.0 stream and in the trunk.
In my image under Windows, I am able to grab the scroll thumb in that case because the window contents are in front of the corner grips.
Which image version are you using?
Best, Marcel
-- View this message in context: http://forum.world.st/Impossible-to-grab-the-scroll-bar-in-the-Transcript-if... Sent from the Squeak - Dev mailing list archive at Nabble.com.
On 24.03.2016, at 07:32, marcel.taeumel Marcel.Taeumel@hpi.de wrote:
Hi Eliot,
this was a bug at the time of the 4.6/5.0 release. I fixed it in the 5.0 stream and in the trunk.
In my image under Windows, I am able to grab the scroll thumb in that case because the window contents are in front of the corner grips.
As Tim wrote, this appears to be a general Mac problem. The lower-right corner of any resizable Mac window can’t be used (in any app, so not squeak-specific).
Vertical mouse scrolling works though (but I noticed that horizontal mouse scrolling selects text instead, that is weird).
- Bert -
On 24-03-2016, at 5:15 AM, Bert Freudenberg bert@freudenbergs.de wrote: [snip] As Tim wrote, this appears to be a general Mac problem. The lower-right corner of any resizable Mac window can’t be used (in any app, so not squeak-specific).
Vertical mouse scrolling works though (but I noticed that horizontal mouse scrolling selects text instead, that is weird).
Actually I’m both right and wrong because Eliot’s problem is within the Transcript window even if it is not at the bottom-right of the total Squeak window.
In a release 50.-15113 image you can see this fairly easily in the ‘Release Notes’ window; a) scroll to the bottom b) move cursor to very near the bottom of the window and 15-20mm left of the right edge c) slowly move cursor rightwards.
Note how it changes to the window resize corner cursor way too early, about when the right edge of the cursor Form gets to the left edge of the scrollbar. Repeating with the cursor a bit higher up shows that the cursor would then change to the window resize edge cursor just as the left edge of the cursor Form touches the left edge of the window frame.
Actually I see you don’t even need to scroll the text downwards. Just do b & c above.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Unprecedented performance: Nothing ever ran this slow before.
On 24.03.2016, at 18:16, tim Rowledge tim@rowledge.org wrote:
On 24-03-2016, at 5:15 AM, Bert Freudenberg bert@freudenbergs.de wrote: [snip] As Tim wrote, this appears to be a general Mac problem. The lower-right corner of any resizable Mac window can’t be used (in any app, so not squeak-specific).
Vertical mouse scrolling works though (but I noticed that horizontal mouse scrolling selects text instead, that is weird).
Actually I’m both right and wrong because Eliot’s problem is within the Transcript window even if it is not at the bottom-right of the total Squeak window.
In a release 50.-15113 image you can see this fairly easily in the ‘Release Notes’ window; a) scroll to the bottom b) move cursor to very near the bottom of the window and 15-20mm left of the right edge c) slowly move cursor rightwards.
Note how it changes to the window resize corner cursor way too early, about when the right edge of the cursor Form gets to the left edge of the scrollbar. Repeating with the cursor a bit higher up shows that the cursor would then change to the window resize edge cursor just as the left edge of the cursor Form touches the left edge of the window frame.
Actually I see you don’t even need to scroll the text downwards. Just do b & c above.
Oh, I see. Yes, halo-click there and you see the extra “grip” morph ...
- Bert -
So the size of the slider is so small that you can not grab it because the cursor changes to rescale the window ? Should the minimum size of slider be adjusted so we don run into this issue?
Best, Karl
On Thu, Mar 24, 2016 at 6:25 PM, Bert Freudenberg bert@freudenbergs.de wrote:
On 24.03.2016, at 18:16, tim Rowledge tim@rowledge.org wrote:
On 24-03-2016, at 5:15 AM, Bert Freudenberg bert@freudenbergs.de
wrote:
[snip] As Tim wrote, this appears to be a general Mac problem. The lower-right
corner of any resizable Mac window can’t be used (in any app, so not squeak-specific).
Vertical mouse scrolling works though (but I noticed that horizontal
mouse scrolling selects text instead, that is weird).
Actually I’m both right and wrong because Eliot’s problem is within the
Transcript window even if it is not at the bottom-right of the total Squeak window.
In a release 50.-15113 image you can see this fairly easily in the
‘Release Notes’ window;
a) scroll to the bottom b) move cursor to very near the bottom of the window and 15-20mm left of
the right edge
c) slowly move cursor rightwards.
Note how it changes to the window resize corner cursor way too early,
about when the right edge of the cursor Form gets to the left edge of the scrollbar. Repeating with the cursor a bit higher up shows that the cursor would then change to the window resize edge cursor just as the left edge of the cursor Form touches the left edge of the window frame.
Actually I see you don’t even need to scroll the text downwards. Just do
b & c above.
Oh, I see. Yes, halo-click there and you see the extra “grip” morph ...
- Bert -
On Thu, Mar 24, 2016 at 11:23 AM, karl ramberg karlramberg@gmail.com wrote:
So the size of the slider is so small that you can not grab it because the cursor changes to rescale the window ?
Yes.
Should the minimum size of slider be adjusted so we don run into this issue?
IMO, no. The border of the window is more than large enough for grabbing. IMO, the area for it should not be expanded so much as to occlude the scroll bar slider.
Best, Karl
On Thu, Mar 24, 2016 at 6:25 PM, Bert Freudenberg bert@freudenbergs.de wrote:
On 24.03.2016, at 18:16, tim Rowledge tim@rowledge.org wrote:
On 24-03-2016, at 5:15 AM, Bert Freudenberg bert@freudenbergs.de
wrote:
[snip] As Tim wrote, this appears to be a general Mac problem. The
lower-right corner of any resizable Mac window can’t be used (in any app, so not squeak-specific).
Vertical mouse scrolling works though (but I noticed that horizontal
mouse scrolling selects text instead, that is weird).
Actually I’m both right and wrong because Eliot’s problem is within the
Transcript window even if it is not at the bottom-right of the total Squeak window.
In a release 50.-15113 image you can see this fairly easily in the
‘Release Notes’ window;
a) scroll to the bottom b) move cursor to very near the bottom of the window and 15-20mm left
of the right edge
c) slowly move cursor rightwards.
Note how it changes to the window resize corner cursor way too early,
about when the right edge of the cursor Form gets to the left edge of the scrollbar. Repeating with the cursor a bit higher up shows that the cursor would then change to the window resize edge cursor just as the left edge of the cursor Form touches the left edge of the window frame.
Actually I see you don’t even need to scroll the text downwards. Just
do b & c above.
Oh, I see. Yes, halo-click there and you see the extra “grip” morph ...
- Bert -
On 24-03-2016, at 11:23 AM, karl ramberg karlramberg@gmail.com wrote:
So the size of the slider is so small that you can not grab it because the cursor changes to rescale the window ?
Not exactly. Notice the region for the BottomRightGrip Morph -
It’s a side-effect of a too-simple test for whether the morph has the cursor and we have exactly the same problem on the bottom-left corner. And indeed, with less obvious effects on the top two corners.
Should the minimum size of slider be adjusted so we don run into this issue?
It’s not relevant to the actual problem so far as I can see. By some means the corner grip morphs need to be cleverer about their touchable area(s). Hmm, actually it looks like all the grips need to be a bit more careful since I see the left/bottom ones for example extend too far outwards and overlap the corners and it all looks a bit untidy.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: RCM: Randomly Corrupt Microcode
Hi Tim,
On Thu, Mar 24, 2016 at 12:37 PM, tim Rowledge tim@rowledge.org wrote:
On 24-03-2016, at 11:23 AM, karl ramberg karlramberg@gmail.com wrote:
So the size of the slider is so small that you can not grab it because the cursor changes to rescale the window ?
Not exactly. Notice the region for the BottomRightGrip Morph -
It’s a side-effect of a too-simple test for whether the morph has the cursor and we have exactly the same problem on the bottom-left corner. And indeed, with less obvious effects on the top two corners.
Lovely picture illustrating the problem perfectly. Would it be sufficient to move the grip morphs behind the morphs within the bounds of the window?
Should the minimum size of slider be adjusted so we don run into this issue?
It’s not relevant to the actual problem so far as I can see. By some means the corner grip morphs need to be cleverer about their touchable area(s). Hmm, actually it looks like all the grips need to be a bit more careful since I see the left/bottom ones for example extend too far outwards and overlap the corners and it all looks a bit untidy.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: RCM: Randomly Corrupt Microcode
_,,,^..^,,,_ best, Eliot
I have tested (on Windows, if that matters) and I do not find any problems with clicking on the slider, when the slider is minimal in size. The cursor changes from window resize to normal as soon as it's over the slider
Best, Karl
On Thu, Mar 24, 2016 at 10:48 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Tim,
On Thu, Mar 24, 2016 at 12:37 PM, tim Rowledge tim@rowledge.org wrote:
On 24-03-2016, at 11:23 AM, karl ramberg karlramberg@gmail.com wrote:
So the size of the slider is so small that you can not grab it because the cursor changes to rescale the window ?
Not exactly. Notice the region for the BottomRightGrip Morph -
It’s a side-effect of a too-simple test for whether the morph has the cursor and we have exactly the same problem on the bottom-left corner. And indeed, with less obvious effects on the top two corners.
Lovely picture illustrating the problem perfectly. Would it be sufficient to move the grip morphs behind the morphs within the bounds of the window?
Should the minimum size of slider be adjusted so we don run into this issue?
It’s not relevant to the actual problem so far as I can see. By some means the corner grip morphs need to be cleverer about their touchable area(s). Hmm, actually it looks like all the grips need to be a bit more careful since I see the left/bottom ones for example extend too far outwards and overlap the corners and it all looks a bit untidy.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: RCM: Randomly Corrupt Microcode
_,,,^..^,,,_ best, Eliot
On Thu, Mar 24, 2016 at 4:48 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Tim,
On Thu, Mar 24, 2016 at 12:37 PM, tim Rowledge tim@rowledge.org wrote:
On 24-03-2016, at 11:23 AM, karl ramberg karlramberg@gmail.com wrote:
So the size of the slider is so small that you can not grab it because the cursor changes to rescale the window ?
Not exactly. Notice the region for the BottomRightGrip Morph -
It’s a side-effect of a too-simple test for whether the morph has the cursor and we have exactly the same problem on the bottom-left corner. And indeed, with less obvious effects on the top two corners.
Lovely picture illustrating the problem perfectly. Would it be sufficient to move the grip morphs behind the morphs within the bounds of the window?
Isn't the problem simply that its extent is too large? It should simply match the width/height of the window border widths.
On 24-03-2016, at 4:21 PM, Chris Muller asqueaker@gmail.com wrote: [snip] It’s a side-effect of a too-simple test for whether the morph has the cursor and we have exactly the same problem on the bottom-left corner. And indeed, with less obvious effects on the top two corners.
Lovely picture illustrating the problem perfectly. Would it be sufficient to move the grip morphs behind the morphs within the bounds of the window?
Isn't the problem simply that its extent is too large? It should simply match the width/height of the window border widths.
Nah; notice how the extent of the grip morph is (unsurprisingly) the whole square shown, overlapping considerably with the bottom part of the scrollbar. The top-left one almost completely overlaps the close button by the way but morph precedence combined with whatever makes it not a problem. What we want is for the effective region to be an L shape not a square. Or perhaps for it to be behind the scrollbar?
If we shrunk it to the border width/height it would be only couple of pixels in size and we’d probably never be able to hit it. Especially on a high resolution display.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Try not to let implementation details sneak into design documents.
Ah, yes.
On Thu, Mar 24, 2016 at 6:28 PM, tim Rowledge tim@rowledge.org wrote:
On 24-03-2016, at 4:21 PM, Chris Muller asqueaker@gmail.com wrote: [snip] It’s a side-effect of a too-simple test for whether the morph has the cursor and we have exactly the same problem on the bottom-left corner. And indeed, with less obvious effects on the top two corners.
Lovely picture illustrating the problem perfectly. Would it be sufficient to move the grip morphs behind the morphs within the bounds of the window?
Isn't the problem simply that its extent is too large? It should simply match the width/height of the window border widths.
Nah; notice how the extent of the grip morph is (unsurprisingly) the whole square shown, overlapping considerably with the bottom part of the scrollbar. The top-left one almost completely overlaps the close button by the way but morph precedence combined with whatever makes it not a problem. What we want is for the effective region to be an L shape not a square. Or perhaps for it to be behind the scrollbar?
If we shrunk it to the border width/height it would be only couple of pixels in size and we’d probably never be able to hit it. Especially on a high resolution display.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Try not to let implementation details sneak into design documents.
I still don't get it. Why is this a Mac problem? Where is the Mac-specific part in this problem?
The size of the grip is fine because all windows contents are *in front of* that grip. So is the scroll bar and its thumb.
So, where does the platform play a role in this Squeak-specific problem?
Please see the screeshot and notice the Z-Order of things. The corner grips do not occlude the text morph and its scroll bar. http://forum.world.st/file/n4886473/squeak-z-order.png
Best, Marcel
-- View this message in context: http://forum.world.st/Impossible-to-grab-the-scroll-bar-in-the-Transcript-if... Sent from the Squeak - Dev mailing list archive at Nabble.com.
this is not a Mac-specific problem - verified it myself on Windows yesterday. It showed all of the behaviour that has been mentioned previously.
-cbc
On Fri, Mar 25, 2016 at 3:25 AM, marcel.taeumel Marcel.Taeumel@hpi.de wrote:
I still don't get it. Why is this a Mac problem? Where is the Mac-specific part in this problem?
The size of the grip is fine because all windows contents are *in front of* that grip. So is the scroll bar and its thumb.
So, where does the platform play a role in this Squeak-specific problem?
Please see the screeshot and notice the Z-Order of things. The corner grips do not occlude the text morph and its scroll bar. http://forum.world.st/file/n4886473/squeak-z-order.png
Best, Marcel
-- View this message in context: http://forum.world.st/Impossible-to-grab-the-scroll-bar-in-the-Transcript-if... Sent from the Squeak - Dev mailing list archive at Nabble.com.
The only way I can think of this happening is that a mouseEnter or mouseLeave is missed somehow.
Best, Karl
On Fri, Mar 25, 2016 at 3:32 PM, Chris Cunningham cunningham.cb@gmail.com wrote:
this is not a Mac-specific problem - verified it myself on Windows yesterday. It showed all of the behaviour that has been mentioned previously.
-cbc
On Fri, Mar 25, 2016 at 3:25 AM, marcel.taeumel Marcel.Taeumel@hpi.de wrote:
I still don't get it. Why is this a Mac problem? Where is the Mac-specific part in this problem?
The size of the grip is fine because all windows contents are *in front of* that grip. So is the scroll bar and its thumb.
So, where does the platform play a role in this Squeak-specific problem?
Please see the screeshot and notice the Z-Order of things. The corner grips do not occlude the text morph and its scroll bar. http://forum.world.st/file/n4886473/squeak-z-order.png
Best, Marcel
-- View this message in context: http://forum.world.st/Impossible-to-grab-the-scroll-bar-in-the-Transcript-if... Sent from the Squeak - Dev mailing list archive at Nabble.com.
On 25.03.2016, at 11:25, marcel.taeumel Marcel.Taeumel@hpi.de wrote:
I still don't get it. Why is this a Mac problem? Where is the Mac-specific part in this problem?
The size of the grip is fine because all windows contents are *in front of* that grip. So is the scroll bar and its thumb.
So, where does the platform play a role in this Squeak-specific problem?
Please see the screeshot and notice the Z-Order of things. The corner grips do not occlude the text morph and its scroll bar. http://forum.world.st/file/n4886473/squeak-z-order.png
There are actually two problems that look very similar but are unrelated:
(1) grips on top of the text morph
In a 5.0 image, the text morph is behind the grips. Apparently this has been fixed in the mean time, in Trunk it looks fine. This is obviously independent of platform.
(2) window “grip” on Mac
On a Mac, the VM provides a similar “grip” for the full Squeak window, which makes it impossible to click in the lower left and right corners.
So (1) appears to be fixed in trunk and (2) can not be fixed because it’s the same in all Mac apps. I’d say we’re good.
- Bert -
On 25-03-2016, at 7:56 AM, Bert Freudenberg bert@freudenbergs.de wrote:
There are actually two problems that look very similar but are unrelated:
(1) grips on top of the text morph
In a 5.0 image, the text morph is behind the grips. Apparently this has been fixed in the mean time, in Trunk it looks fine. This is obviously independent of platform.
(2) window “grip” on Mac
On a Mac, the VM provides a similar “grip” for the full Squeak window, which makes it impossible to click in the lower left and right corners.
So (1) appears to be fixed in trunk and (2) can not be fixed because it’s the same in all Mac apps. I’d say we’re good.
I know this hardly ever happens, but Bert is right :-O
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Don't sweat petty things....or pet sweaty things.
On 25.03.2016, at 19:28, tim Rowledge tim@rowledge.org wrote:
On 25-03-2016, at 7:56 AM, Bert Freudenberg bert@freudenbergs.de wrote:
There are actually two problems that look very similar but are unrelated:
(1) grips on top of the text morph
In a 5.0 image, the text morph is behind the grips. Apparently this has been fixed in the mean time, in Trunk it looks fine. This is obviously independent of platform.
(2) window “grip” on Mac
On a Mac, the VM provides a similar “grip” for the full Squeak window, which makes it impossible to click in the lower left and right corners.
So (1) appears to be fixed in trunk and (2) can not be fixed because it’s the same in all Mac apps. I’d say we’re good.
I know this hardly ever happens, but Bert is right :-O
Well, almost. I just noticed that in the 5.0 All-in-One-VM the Mac corner grip is visible, and *only* affects the lower right window corner:
... whereas in a 5.0.3602 Spur VM the grips are invisible and in both lower-left and lower-right corners.
Is this a difference between Carbon and Cocoa VMs, maybe?
- Bert -
Bert Freudenberg wrote
On 25.03.2016, at 19:28, tim Rowledge <
tim@
> wrote:
On 25-03-2016, at 7:56 AM, Bert Freudenberg <
bert@
> wrote:
There are actually two problems that look very similar but are unrelated:
(1) grips on top of the text morph
In a 5.0 image, the text morph is behind the grips. Apparently this has been fixed in the mean time, in Trunk it looks fine. This is obviously independent of platform.
(2) window “grip” on Mac
On a Mac, the VM provides a similar “grip” for the full Squeak window, which makes it impossible to click in the lower left and right corners.
So (1) appears to be fixed in trunk and (2) can not be fixed because it’s the same in all Mac apps. I’d say we’re good.
I know this hardly ever happens, but Bert is right :-O
Well, almost. I just noticed that in the 5.0 All-in-One-VM the Mac corner grip is visible, and *only* affects the lower right window corner:
... whereas in a 5.0.3602 Spur VM the grips are invisible and in both lower-left and lower-right corners.
Is this a difference between Carbon and Cocoa VMs, maybe?
- Bert -
PastedGraphic-1.png (7K) <http://forum.world.st/attachment/4886719/0/PastedGraphic-1.png%3E; smime.p7s (5K) <http://forum.world.st/attachment/4886719/1/smime.p7s%3E;
Hi, there.
In Windows 10, the grab handles are outside the (resp. adjacent to) windows and reside in the drop shadow. Since there are no window borders anymore in Windows 10, the window contents would otherwise overlap with the grips. This holds also for the corner grips.
I think we should also move our grips to the outside if SystemWindow borders are too small. The only draw back would be that full-screen windows cannot be resized anymore. Should they anyway? Maximized means maximized. :-)
Best, Marcel
-- View this message in context: http://forum.world.st/Impossible-to-grab-the-scroll-bar-in-the-Transcript-if... Sent from the Squeak - Dev mailing list archive at Nabble.com.
-1. No ghost grabbing please. Squeak is not Windows 10. Window contents don't overlap with the grips. The close-box is not "content".
Changing the mouse to resize shape when one is adjacent to the resizer just plain looks like a bug. The environment should have a "physicality" to it that users can relate to. No one clicks *next* to something to grab it.
Why does Microsoft continue to pursue such insanity? Too much overdesign zeal? The big tablet dumb-down? They turn one UI feature into a problem, and then they gotta "solve" it, by introducing another problem... Like what happened with those disasterous "auto maximize" features in Windows 8 / Ubuntu Unity. The same was already available by clicking maximize and then sizing the window down along 1 dimension which is flexible, easy and consistent with the existing window management gestures.
On Sun, Jun 5, 2016 at 12:44 AM, marcel.taeumel Marcel.Taeumel@hpi.de wrote:
Bert Freudenberg wrote
On 25.03.2016, at 19:28, tim Rowledge <
tim@
> wrote:
On 25-03-2016, at 7:56 AM, Bert Freudenberg <
bert@
> wrote:
There are actually two problems that look very similar but are unrelated:
(1) grips on top of the text morph
In a 5.0 image, the text morph is behind the grips. Apparently this has been fixed in the mean time, in Trunk it looks fine. This is obviously independent of platform.
(2) window “grip” on Mac
On a Mac, the VM provides a similar “grip” for the full Squeak window, which makes it impossible to click in the lower left and right corners.
So (1) appears to be fixed in trunk and (2) can not be fixed because it’s the same in all Mac apps. I’d say we’re good.
I know this hardly ever happens, but Bert is right :-O
Well, almost. I just noticed that in the 5.0 All-in-One-VM the Mac corner grip is visible, and *only* affects the lower right window corner:
... whereas in a 5.0.3602 Spur VM the grips are invisible and in both lower-left and lower-right corners.
Is this a difference between Carbon and Cocoa VMs, maybe?
- Bert -
PastedGraphic-1.png (7K) <http://forum.world.st/attachment/4886719/0/PastedGraphic-1.png%3E; smime.p7s (5K) <http://forum.world.st/attachment/4886719/1/smime.p7s%3E;
Hi, there.
In Windows 10, the grab handles are outside the (resp. adjacent to) windows and reside in the drop shadow. Since there are no window borders anymore in Windows 10, the window contents would otherwise overlap with the grips. This holds also for the corner grips.
I think we should also move our grips to the outside if SystemWindow borders are too small. The only draw back would be that full-screen windows cannot be resized anymore. Should they anyway? Maximized means maximized. :-)
Best, Marcel
-- View this message in context: http://forum.world.st/Impossible-to-grab-the-scroll-bar-in-the-Transcript-if... Sent from the Squeak - Dev mailing list archive at Nabble.com.
Chris Muller-3 wrote
-1. No ghost grabbing please. Squeak is not Windows 10. Window contents don't overlap with the grips. The close-box is not "content".
Changing the mouse to resize shape when one is adjacent to the resizer just plain looks like a bug. The environment should have a "physicality" to it that users can relate to. No one clicks *next* to something to grab it.
Why does Microsoft continue to pursue such insanity? Too much overdesign zeal? The big tablet dumb-down? They turn one UI feature into a problem, and then they gotta "solve" it, by introducing another problem... Like what happened with those disasterous "auto maximize" features in Windows 8 / Ubuntu Unity. The same was already available by clicking maximize and then sizing the window down along 1 dimension which is flexible, easy and consistent with the existing window management gestures.
On Sun, Jun 5, 2016 at 12:44 AM, marcel.taeumel <
Marcel.Taeumel@
> wrote:
Bert Freudenberg wrote
On 25.03.2016, at 19:28, tim Rowledge <
tim@
> wrote:
On 25-03-2016, at 7:56 AM, Bert Freudenberg <
bert@
> wrote:
There are actually two problems that look very similar but are unrelated:
(1) grips on top of the text morph
In a 5.0 image, the text morph is behind the grips. Apparently this has been fixed in the mean time, in Trunk it looks fine. This is obviously independent of platform.
(2) window “grip” on Mac
On a Mac, the VM provides a similar “grip” for the full Squeak window, which makes it impossible to click in the lower left and right corners.
So (1) appears to be fixed in trunk and (2) can not be fixed because it’s the same in all Mac apps. I’d say we’re good.
I know this hardly ever happens, but Bert is right :-O
Well, almost. I just noticed that in the 5.0 All-in-One-VM the Mac corner grip is visible, and *only* affects the lower right window corner:
... whereas in a 5.0.3602 Spur VM the grips are invisible and in both lower-left and lower-right corners.
Is this a difference between Carbon and Cocoa VMs, maybe?
- Bert -
PastedGraphic-1.png (7K) <http://forum.world.st/attachment/4886719/0/PastedGraphic-1.png%3E; smime.p7s (5K) <http://forum.world.st/attachment/4886719/1/smime.p7s%3E;
Hi, there.
In Windows 10, the grab handles are outside the (resp. adjacent to) windows and reside in the drop shadow. Since there are no window borders anymore in Windows 10, the window contents would otherwise overlap with the grips. This holds also for the corner grips.
I think we should also move our grips to the outside if SystemWindow borders are too small. The only draw back would be that full-screen windows cannot be resized anymore. Should they anyway? Maximized means maximized. :-)
Best, Marcel
-- View this message in context: http://forum.world.st/Impossible-to-grab-the-scroll-bar-in-the-Transcript-if... Sent from the Squeak - Dev mailing list archive at Nabble.com.
Hi Chris,
after reading your response several times to look for some useful feedback, I think I actually found some. Here is what I found:
1. It is advisable to make suggestions about changes to Squeak without referring to systems were many people have mixed feelings about. A somewhat neutral and objective perspective is more likely to foster fruitful discussions.
2. Squeak's windows do have borders where the resize grips perfectly fit in without covering the window's contents or control buttons. There is no need to move the grips to the outside of the window.
3. From a user perspective, Squeak's resize grips have a visual representation, which is the window border itself.
4. The shadow of a window is not part of the window. A click into the shadow of a window means clicking next to it or behind it.
While I totally agree with the points 1 and 2, I kind of disagree with 3 and 4. However, this is just my personal experience. I am not aware of any studies that confirm or refute these statements.
Now, just for a moment, let's think about and discuss zero-border windows.
Apple's Mac OS has been having them for a long time. Once, there was only the grip in the bottom right corner to resize a window. Nowadays, there are also grips for the edges. Tobias showed me that in a recent version and it seems that the edge grips partially overlap the window contents because there is no window border. They do, however, not really really into the window's shadow. Anyway, the grips do not have a visual representation other than the changing mouse cursor when hovering over them. Looking at the OS X Human Interface Guidelines, grips are only mentioned very briefly: https://developer.apple.com/library/mac/documentation/UserExperience/Concept...
Microsoft's Windows 10 reduced window borders down to a single pixel. It looks like the window borders in Mac OS X. The grips, however, do not overlap with the window contents but reach into the window's drop shadow. In my daily experience, I had no troubles resizing windows via the grips.
I have no real experience with Ubuntu/Linux (resp. Gnome, KDE, ...).
*~*~*~*
Why was I writing about this? About a year ago, I refactored some magic numbers to make the border thickness of Squeak's windows configurable. Especially in the face of Hi-DPI, this should work to provide bigger borders in the sense of pixels to keep their effective size similar. Then I thought: "Why does there have to be a border at all?" ... when it might be used for real content instead. But what about the window grips? If they would overlap the content, it would be somewhat annoying. Then I discovered the way Windows 10 does it, and I liked it.
That's it. Thanks for your time.
Best, Marcel
-- View this message in context: http://forum.world.st/Impossible-to-grab-the-scroll-bar-in-the-Transcript-if... Sent from the Squeak - Dev mailing list archive at Nabble.com.
after reading your response several times to look for some useful feedback, I think I actually found some. Here is what I found:
LOL! Okay. Thanks for understanding that I'm passionate about proposals which I consider to erode the multi-windowing UI metaphor.
- It is advisable to make suggestions about changes to Squeak without
referring to systems were many people have mixed feelings about. A somewhat neutral and objective perspective is more likely to foster fruitful discussions.
- Squeak's windows do have borders where the resize grips perfectly fit in
without covering the window's contents or control buttons. There is no need to move the grips to the outside of the window.
- From a user perspective, Squeak's resize grips have a visual
representation, which is the window border itself.
- The shadow of a window is not part of the window. A click into the shadow
of a window means clicking next to it or behind it.
While I totally agree with the points 1 and 2, I kind of disagree with 3 and 4. However, this is just my personal experience. I am not aware of any studies that confirm or refute these statements.
Now, just for a moment, let's think about and discuss zero-border windows.
Apple's Mac OS has been having them for a long time. Once, there was only the grip in the bottom right corner to resize a window. Nowadays, there are also grips for the edges. Tobias showed me that in a recent version and it seems that the edge grips partially overlap the window contents because there is no window border. They do, however, not really really into the window's shadow. Anyway, the grips do not have a visual representation other than the changing mouse cursor when hovering over them. Looking at the OS X Human Interface Guidelines, grips are only mentioned very briefly: https://developer.apple.com/library/mac/documentation/UserExperience/Concept...
Microsoft's Windows 10 reduced window borders down to a single pixel. It looks like the window borders in Mac OS X. The grips, however, do not overlap with the window contents but reach into the window's drop shadow. In my daily experience, I had no troubles resizing windows via the grips.
I have no real experience with Ubuntu/Linux (resp. Gnome, KDE, ...).
Ubuntu 14.04 default settings do the same thing Windows does -- make resizing grips well beyond the outer edge of the window -- which is incredibly annoying, because 1) it interferes with the content and/or edges of adjacent windows, which I sometimes want to interact with (or resize to be closely side-by-side), but can't because it keeps grabbing the resizer of the window which I'm not even clicking because, 2) it has defied the physicality of the environment (this is what I referred to as the "insanity"), and established a new paradigm to the user that there are "invisible regions" on the screen which are actually sensitive to input.
Why was I writing about this? About a year ago, I refactored some magic numbers to make the border thickness of Squeak's windows configurable. Especially in the face of Hi-DPI, this should work to provide bigger borders in the sense of pixels to keep their effective size similar.
That sounds good..
Then I thought: "Why does there have to be a border at all?" ... when it might be used for real content instead. But what about the window grips? If they would overlap the content, it would be somewhat annoying. Then I discovered the way Windows 10 does it, and I liked it.
Invisible grips are gonna overlap either to the inside or the outside right? Making the assumption that overlapping to the outside triggers my sensitivity about this subject, because it assumes and encourages that modal-thinking revolution. IMO, we should stand strong against that and show the world what Smalltalk showed them 33 years ago -- windows are visible and physical, and present an object-centric interface (rather than command-centric) which, unlike tablet interfaces, allows seamless integration of disparate domains.
Best, Chris
On 07.06.2016, at 19:29, Chris Muller asqueaker@gmail.com wrote:
Ubuntu 14.04 default settings do the same thing Windows does -- make resizing grips well beyond the outer edge of the window -- which is incredibly annoying, because 1) it interferes with the content and/or edges of adjacent windows, which I sometimes want to interact with (or resize to be closely side-by-side), but can't because it keeps grabbing the resizer of the window which I'm not even clicking because, 2) it has defied the physicality of the environment (this is what I referred to as the "insanity"), and established a new paradigm to the user that there are "invisible regions" on the screen which are actually sensitive to input.
Zero-width window borders (with a nice soft shadow) manage to provide maximum screen real estate while being exactly as usable as “wide” borders. I have no problems at all resizing windows on a Mac - I put my mouse pointer on the border (which is very visible, plus the pointer shape changes), drag and resize.
Invisible grips are gonna overlap either to the inside or the outside right? Making the assumption that overlapping to the outside triggers my sensitivity about this subject, because it assumes and encourages that modal-thinking revolution. IMO, we should stand strong against that and show the world what Smalltalk showed them 33 years ago -- windows are visible and physical, and present an object-centric interface (rather than command-centric) which, unlike tablet interfaces, allows seamless integration of disparate domains.
The old Smalltalk UI for resizing was *way* more modal. You had to choose “reframe” from the blue-button menu and then rubber-band the new window frame. We’ve come a long way from that (so much so that Alan made me put in corner resizing in our Smalltalk-78 revival).
Not every “newer” UX is bad. +1 for zero-width borders (provided we do have nice soft-shadows to indicate window stacking - on slower machines we should have clearly visible opaque borders)
- Bert -
Ubuntu 14.04 default settings do the same thing Windows does -- make resizing grips well beyond the outer edge of the window -- which is incredibly annoying, because 1) it interferes with the content and/or edges of adjacent windows, which I sometimes want to interact with (or resize to be closely side-by-side), but can't because it keeps grabbing the resizer of the window which I'm not even clicking because, 2) it has defied the physicality of the environment (this is what I referred to as the "insanity"), and established a new paradigm to the user that there are "invisible regions" on the screen which are actually sensitive to input.
Zero-width window borders (with a nice soft shadow) manage to provide maximum screen real estate
No, they don't. Did you understand what I wrote? There is no more real-estate available than normal "thick" borders because you don't have use of those 4-pixels that extend beyond that "thin" edge -- i.e.. where the shadow is. That's your "fake thick resizer". Its visually deceptive and totally interferes with usability when one is working with multiple windows. But hey, who ever works in multiple windows right? Taht was my point about designers dumbing interfaces down to "one app at a time like a phone or tablet"..
So they give a false appearance that they're "thin", they've crossed a line that had not crossed before -- they took the physicality of the system away in favor of "magic invisible regions".
Plus, it is now ambiguous with windows that are not resizable. Remember when it was only non-resizable dialogs that had the thin border? Before, there was that visual cue, now, its ambigous.
IMO, its a big design mistake that only ever gained any acceptance because of its "eye-candy" nature. Imagine if they tried to pull this off without a soft shadow, but with a simple translucent rectangle like Squeaks classic shadow -- I think it would never have been accepted over thick borders because it doesn't look pretty enough..
On 08.06.2016, at 17:04, Chris Muller asqueaker@gmail.com wrote:
Bert wrote:
Zero-width window borders (with a nice soft shadow) manage to provide maximum screen real estate
No, they don’t.
Yes, they do. I see about one character’s width more of the back window.
[...] interferes with usability when one is working with multiple windows
Not for me.
I should point out that I *like* the wide borders on Squeak windows, just not for the reason of usability (which IMHO is unaffected by that). I like them because I like colored windows, so I want a colored window frame on each system window. Our current ones could be made to look a bit nicer, but they do have a purpose.
OTOH I know Marcel likes gray windows, and in that case the borders do not serve a good purpose. So having the option of borderless windows seems useful.
- Bert -
On 25-03-2016, at 3:25 AM, marcel.taeumel Marcel.Taeumel@hpi.de wrote:
I still don't get it. Why is this a Mac problem? Where is the Mac-specific part in this problem?
It’s not; except that a similar problem does exist at the Mac-Window level. It was me mistaking Eliot’s description.
Please see the screeshot and notice the Z-Order of things. The corner grips do not occlude the text morph and its scroll bar. http://forum.world.st/file/n4886473/squeak-z-order.png
Except the behaviour doesn’t support what we think ought to be happening.
And look at the screen grab from my iMac running a 5.0-15113 image -
The text morph (along with its scrollers) is the last item rather than the first. Weird, eh?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Tight slacks
Hi Tim,
in your 5.0 image, just hit the "update" button. :-)
Name: squeak50/Morphic-mt.996 Author: mt Time: 15 January 2016, 1:38:12.241 pm UUID: 5f2a2387-02db-8d42-bbc8-cf70c34c27be Ancestors: Morphic-cmm.995
Ports a fix from trunk regarding Z hierarchy of corner grips in system windows. For example, you can now again select the first characters in the annotation pane in system browsers.
Best, Marcel
-- View this message in context: http://forum.world.st/Impossible-to-grab-the-scroll-bar-in-the-Transcript-if... Sent from the Squeak - Dev mailing list archive at Nabble.com.
On Mar 25, 2016, at 11:54 PM, marcel.taeumel Marcel.Taeumel@hpi.de wrote:
Hi Tim,
in your 5.0 image, just hit the "update" button. :-)
and reopen the transcript, workspace, etc. The update applies to newly opened Windows. It doesn't edit existing windows (which seems perfectly reasonable to me).
Name: squeak50/Morphic-mt.996 Author: mt Time: 15 January 2016, 1:38:12.241 pm UUID: 5f2a2387-02db-8d42-bbc8-cf70c34c27be Ancestors: Morphic-cmm.995
Ports a fix from trunk regarding Z hierarchy of corner grips in system windows. For example, you can now again select the first characters in the annotation pane in system browsers.
Best, Marcel
-- View this message in context: http://forum.world.st/Impossible-to-grab-the-scroll-bar-in-the-Transcript-if... Sent from the Squeak - Dev mailing list archive at Nabble.com.
In a existing window you can always inspect the BottomRightGripMorph and send it a 'self goBehind'.
Best, Karl
On Sat, Mar 26, 2016 at 3:48 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Mar 25, 2016, at 11:54 PM, marcel.taeumel Marcel.Taeumel@hpi.de
wrote:
Hi Tim,
in your 5.0 image, just hit the "update" button. :-)
and reopen the transcript, workspace, etc. The update applies to newly opened Windows. It doesn't edit existing windows (which seems perfectly reasonable to me).
Name: squeak50/Morphic-mt.996 Author: mt Time: 15 January 2016, 1:38:12.241 pm UUID: 5f2a2387-02db-8d42-bbc8-cf70c34c27be Ancestors: Morphic-cmm.995
Ports a fix from trunk regarding Z hierarchy of corner grips in system windows. For example, you can now again select the first characters in
the
annotation pane in system browsers.
Best, Marcel
-- View this message in context:
http://forum.world.st/Impossible-to-grab-the-scroll-bar-in-the-Transcript-if...
Sent from the Squeak - Dev mailing list archive at Nabble.com.
On Mar 26, 2016, at 8:16 AM, karl ramberg karlramberg@gmail.com wrote:
In a existing window you can always inspect the BottomRightGripMorph and send it a 'self goBehind'.
So how about a post load that iterates over all system Windows and does this?
Best, Karl
On Sat, Mar 26, 2016 at 3:48 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Mar 25, 2016, at 11:54 PM, marcel.taeumel Marcel.Taeumel@hpi.de wrote:
Hi Tim,
in your 5.0 image, just hit the "update" button. :-)
and reopen the transcript, workspace, etc. The update applies to newly opened Windows. It doesn't edit existing windows (which seems perfectly reasonable to me).
Name: squeak50/Morphic-mt.996 Author: mt Time: 15 January 2016, 1:38:12.241 pm UUID: 5f2a2387-02db-8d42-bbc8-cf70c34c27be Ancestors: Morphic-cmm.995
Ports a fix from trunk regarding Z hierarchy of corner grips in system windows. For example, you can now again select the first characters in the annotation pane in system browsers.
Best, Marcel
-- View this message in context: http://forum.world.st/Impossible-to-grab-the-scroll-bar-in-the-Transcript-if... Sent from the Squeak - Dev mailing list archive at Nabble.com.
SystemWindow allSubInstancesDo: [:ea | ea paneMorphs do: #comeToFront. ea labelArea comeToFront].
Best, Marcel
-- View this message in context: http://forum.world.st/Impossible-to-grab-the-scroll-bar-in-the-Transcript-if... Sent from the Squeak - Dev mailing list archive at Nabble.com.
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Chris Cunningham -
Chris Muller -
Chris Muller -
Eliot Miranda -
karl ramberg -
marcel.taeumel -
tim Rowledge