Re: Touch selections

Hi Carlos,

Just wanted to provide some design feedback after some testing of your patch inside of the GTK3 based Sugar – on an XO-4 Touch. Items are mainly related to the context menu behaviour:

On 11 Jan 2013, at 17:24, Carlos Garnacho <carlosg gnome org> wrote:

> Hello GTK+ list,
> I went ahead at implementing the missing functionality from:

Great thanks!

> On the GTK+ touch-selections branch [1] there is now:
>      * Improved text handle dragging behavior, including a bigger input
>        area, covering the line height, plus other smaller fixes.

Don't think I'm seeing this improvement, in Sugar at least, but you mentioned on IRC you were investigating this issue already.

>      * A popup widget for bubble-like context menus, with separated
>        show/grab semantics

Palette horizontally offset in some cases
- The selection context palette appears offset horizontally from the text selection in some cases (e.g. Sugar's Pippy activity python source code editor). The incorrect offset is usually towards the left, near or on the text selection start point. [1]

Palette horizontal positioning over multi-line text selections
- If the text selection partially wraps from the end of one line to the start of another, the context palette is still centred between the two handles, guaranteeing to put it over unselected text which looks odd, especially when the handles are manipulated [2]. Recommendation: I would suggest for the multi-line selection case that the context palette is always horizontally centred over the full width of the text view [3].

Screen top edge collision
- The palette, by default, is now positioned above the selection (great), but when the palette hits the top of the screen edge and is flipped to flow downward, it is attached to the top edge of the text selection, hiding the selected text [4]. Recommendation: It should attach to the bottom edge of the selection, if a multiline selection then it should be horizontally centred and at the bottom edge of the last selected row. [5]
- If the selection fills the visible view area (i.e. both start and end are off screen), the palette is currently drawn off screen at the top of the text selection.  Recommendation: The palette could be placed in the centre of the text view (this also applies when both start and end of selection are near enough the screen edges that there is no space there for the context palette). [6]

Auto timer popup delay
- The auto delay popup behaviour frequently leaves the selection start/end handles obscured preventing modification of the selection, the user has no control over when to expose the pop-up. Recommendation: Replace the auto delay pop-up with a single tap of a text selection to raise the context palette for cut/copy/paste.
- The popup always triggers after very short delay, distracting to the user when wanting to type, can obscure surrounding canvas content, and can prevent user dragging the insertion point to place cursor accurately. Recommendation: Replace the auto delay pop-up with a single tap of the insertion cursor to raise the context palette for pasting.

Canvas scrolling
- The context selection palette needs to auto hide when view is scrolled, and re-appear in new correct location when scrolling stops.

Sugar/theming specific items
- Bubble palette pointer triangle custom shape needs to match main palette background theme colour
- Needs to allow theming options to allow a grey 2px outline for palette contrast against different backgrounds, and match other Sugar palette theming [6]
- Sugar needs proper svg Cut icon (various proposals on ticket SL#4387) [8]
- Sugar needs an additional button item added to the context selection palette for the "Speak" feature (cut/copy/paste/speak)



>      * An specific subclass for selection edition popups
>      * Support in entry/textview
> You don't need a touch device to see this working, the
> GTK_TEST_TOUCHSCREEN envvar can be used to get this working on all input
> devices
> Some thoughts/notes:
>      * Those 2 widgets have been made public, I can see other uses for
>        bubbles, and apps like nautilus/file-roller could want the
>        selection window too
>      * The text handles helper object is still private though, there
>        are little potential users, although funnily there's already a
>        patch around with a copy of this code for Abiword.
>      * Theming of the bubble shape is still quite poor, given the
>        bubble tail can be irregular on edge cases, I can hardly think
>        how to use CSS here, besides just taking the border color and
>        stroking by hand and giving up on the rest.
>      * As used by GtkEntry/TextView, there's no keyboard navigation nor
>        interaction at all with the selection bubble, although being
>        mostly designed as a touch interaction helper, it doesn't make
>        much sense either. There are separate grab/ungrab methods for
>        other usecases.
>      * For interaction behavior I've mostly followed the whiteboard
>        recipe, could be nice to get designers early in the loop now
>        that there's and implementation they can play on.
> Testing/Comments welcome,
>  Carlos
> [1]

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]