Smalltalk › Squeak › Squeak - Dev

text selection broken

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

12 messages Options

Chris Muller-4

text selection broken

Clicking beyond the end of a text is no longer responsive.

I use it to quickly and easily select / deselect text in a workspaces.

I keep thinking something has locked up..

Please do not break gross-motor gestures..!

One of your changes Marcel?

Chris Muller-3

Re: text selection broken

> Please do not break gross-motor gestures..!

Err, I mean, this gesture is a good one, we should keep it. :)

Levente Uzonyi

Re: text selection broken

In reply to this post by Chris Muller-4

It still works for me.

Levente

On Mon, 16 May 2016, Chris Muller wrote:

> Clicking beyond the end of a text is no longer responsive.
>
> I use it to quickly and easily select / deselect text in a workspaces.
>
> I keep thinking something has locked up..
>
> Please do not break gross-motor gestures..!
>
> One of your changes Marcel?
>
>

Chris Muller-3

Re: text selection broken

Are you running the latest updates to 15956? I just verified it
against a Squeak5.1-15113 (with stock preferences). Before updating,
clicking *below* the last line of any text or code pane works
normally. After updating, it doesn't.

On Mon, May 16, 2016 at 8:07 PM, Levente Uzonyi <[hidden email]> wrote:

> It still works for me.
>
> Levente
>
>
> On Mon, 16 May 2016, Chris Muller wrote:
>
>> Clicking beyond the end of a text is no longer responsive.
>>
>> I use it to quickly and easily select / deselect text in a workspaces.
>>
>> I keep thinking something has locked up..
>>
>> Please do not break gross-motor gestures..!
>>
>> One of your changes Marcel?
>>
>>
>

Levente Uzonyi

Re: text selection broken

On Mon, 16 May 2016, Chris Muller wrote:

> Are you running the latest updates to 15956? I just verified it
> against a Squeak5.1-15113 (with stock preferences). Before updating,
> clicking *below* the last line of any text or code pane works
> normally. After updating, it doesn't.

You're right. If the code pane has extra space below the text, then
clicking there won't select anything. Clicking the empty area in the last
line still works though.

Levente

>
> On Mon, May 16, 2016 at 8:07 PM, Levente Uzonyi <[hidden email]> wrote:
>> It still works for me.
>>
>> Levente
>>
>>
>> On Mon, 16 May 2016, Chris Muller wrote:
>>
>>> Clicking beyond the end of a text is no longer responsive.
>>>
>>> I use it to quickly and easily select / deselect text in a workspaces.
>>>
>>> I keep thinking something has locked up..
>>>
>>> Please do not break gross-motor gestures..!
>>>
>>> One of your changes Marcel?
>>>
>>>
>>
>
>

marcel.taeumel

Re: text selection broken

Hi, there.

Yes, I changed that to address an issue with method templates and the focus *not* following the mouse cursor but requiring a click: http://forum.world.st/The-Trunk-Morphic-mt-1144-mcz-td4894605.html

We can discuss the impact of such trade-off but let me first explain the technical perspective and the offer some alternatives to the issues at hand.

A mouse click in a pluggable text morph can target three different areas:
A) Inside text (lines), inside text morph, inside pluggable text morph
B) Outside text (lines), inside text morph, inside pluggable text morph
C) Outside text (lines), outside text morph, inside pluggable text morph

Here is the situation for method templates:

Here is the situation with a method that is larger than the screen space available:

Here is the situation with a one-liner, for example, our world search bar:

Before my change in Morphic-mt.1144, B and C provided the same behavior. Now, C does nothing to the text selection while B still does. Now, a large area C helps for extending the behavior of B. Note that we still have CMD+A to select the whole text and I assume we follow a bi-manual interaction scheme using both keyboard and mouse on a regular basis. Additionally, I noticed a strong interest in good keyboard shortcuts around here. :-)

So, I see the following options here:

1) Make C only behave differently to B when the focus does not follow the mouse cursor. Either way, make C behave like B when facing a one-line text morph such as our search bar.
2) Always make C behave like B and ignore the issue with the method template.
3) Keep it as it is now, meaning C is always different to B.

You votes?

Best,
Marcel

Bert Freudenberg

Re: text selection broken

On 17.05.2016, at 10:45, marcel.taeumel <[hidden email]> wrote:

>
> I see the following options here:
>
> 1) Make C only behave differently to B when the focus does not follow the
> mouse cursor. Either way, make C behave like B when facing a one-line text
> morph such as our search bar.
> 2) Always make C behave like B and ignore the issue with the method
> template.
> 3) Keep it as it is now, meaning C is always different to B.
>
> You votes?

IMHO it shouldn’t matter if you click in A, B, or C. And I’m not sure what the special issue with the template is.

When focus-follows-mouse is disabled, the first click should only set the focus and not change the selection no matter where you click. When focus-follows-mouse is enabled, the field is already focused. In both cases, clicking in a focused text field will then change the selection.

Wouldn’t that be the simplest option? AFAICT that’s how text fields work in general (outside Squeak).

- Bert -

smime.p7s (5K) Download Attachment

marcel.taeumel

Re: text selection broken

Hi Bert,

this would make list interaction awkward. Having to double-click an item if it is in another list... :-/ I think that such extra activation, as configurable for system windows, is neither necessary nor convenient for widgets.

I just tried it out with the Firefox address bar, it directly sets the text cursor. It is not even capable of keeping the selection if not focused. :-D

Best,
Marcel

Bert Freudenberg

Re: text selection broken

On 17.05.2016, at 20:22, marcel.taeumel <[hidden email]> wrote:
>
> Hi Bert,
>
> this would make list interaction awkward. Having to double-click an item if
> it is in another list... :-/ I think that such extra activation, as
> configurable for system windows, is neither necessary nor convenient for
> widgets.

I thought we were talking about text, not lists.

> I just tried it out with the Firefox address bar, it directly sets the text
> cursor. It is not even capable of keeping the selection if not focused. :-D

On the Mac, the first click in the address bar activates the window. The second sets the cursor.

- Bert -

smime.p7s (5K) Download Attachment

Chris Muller-3

Re: text selection broken

In reply to this post by marcel.taeumel

Hi Marcel, thanks for the good visual explanation. It does seem
tempting, at least initially, given that we *can* make different
behaviors for red-clicking in B or C, to maybe find some opportunity
to extend some functionality..

However, such delineation of B from C comes at too much cost. First
casualty is the "Add a new line of code to a method" use-case.. Its
just *too common* that the user will click below the last line, often
right where they wish to place the cursor to start typing the new line..

.. but since most methods did not end with a blank line, the effect is
\nothing\, and there's this inevitable few seconds of disconcert where
the system feels non-responsive..

Its a totally understandable confusion because, visually, all the
user knows is they clicked inside the nougat of the text widget.
They expected all of that area to be sensitive to input. A red-click
there should be responsive. For it to not be so is truly a disruptive
experience that pulls me right out of my thoughts.

So, I guess I would vote for option 2, with a fallback vote for option 1.

Wait, how about option 4? --> If Focus Follows Mouse and
mouseOverForKeyboardFocus are both Disabled, then don't pre-select the
contents of the method template, so when they click down there, it'll
select it all and then they can just start typing..??

Even still, people who use Click For Focus are *accustomed* to
having to make extra clicks, constantly, all the time..!
mouseOverForKeyboardFocus is the only real way to de-couple widget
focus from application input..

On Tue, May 17, 2016 at 3:45 AM, marcel.taeumel <[hidden email]> wrote:

> Hi, there.
>
> Yes, I changed that to address an issue with method templates and the focus
> *not* following the mouse cursor but requiring a click:
> http://forum.world.st/The-Trunk-Morphic-mt-1144-mcz-td4894605.html
>
> We can discuss the impact of such trade-off but let me first explain the
> technical perspective and the offer some alternatives to the issues at hand.
>
> A mouse click in a pluggable text morph can target three different areas:
> A) Inside text (lines), inside text morph, inside pluggable text morph
> B) Outside text (lines), inside text morph, inside pluggable text morph
> C) Outside text (lines), outside text morph, inside pluggable text morph
>
> Here is the situation for method templates:
> <http://forum.world.st/file/n4895300/squeak-text-1.png>
>
> Here is the situation with a method that is larger than the screen space
> available:
> <http://forum.world.st/file/n4895300/squeak-text-2.png>
>
> Here is the situation with a one-liner, for example, our world search bar:
> <http://forum.world.st/file/n4895300/squeak-text-3.png>
>
> Before my change in Morphic-mt.1144, B and C provided the same behavior.
> Now, C does nothing to the text selection while B still does. Now, a large
> area C helps for extending the behavior of B. Note that we still have CMD+A
> to select the whole text and I assume we follow a bi-manual interaction
> scheme using both keyboard and mouse on a regular basis. Additionally, I
> noticed a strong interest in good keyboard shortcuts around here. :-)
>
> So, I see the following options here:
>
> 1) Make C only behave differently to B when the focus does not follow the
> mouse cursor. Either way, make C behave like B when facing a one-line text
> morph such as our search bar.
> 2) Always make C behave like B and ignore the issue with the method
> template.
> 3) Keep it as it is now, meaning C is always different to B.
>
> You votes?
>
> Best,
> Marcel
>
>
>
> --
> View this message in context: http://forum.world.st/text-selection-broken-tp4895226p4895300.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>

Eliot Miranda-2

Re: text selection broken

In reply to this post by Bert Freudenberg

> On May 17, 2016, at 12:19 PM, Bert Freudenberg <[hidden email]> wrote:
>
>> On 17.05.2016, at 20:22, marcel.taeumel <[hidden email]> wrote:
>>
>> Hi Bert,
>>
>> this would make list interaction awkward. Having to double-click an item if
>> it is in another list... :-/ I think that such extra activation, as
>> configurable for system windows, is neither necessary nor convenient for
>> widgets.
>
> I thought we were talking about text, not lists.
>
>> I just tried it out with the Firefox address bar, it directly sets the text
>> cursor. It is not even capable of keeping the selection if not focused. :-D
>
> On the Mac, the first click in the address bar activates the window. The second sets the cursor.

The Mac being a platform that has strong consistent UI guidelines. Marcel, using Firefox (on Windows?) as an authority isn't that convincing.

>
> - Bert -
>
>
>

marcel.taeumel

Re: text selection broken

Hi Eliot,

an example is not an authority. :-) It is just some input for the discussion. So, what do the strong consistent UI guidelines on the Mac say about this?

Best,
Marcel