Re: Review appreciated: touch-text-selection branch

[Carlos Garnacho <carlosg gnome org>]

Hey Matthias,

On jue, 2012-08-23 at 19:07 -0400, Matthias Clasen wrote:
> On Wed, Aug 22, 2012 at 12:27 PM, Carlos Garnacho <carlosg gnome org> wrote:
> > Hey all,
> >
> > A few days after guadec I last updated the touch-text-selection branch:
> >
> >   http://git.gnome.org/browse/gtk+/log/?h=touch-text-selection
> >
> > The branch implements draggable handles to ease text selection on touch
> > devices. It'd be great to get this rolling soon so it's included for
> > 3.6. (I know it's past-freeze, but this is a non intrusive change, and
> > an usability leap with touchscreens)
> 
> Hey, thanks for sending this out. I'm just now playing with it.
> Unfortunately, I'm seeing more problems with this branch than with the
> one I played with before guadec...

Doh! there were indeed a few unhandled corner cases introduced by the
selection clamping...

> 
> I've taken out all the touchscreen checks to try this with my mouse.
> 
> When clicking into an entry to focus it, I get a cursor with a single
> handle underneath it.
> When dragging that, the handle jumps away from the pointer and
> alternates between the left and right end of the entry.

Fixed, selection clamping was kicking in on cursor mode too

> When double-clicking to select the contents of the entry, I end up
> with a selection that has only one handle, and dragging it is broken
> in the same way.

Dragging brokenness itself should be gone, I tried to fix the former too
but stumbled on some strange behavior in GtkTextView, on per-char
selection it drags the cursor mark and keeps the selection bound fixed,
whereas on word/line selection it does the opposite. This effectively
flips handles' position, I'm looking into using a min/max approach for
handles' positioning, although that leads so some repetitive iter
comparisons I preferred to avoid.

> When clicking and dragging to get an extended selection, I get two
> handles that are working as expected.
> When clicking and dragging in the empty part of the entry, I sometimes
> get handles that extend all the way from the end of the entry to where
> I let go, with no visible selection at all.

Fixed, it was a corner case in keeping a minimal selection when the
selection started at the end.

> When moving the window with touch handles by dragging the titlebar,
> the handles disappear and don't come back, leaving a 'naked' selection
> behind.

That's tricky to fix... text widgets set mode=none on the text handles
on focus out, usually legit but window moving/resizing triggers that
too. Best thing I can think of is checking on focus in whether the last
pointer events source device triggered the handles to appear, will play
with that.

> Same when starting a drag of a selection with handles - the handles go
> away, and after I cancel the drag, the selection is 'naked'

This one is fixed.

> I'm also seeing lots of warnings:
> 
> (lt-gtk3-demo:24582): Pango-CRITICAL **: pango_layout_get_cursor_pos:
> assertion `index >= 0 && index <= layout->length' failed

Fixed too, related to the corner case mentioned above.

> 
> Now, I may have made some mistake when patching out the touchscreen
> checks - maybe it would be good to have an env var or setting to force
> the handles ?

There's a patch now in the branch adding checks for a
GTK_TEST_TOUCHSCREEN_FEATURES envvar, so the behavior can be replicated
with any other device.

  Carlos