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 {
> GTK_WIDGET_TAP_AND_HOLD_QUERY,
> GTK_WIDGET_TAP_AND_HOLD_TRIGGER,
> GTK_WIDGET_TAP_AND_HOLD_CANCEL
> } 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
applications?
Ross
--
Ross Burton mail: ross burtonini com
jabber: ross burtonini com
www: http://www.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