Re: #315645; supporting tap-and-hold

On Fri, 2006-09-22 at 12:37 +0200, Kristian Rietveld wrote:
> As Ross says in that bug, there are two ways of implementing this:
>   - load a GTK+ module at run time;
>   - add this functionality to GtkWidget.
> I would propose to add this functionality directly to GtkWidget.  The
> feature would only be turned on if the touchscreen mode has been
> turned on.

Sounds reasonable.  Great to see movement on this!

> Other points:
>   - The original proposal in the bug report suggests to have the tap-n-hold
>     operation generate a right click (button3 press).  I don't think we should
>     hardcode this behaviour, since it will probably break a bunch of apps.
>     IMHO it would be much better to have a tap-and-hold signal for this,
>     also since most apps will want to handle tap-n-hold "clicks"
>     differently anyway.
>     Same story for having tap-n-hold automatically pop up menus.  Maybe
>     we want to execute a different action.

I can't think of any applications on Maemo where tap-and-hold doesn't
open a popup-menu, are there any?  Although restricting tap-and-hold to
only open context menus might not be a good idea, it does lead to a
standard behaviour (like right click->context menu is currently).

>   - It is probably a good idea to give feedback to the user when holding
>     down the stylus at some place.  Maemo currently does this using an
>     animation at the place where the stylus has been put down.  If we
>     decide to provide an animation as feedback to the user we also need
>     a way to query a certain position to see if it will "respond" to the
>     tap-n-hold signal.  This way we avoid the scenario where an animation
>     is shown and after that nothing happens.
>     I am wondering whether we should provide a default animation in
>     the icon theme and different icon themes can provide different
>     animations.  Another option would be to add a function like:
>   void gtk_widget_set_tap_and_hold_animation (GtkWidget *widget,
>                                               GdkPixbufAnimation *ani);

If tap-and-hold is going to emit a generic signal rather than specify a
behaviour, the I think it should default to an animated icon in the icon
theme, and allow certain widgets to override the animation if required.

>   - Of course we should make the hold time configurable.
>   - In the bug report, Mitch pointed out that we can probably implement
>     everything nicely by just adding a single signal to GtkWidget (we
>     only have 3 placeholders left though, and only 2 after the new
>     tooltips code hit CVS ...):
>   typedef enum {
>   } GtkWidgetTapAndHoldAction;
>   gboolean GtkWidget::tap-and-hold (GtkWidget                 *widget,
>                                     GtkWidgetTapAndHoldAction  action,
>                                     gint                       x,
>                                     gint                       y);

What is the cancel action for?

I'm not convinced of the merits of sending a special signal opposed to
popup-menu.  Would GTK+ be edited so that tap-and-hold in a GtkEntry and
so on popped up the context menu, or would that be left to the

Ross Burton                                 mail: ross burtonini com
                                          jabber: ross burtonini com
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF

Attachment: signature.asc
Description: This is a digitally signed message part

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