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.