[Webkit-unassigned] [Bug 226681] [GTK] Long press context menu only appears after releasing the finger

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Jun 7 05:25:19 PDT 2021


https://bugs.webkit.org/show_bug.cgi?id=226681

--- Comment #5 from Carlos Garnacho <carlosg at gnome.org> ---
(In reply to Alexander Mikhaylenko from comment #4)
> 2-level long press should be fine, indeed.
> 
> And I don't think it's possible to get rid of the menu here completely, it's
> used for many more things than text selection: opening links in new tab,
> saving, copying link address, etc. Similarly, both iOS and Android still
> have menus for these actions even though both provide popovers for text
> selection similarly to the GTK one.

Maybe, and it's probably wise to involve the design team at that point, all I'm clear about is that it shouldn't be a GtkMenu, and that the remaining contextual actions don't seem to justify it popping up everywhere.

> 
> Also GTK still has a long press in color picker dialog, in the file chooser
> sidebar, in the emoji picker etc.

You are pointing out pickers (i.e. self-contained complex UIs) and a widget that was a straight port from an application. Also, these use popovers, that are significantly friendlier to touch interaction (and can/do contain UI optimized for it, as opposed to GtkMenu).

OTOH, none of the widgets that you can embed in your UI does this by default (with the exception of GtkPlacesSidebar). If GTK wanted to show pointer-oriented menus and call it a day, it would have hardcoded a long-press gesture to GtkWidget::popup-menu long ago.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210607/525ad9fd/attachment-0001.htm>


More information about the webkit-unassigned mailing list