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 <Marcel.Taeumel at hpi.de> 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.
>