[Webkit-unassigned] [Bug 172905] [GTK] Add API to allow overriding popup menus

[bugzilla-daemon at webkit.org]

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

--- Comment #5 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to Michael Catanzaro from comment #4)
> I've been meaning to review your combo box patch for a while but haven't
> gotten to it yet... can you briefly describe the advantages to using your
> custom treeview implementation over what we have now? They look similar to
> me.

You are mixing bugs here. This is the WebKit bug to provide API to override popup menus. We needs this to allow users to override the default GTK+ menu, but not because our current implementation is not good enough. Popup menus is the only thing where we expose GTK+ unconditionally, so it has always been in my TODO, to provide API to be able to override it.

To make sure the API is good to implement your own menu, I implemented a new custom menu in epiphany using the new API, not because it has any advantages, but just to try the API. However, it indeed has advantages:

 - It scales much better, because it has a maximum size and context are scrollable, instead of the current menu that takes the whole work area and has scroll button on top/bottom.

 - It uses a tree view which allows us to better format group labels, making them bold instead of current menu that just makes them insensitive, like any other disabled item.

 - It behaves like other browsers (chromium/firefox). When you hover the items, they are selected in the tree view, but the combo text doesn't change. In case of typeahead find, the matched element is selected in the tree view and the combo box text is also updated.

All this is specially noticeable with long menus, that's why I included a screenshot of the redhat bugzilla products menu, just open that menu in you current ephy to see the differences.

As I said in ephy bug, there's actually no reason why that implementation couldn't be the default, but I think we can test it for a while this cycle in ephy, and move it to WebKit during the next cycle if we all are happy with it.

I'm sorry this was not briefly in the end.

-- 
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/20170612/376d21a2/attachment.html>