GNOME Bugzilla – Bug 504901
GtkCellRendererCombo requires click-and-hold
Last modified: 2013-04-19 22:04:37 UTC
GtkComboBox pops up its menu and leaves it up when the left mouse button is clicked and quickly released. GtkCellRendererCombo doesn't--the menu is up only while the button is held down. The difference in behavior can be traced to gtk_menu_shell_button_release (gtkmenushell.c:660): if ((event->time - menu_shell->activate_time) > MENU_SHELL_TIMEOUT) ... The condition fails for a quick click on a GtkComboBox, because menu_shell->activate_time is valid, but always succeeds for GtkCellRendererCombo, because menu_shell->activate_time is 0. Test case and proposed patch to follow.
Created attachment 101422 [details] test case Test case shows a GtkComboBox and a GtkTreeView with a GtkCellRendererCombo. Compare the results of a quick click on each.
Created attachment 101423 [details] [review] patch against current svn Patch to pass the event button and time to gtk_combo_box_menu_popup.
2007-12-24 Matthias Clasen <mclasen@redhat.com> * gtk/gtkcombobox.c: When popping up a menu from a treeview cell, use the time and button information from the event. (#504901, Peter Bloomfield)
Created attachment 241702 [details] test case
Reopening. A slightly updated test case shows that the issue has resurfaced in Gtk3. The patch is still in place, and would presumably still work, but now gtk_cell_editable_start_editing is called from gtk_cell_area_activate_cell with a NULL GdkEvent, which defeats the purpose of the patch. Not clear why--the GdkEvent is a parameter to gtk_cell_area_activate_cell, so it's available to be passed to gtk_cell_editable_start_editing. Test case and proposed patch attached.
Created attachment 241703 [details] [review] Proposed patch
Tristan ?
I've noticed this problem too (Glade uses these combo cells too), thanks for doing the grunt work and finding the problem Peter :) As for your patch, I think that it's fine to commit that, the event is passed to activatable cells but not editable cells, I can't see any reason why not to pass them. However there is another issue which would also be nice to fix. Your patch will work for activating the combo cell with a mouse click, but it will still be broken for keyboard activation (when the combo cell is in focus). Unfortunately, I missed adding a GdkEvent argument to the gtk_cell_area_activate() API which kind of blocks this working from keynav (since the focus/activate mechanism goes through the gtk_cell_area_activate() API which lacks the 'event' argument, it can't be propagated... and it would probably be wrong to peek at the current event for this). I guess the ultimate solution would be to: o Add gtk_cell_area_activate_with_event() o Deprecate gtk_cell_area_activate() o Update GtkTreeView code to make an attempt at passing the right event to gtk_cell_area_activate_with_event() This last part is tricky though, since gtk_tree_view_set_cursor_on_cell() allows one to programatically start editing a cell, in which case it might be wrong to grab the current event and push it along.
(In reply to comment #8) > I've noticed this problem too (Glade uses these combo cells too), > thanks for doing the grunt work and finding the problem Peter :) You're welcome! > Your patch will work for activating the combo cell with a mouse click, > but it will still be broken for keyboard activation (when the combo > cell is in focus). That's odd: in my app, keynav works fine. In fact, that was why I was pretty sure the broken click handling was a real bug. Keynav works in the test case in comment #4, too, at least on this F18 laptop.