Recent

Author Topic: User-experience with mouse selections  (Read 1988 times)

Marchello

  • Newbie
  • Posts: 3
User-experience with mouse selections
« on: August 02, 2021, 07:33:06 pm »
Linux Mint 20.2 XFCE, Lazarus v2.0.12

Selecting text seems to be a bit wonky (compared to MS-Windows) and I'm uncertain if wonkyness is normal behavior, a system-wide XFCE behavior, or a Linux thing.
As I expect a high probability of a "Linux"-wide issue, maybe it can be overcome by Pascal-programming.

The main issue is that it's very hard and sometimes impossible to select a text in an edit box by mouse...  here some scenario's.


* Situation-1
[tEdit runtime]
A tEdit on a form contains some text. I click half-way the edit-box and yank my optical mouse a centimetre to the left then let go of the mouse-button.
(This is basically how I mouse-select. So I can ensure quickly that my selection includes the first character plus that the mouse-cursor is not obstructing my view plus that I can  'calibrate' my expected mouse position at the screen-edge at the same time when I mouse a bit further)
* Expected:
A text selection from half-way to the start.
* Result: failed
A selection is formed from half-way till when the mouse escaped the edit-box.

* Situation-2
[tEdit runtime]
A tEdit on a form contains some text that overflows to the right. I click half-way the edit-box and now, learned from situation-1, I carefully move my mouse-cursor to the right side edge of the edit-box and then let go of the mouse-button.
* Expected:
Content scrolls. A selection from half-way till the end of text
* Result: ok
The content scrolled to the end and we have a selection from half-way till the end of text

* Situation-3
[tEdit runtime]
A tEdit on a form contains some text that overflows to the right. The text is now scrolled towards the end. I click half-way the edit-box and carefully move my mouse to the left-side edge of the edit-box and then let go of the mouse.
* Expected
Content scrolls. A selection from a couple of character from the end till the beginning of the text
* Result: fail
There is no scrolling as the text remains stationary. The selection is up until the second visible character. The first visible character remains unselected, just as the text that precedes.

* Situation-4
[Lazarus IDE]
The Lazarus IDE-Object Inspector basically shows the same behavior.
Except that the initial click most of the time selects all the text.
When a long text is selected then the text is automatically scrolled to the right. Click twice and the selection is gone. But now, as situation 3, I can't make a partial selection to the beginning.
Thus, for example, I can't the text of a large control-name and leave out an index number that way.

* Situation-5
[Lazarus IDE]
Not a textbox-situation, but side eyeing at the memo-control. Because the tMemo-control, like the tEdit, is also unaware of its surroundings.
The Source Editor has the preferred behavior: The initial click sets the start of the selection and then the mouse can be moved all over the screen, and out of Window range, while the selection follows and expands or contracts.
I looked at the tSynEdit-control. And that behaves the similarly.
Thus selecting while moving out of (control)-sight is definitely possible.

* Situation-6
[Linux, Thunar File manager]
With the View/Location-selector in "Pathbar style" the behavior is interesting.
It too is apparently not fully aware of the mouse position in selection-mode or it's constraining the input.
It completes the halfway selection towards the beginning of the textbox when the mouse is above or and the left of the textbox and selects to the end when the mouse is below or above the textbox. I can make it jump back and forth. Even when out of range of the window; I can circle around that window.
It's not fine-tuned useful, but most of the time seems practically useful. Just following a different UX-paradigm.
Let's consider it a benefit that we don't have to wait for the scrolling-effect.

* Situation-7
[Linux, Firefox browser]
The address-bar of Firefox , and other controls which include the textbox inside a web-page, looks like it's aware of the mouse-position when I'm outside the window while selecting takes place.

Circling this behavior back to situations 1..4:
The not fine-tuned selection-jump to the end apparently does happen in the tEdit, but only when passing the edge of the control.
The selection to the beginning does not happen.

* Situation-8
[tEdit runtime]
I tried to do a SetCapture(Edit.Handle) and a ReleaseCapture. But that does not seem to do anything.
Expected: When I control such "SetCapture" and "ReleaseCapture" via a checkbox then the tEdit should receive some OnMouseMove events while hovering around.
But nothing is received. A bug?

-
Is this a know (Linux-)issue with known solutions?
How broad is this issue, and what can I do about it besides changing my expectations?
A possible solution is to try (can I?) to totally overwrite the selection behavior by tracking where the mouse is myself and apply some selection magic.
Is this what's done in Lazarus Source-editor and the Firefox-browser?
In the hope to make life easier, although likely overkill, is there a single line tEdit-variant of the tSynEdit-(memo) control?

Regards, Marchello

Gald

  • Jr. Member
  • **
  • Posts: 63
Re: User-experience with mouse selections
« Reply #1 on: October 12, 2021, 06:52:11 pm »
"Is this a know (Linux-)issue with known solutions?"

Yes, Linux is a unfinished product. There are a thousand of small things that make the system weird.
New users know that there some problems, but they can't point to them because these problems are small and simple, like breath or blink.

I already did some suggestions to solve this issue, by select all text when it getting focus, but with no results yet.
Please, take a look:

https://forum.lazarus.freepascal.org/index.php/topic,54995.msg408813.html#msg408813

https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39015

Probably even the devs (I'm talking about Linux distro) can't understand the problem, like a person who doesn't figure out that he is breathing.
We need to make it simple so they can understand the problem. This is harder to do then you can imagine!

 

TinyPortal © 2005-2018