Re: Review appreciated: touch-text-selection branch

[Carlos Garnacho <carlosg gnome org>]

Hey Matthias,

On vie, 2012-08-24 at 18:30 -0400, Matthias Clasen wrote:
> Thanks for the debug envvar. Overall, feels more robust now. Still a
> few things that are odd:
> 
> - I guess the fact that double and triple clicking gives me a nonempty
> selection with just a single handle is not really an issue, since you
> don't double click on a touchscreen.

That's true with GDK_TOUCH_MASK set, widgets that don't set it will
still get pointer emulated events from touch devices. This is the case
for both GtkEntry and GtkTextView, so it is still better to handle this
case.

I've changed in the branch the GtkTextHandlePosition enum to
SELECTION_START/SELECTION_END, and updated both widgets to match
themselves those with cursor/selection bounds, it also enabled fixing
this oddity.

> 
> - I can't select 'backwards' ie click and then drag against the text
> direction. Maybe not a huge deal, but it is noticable to me.

This has changed too, now the initial selection (press+drag on text)
will allow for backwards selection, only dragging from the handles will
disallow both to cross over each other.

> 
> - In the hypertext example of gtk3-demo, when clicking on a link, I
> end up with a leftover handle at the wrong position.

Fixed that. 

> 
> - Selecting text in an entry, moving the focus away (to remove the
> handles), and then clicking in the selection to bring the focus back,
> I see the two handles appear at the ends of the selection, and when I
> release the mouse button, the selection gets collapsed to the cursor
> with a single handle. That is a little irritating and flickery

Right... This is a side effect of the show-handles-on-focus-in hack,
since this is only ok when the toplevel is moved/resized and we can't
tell that apart from other focus-out reasons, perhaps we could do better
without this hack? Sounds like a corner case on touch devices anyway.

> 
> - In the 'entry buffer' example, type some text in the first entry,
> then select it (two handles appear). Now click in the second entry
> (the two handles in the first entry disappear, and the cursor in the
> second entry gets a single handle). Now hit tab twice to cycle the
> focus back. The first entry now has two handles again. The fact that
> the handles reappeared on focus in in this case seems arbitrary, they
> don't do otherwise

This is a side effect of the above too.

> 
> - In a scrollable entry, I seem to be able to scroll to the end by
> moving the second handle all the way to the end. But it doesn't seem
> to work in the other direction

Fixed in the branch.

> 
> - In text views, there seem to be situations where it is not possible
> to move the handles closer to each other, although they're still more
> than a row apart (see attached screenshot).

Maybe it's odd, but that looks legit, the minimal selection in that case
is the '\n', so both handles are laying around that char.

> 
> - Scrolling to extend the selection seems to generally work fine in
> text views, but I've managed to get to a situation where the handles
> disappeared after a lot of scrolling, and then they never wanted to
> come back afterwards (they always briefly flashed in when I started a
> new selection, and then disappeared again). Haven't been able to
> reproduce that consistently.

Hmm, nasty, I'll be trying to spot that.

  Carlos