Re: popup menu keybinding

[Owen Taylor <otaylor redhat com>]

I'm currently applying this patch. Here's my responses to Tim's concerns
(which mostly just parallel Havoc's earlier responses.)

Tim Janik <timj gtk org> writes:

> i just now see that you added *popup_menu fields to textview and gtkentry.
> user-provided popupmenus on entries may not be so common but for textviews
> surely are, but users can't provide or extend those builtin popup menus.
> and what should apps do that mean to have icons for menu items in every menu?

The patch provides a POPULATE_POPUP signal that is emitted on 
the entry/textview, passing in the menu.
 
> creating a new menu for every entry that button3 is clicked in is an
> extreme memory waste btw, users that actually do use those popupmenus,
> and do so in a bunch of entries supplied by an application will create
> a big stack of unused widgets. at most you should have one such menu per
> widget class (e.g. GtkEntry and GtkTextView).

I don't think this is a good idea. It doesn't fit in with customization,
for one thing.

The patch (as applied) creates the menus on demand and destroys
them afterwards, so there is no permanent overhead. This is 
easy, memory efficient, and fast enough.
 
> the popupmenu behaviour of not letting one select the first item
> with drag selections is also quite irritating.

Don't understand this one, doesn't sound related to this patch.
Perhaps is a bug in the ignore-enter code. (There are still some
outstanding fixes to be ported up from the 1.2.x branch.)
 
> you need to disable accelerator settings for those menus, currently the
> users can set accelerators on them that aren't negotiated or saved which is
> highly confusing.

The accelerator setting should have to be explicitely enabled, since
it makes no sense to have accelerators changeable if you don't
have infrastructure for saving them. (In bugzilla as #52434)

(option menus, context menus, etc, almost all have this bug currently.)
 
> to finally come to your <Shft>+F10 key binding, beast for instance is an
> application that makes use of F* and <Shft>+F*, with most window managers
> taking <Ctrl>+F* and <Alt>+F* away, there's not much left for an application
> if gtk now starts to clutter <Shft>+F* as well.
> why i could have understood (not apprechiated though) an F10 binding that
> activates the menu bar in a window which is quite common in *some* GUIs,
> <Shft>+F10 certainly isn't.

As Havoc pointed out, it's pretty much the standard binding on
all GUIs for popping up the context menu - an extension of Shift-F10
to go to the menu bar.

And it is customizable through your RC file.

> also i think it's a pretty bad idea to introduce any keybinding on GtkWidget
> class, since this will affect *all* widgets out there, including third party
> ones.
> dictating <Shft>+F10 for them for menu popups and further dictating the
> signature those widgets may use to popup menus is too much policy for
> gtk+ and is prone to lead to extreme confusion.

I think Havoc responded to this well. Basically, having a single 
consistent keybinding is right. If widgets need to override for
some reason, it's easy enough.

Regards,
                                        Owen