next steps for touch support in GTK+
Hi, there have been several discussions around GTK+ touch support during GUADEC. To get a good touch experience we talked about the following points. I ordered them by priority that we set in Sugar development for them. If you come across something that we missed, please comment. === 1. Text selection === A lot of work has been going into text selection and manipulation those days from the design and implementation point of view. The current design ideas can be seen at [1]. Carlos created universally usable handles (implemented using GtkWindows) to adjust the selection and wrote the code to use them in GtkEntry and the GtkTreeView in this branch [2]. The idea is to make those available as well for external widgets, e.g. in Abiword or WebKitGTK. We discussed as well how the Edit Palette should look like and agreed loosely on using GtkWindows instead of an Overlay for this to handle cases like resizing windows for example. Something to check is if we want to allow to adjust the selection in moving the right handle over the left one. Both iOS and Android do block that and snap to the minimum selection when releasing the finger which seems a good interaction model and limits complexity and edge cases. Another thing to make sure is that we do not use fixed positions in regards to Wayland. === 2. OSK - Slide canvas vertically to keep insertion point visible === Carlos has been working on this already. He will send a mail with more info about it. To get more background about the issue itself a whitepaper is available at [3]. === 3. SpinButton === We had several discussions around the SpinButton. One thing that came up is why we do not want to reuse the existing one. One option is to put the '' on the left side (this could be done by a property for example). When the SpinButton was redesigned they put the and close together to not interfere with other widgets at the left side. Having something like [button] | 3| might not be as clear. That at last was the reasoning for putting the stepper buttons next to each other. In touch the interaction gets a bit fiddly having the buttons next to each other that is why we propose that configuration option. We would keep the entry widget, on touch you can use the OSK to set a value, or you can set it to be non-editable. Furthermore you can accept a vertical swipe to alter the value, implementing this would be a perfect use case for EventControllers. Another option is introducing a complete new widget targeted at touch usage (similar to the one in iOS Garageband) [4] which Carlos implemented already [5]. The issue is here the height, which at least in a Sugar toolbar could be not as ideal and introducing a new widget. === 4. Which GTK+ widgets break with touch === The SpinButton item from above is one example of those. Another one was the Combobox which has been fixed by Carlos and landed in master [6]. I will have a look if I come across more. Feel free to add if you are aware of more blockers. === 5. Widget Gestures (e.g. swipe, pinch) === The desired implementation is to use EventControllers for that. The work has currently stagnated on that end. In Sugar we could implement this at our toolkit level but an upstream solution would be desired at least longer term. === 6. OSK widget context provider (e.g. search vs open vs go...) === Matthias said there was a patch floating around for that. I looked in the bugs with patches attached in bugzilla but could not find it. If someone knows where it is would be great. Regards, Simon [1] https://live.gnome.org/GnomeOS/Design/Whiteboards/Selections [2] http://git.gnome.org/browse/gtk+/log/?h=touch-text-selection [3] https://wiki.maliit.org/images/a/a7/Technical-overview-widget-relocation.pdf (from https://wiki.maliit.org/Documentation#Technical_documentation) [4] http://wiki.sugarlabs.org/go/File:Ios_spinbutton.JPG [5] https://bugzilla.gnome.org/show_bug.cgi?id=678108 [6] https://bugzilla.gnome.org/show_bug.cgi?id=678113 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: touch events
On 02/03/2012 01:44 AM, Alberto Ruiz wrote: 2012/2/2 Benjamin Otteo...@gnome.org So from reading Matthias' mails it seems to me that this is the first step, so we should get this right first. We should have a good idea of where we want to go, but we don't need to merge the full multitouch branch to get touch events. So let's start small. Note that I do not have any touch-capable devices, so I have no way to test the things I'm suggesting here. All I can and will do for now is API review. Just FYI, if anyone wants to get a device to test this, the Apple magic trackpad works on Linux and it is really neat for testing. Chase Douglas and the other touch engineers in the System teams use it for the gesture support development in Ubuntu. It is a good workaround if you don't want to buy a whole multitouch capable tablet(pc). The Apple magic trackpad sounds interesting, indeed. I am using here the Wetab [1] with Fedora rawhide and the gtk-multitouch branch to explore the touchscreen possibilities until Fedora-ARM gets ready for rawhide so I can run on the XO-1.75/touch [2]. Was wondering the other day what devices others were using. Regards, Simon [1] http://wetab.mobi/en/ [2] http://wiki.laptop.org/go/XO-1.75 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Multitouch review 2: press-and-hold
Hi,
first of all, thanks for all the work on this!
I just tested the multitouch branch here on my Wetab in a little python
example to get a feeling what the API would be like. The approach to
connect to a signal and then decide whether to handle it or not was
straight forward to me.
On 02/01/2012 05:23 PM, Carlos Garcia Campos wrote:
Excerpts from Bastien Nocera's message of mié feb 01 12:23:52 +0100 2012:
On Tue, 2012-01-31 at 19:18 -0500, Matthias Clasen wrote:
API:
GtkWidget::press-and-hold
GTK_PRESS_AND_HOLD_{QUERY,TRIGGER,CANCEL}
GTK_STYLE_CLASS_PRESS_AND_HOLD style class
GtkSettings::gtk-press-and-hold-timeout setting
This feature has a long history going back to 2005 and Hildon [1][2].
The way it works is that ::press-and-hold is emitted upon button
press (only button 1), scroll or touch events with an action of
GTK_PRESS_AND_HOLD_QUERY. Widgets have to opt-in to press-and-hold by
handling that and returning TRUE. GTK+ then plays the press-and-hold
animation (which is adapted to whether you are using a tiny cursor or
a fat thumb). If you hold still until the time determined by
gtk-press-and-hold-timeout has passed, ::press-and-hold is emitted
again with the TRIGGER action, and widgets are expected to handle that
by doing whatever action they want to tie to long presses. If the
press-and-hold is canceled because the pointer was moved (beyond the
drag threshold), ::press-and-hold is emitted with the CANCEL action.
If the widget goes away while the press-and-hold animation is running,
it gets removed and cleaned up.
One interesting aspect here is that ::press-and-hold is emitted on the
target widget of the event before the capture phase. There is a
comment in the code that explains that this is 'so a parent capturing
events doesn't delay nor prevent a child from doing the press-and-hold
action'.
Questions, comments:
I still think that the press and hold animation has no place here. Apart
from Windows, I've not seen any touch or stylus devices use this, and I
seriously doubt its usefulness (versus it looking tacky, out of place,
etc.).
IIRC, animation will only work if GtkSettings:gtk-enable-animations is TRUE.
Yes, from my testing here, the animation is not shown when setting the
property to FALSE.
Can we please get the code writers' reasoning behind having this
animation?
I think it gives good feedback that something is going to happen, and
when.
I think it is good feedback, indeed. I wonder if the diameter could even
be a bit larger (or configurable). If you compare mouse or finger
presses, for finger presses the animation is a bit covered under the finger.
What do the designers think? Should it be something the theme
chooses to implement (so that the Windows theme would use the Windows
animation for that for example)?
Yes I think I added a style class for press and hold animation, so
it's themable.
There is a style class:
.press-and-hold {
background-color: alpha (@bg_color, 0.5);
color: alpha (lighter (@selected_bg_color), 0.8);
border-width: 10;
}
If my testing was correct, setting the background color does set the
background color of the widget as well. Is this desired? What does the
'border-width' is meant to do in this particular case? As far as I
understood, the animation sizes are proportional to the input pointer
(e.g. finger or mouse pointer) does this border size has any effect?
Regards,
Simon
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
