Smalltalk › Squeak › Squeak - Dev

Impossible to grab the scroll bar in the Transcript if...

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

33 messages Options

marcel.taeumel

Re: Impossible to grab the scroll bar in the Transcript if...

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

Bert Freudenberg

Re: Impossible to grab the scroll bar in the Transcript if...

In reply to this post by timrowledge

On 25.03.2016, at 19:28, tim Rowledge <[hidden email]> wrote:

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

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 -

smime.p7s (5K) Download Attachment

Eliot Miranda-2

Re: Impossible to grab the scroll bar in the Transcript if...

In reply to this post by marcel.taeumel

> On Mar 25, 2016, at 11:54 PM, marcel.taeumel <[hidden email]> 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-tp4886210p4886663.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>

Karl Ramberg

Re: Impossible to grab the scroll bar in the Transcript if...

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 <[hidden email]> wrote:

> On Mar 25, 2016, at 11:54 PM, marcel.taeumel <[hidden email]> 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-tp4886210p4886663.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>

Eliot Miranda-2

Re: Impossible to grab the scroll bar in the Transcript if...

On Mar 26, 2016, at 8:16 AM, karl ramberg <[hidden email]> 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 <[hidden email]> wrote:

> On Mar 25, 2016, at 11:54 PM, marcel.taeumel <[hidden email]> 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-tp4886210p4886663.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>

marcel.taeumel

Re: Impossible to grab the scroll bar in the Transcript if...

SystemWindow allSubInstancesDo: [:ea |
ea paneMorphs do: #comeToFront.
ea labelArea comeToFront].

Best,
Marcel

marcel.taeumel

Re: Impossible to grab the scroll bar in the Transcript if...

In reply to this post by Bert Freudenberg

Bert Freudenberg wrote

> On 25.03.2016, at 19:28, tim Rowledge <[hidden email]> wrote:
>
>
>> 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

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>
smime.p7s (5K) <http://forum.world.st/attachment/4886719/1/smime.p7s>

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

Chris Muller-3

Re: Impossible to grab the scroll bar in the Transcript if...

-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 <[hidden email]> 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>
>> smime.p7s (5K)
>> <http://forum.world.st/attachment/4886719/1/smime.p7s>
>
> 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-tp4886210p4899235.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>

marcel.taeumel

Re: Impossible to grab the scroll bar in the Transcript if...

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 <[hidden email]> 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>
>> smime.p7s (5K)
>> <http://forum.world.st/attachment/4886719/1/smime.p7s>
>
> 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-tp4886210p4899235.html
> 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/Conceptual/OSXHIGuidelines/WindowAppearanceBehavior.html

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

Chris Muller-3

Re: Impossible to grab the scroll bar in the Transcript if...

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

> 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/Conceptual/OSXHIGuidelines/WindowAppearanceBehavior.html
>
> 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

Bert Freudenberg

Re: Impossible to grab the scroll bar in the Transcript if...

On 07.06.2016, at 19:29, Chris Muller <[hidden email]> 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 -

smime.p7s (5K) Download Attachment

Chris Muller-3

Re: Impossible to grab the scroll bar in the Transcript if...

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

Bert Freudenberg

Re: Impossible to grab the scroll bar in the Transcript if...

On 08.06.2016, at 17:04, Chris Muller <[hidden email]> 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 -

smime.p7s (5K) Download Attachment