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 <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim There can never be a computer language in which you cannot write a bad program. |
In reply to this post by Eliot Miranda-2
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 |
> On 24.03.2016, at 07:32, marcel.taeumel <[hidden email]> 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 - smime.p7s (5K) Download Attachment |
> On 24-03-2016, at 5:15 AM, Bert Freudenberg <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim Unprecedented performance: Nothing ever ran this slow before. |
> On 24.03.2016, at 18:16, tim Rowledge <[hidden email]> wrote: > > >> On 24-03-2016, at 5:15 AM, Bert Freudenberg <[hidden email]> 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 - smime.p7s (5K) Download Attachment |
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 <[hidden email]> wrote:
|
On Thu, Mar 24, 2016 at 11:23 AM, karl ramberg <[hidden email]> wrote:
Yes.
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, Eliot |
In reply to this post by Karl Ramberg
On 24-03-2016, at 11:23 AM, karl ramberg <[hidden email]> wrote: 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? tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: RCM: Randomly Corrupt Microcode |
Hi Tim,
On Thu, Mar 24, 2016 at 12:37 PM, tim Rowledge <[hidden email]> wrote:
Lovely picture illustrating the problem perfectly. Would it be sufficient to move the grip morphs behind the morphs within the bounds of the window?
_,,,^..^,,,_ 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 <[hidden email]> wrote:
|
In reply to this post by Eliot Miranda-2
On Thu, Mar 24, 2016 at 4:48 PM, Eliot Miranda <[hidden email]> wrote:
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 <[hidden email]> 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; [hidden email]; 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 <[hidden email]> wrote: > >> On 24-03-2016, at 4:21 PM, Chris Muller <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim > Try not to let implementation details sneak into design documents. > > |
In reply to this post by Chris Muller-3
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. Best, Marcel |
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 <[hidden email]> wrote: I still don't get it. Why is this a Mac problem? Where is the Mac-specific |
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 <[hidden email]> wrote:
|
In reply to this post by marcel.taeumel
On 25.03.2016, at 11:25, marcel.taeumel <[hidden email]> 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 - smime.p7s (5K) Download Attachment |
In reply to this post by marcel.taeumel
On 25-03-2016, at 3:25 AM, marcel.taeumel <[hidden email]> wrote:
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? |
In reply to this post by Bert Freudenberg
> On 25-03-2016, at 7:56 AM, Bert Freudenberg <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim Don't sweat petty things....or pet sweaty things. |
Free forum by Nabble | Edit this page |