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 <[email protected]> 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 _______________________________________________ gtk-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gtk-devel-list
