GNOME Bugzilla – Bug 433242
Inconsistent scroll arrow position calculations
Last modified: 2007-04-27 05:56:50 UTC
gtk_menu_paint() and gtk_menu_handle_scrolling() are calculating the scroll arrow positions differently, causing strangely feeling interactions with large horizontal/vertical-padding values. Visually the arrow is a distinct rectangular area in the menu, but pointer events outside the arrow area are still considered for prelighting and scrolling. Expected behavior (!touchscreen) 1. pointer moves to the border around the arrow area -> nothing happens 2. pointer moves to the arrow area -> arrow is prelit, scrolling starts 3. pointer moves outside the arrow area -> scrolling stops, arrow is back to normal Actual result: 1. arrow is prelit, scrolling starts 3a. if pointer moves to the border area, nothing happens 3b. if the pointer moves to the menu items, or outside the menu, scrolling stops, arrow goes back to normal Expected behavior (touchscreen) 1. button is pressed inside the arrow area -> arrow is prelit, scrolling starts 2. pointer is moved outside the arrow area -> prelighting is removed 3. button is released -> scrolling stops Actual result: 2a. if pointer moves to the border area, nothing happens 2b. if pointer moves to the menu items, or outside the menu, scrolling stops, arrow goes back to normal 3. if button is released on the border area, nothing happens
Created attachment 86978 [details] testcase
Created attachment 86979 [details] [review] [PATCH] Calculate the scroll arrow position consistently When checking whether the pointer is inside the scroll arrow, calculate the arrow position the same way as when painting it. Previously the border area around the scroll arrows would be sensitive to pointer events, but the arrow graphics (including the background) would not be drawn in that area. * gtk/gtkmenu.c (gtk_menu_handle_scrolling): Calculate the scroll arrow position the same way as in gtk_menu_paint --- gtk/gtkmenu.c | 24 ++++++++++++++---------- 1 files changed, 14 insertions(+), 10 deletions(-)
Created attachment 86980 [details] [review] [PATCH] Stop scrolling when pointer is (released) outside the scroll arrow Previously it was possible to drag the pointer outside the scroll arrow area without scrolling being stopped. It only worked correctly with leave-notify events. * gtk/gtkmenu.c (gtk_menu_button_scroll): Call gtk_menu_handle_scrolling on every button-release event. (gtk_menu_handle_scrolling): In !touchscreen mode stop scrolling when pointer is moved outside the scroll arrow area. --- gtk/gtkmenu.c | 7 ++++--- 1 files changed, 4 insertions(+), 3 deletions(-)
Created attachment 86981 [details] [review] [PATCH] Redraw the arrow when dragging pointer outside the scroll arrow In touchscreen mode it was possible to drag the pointer outside the scroll arrow which would not remove the prelighting from the arrow. It only worked correctly with leave-notify events and when releasing the button. * gtk/gtkmenu.c (gtk_menu_handle_scrolling): Redraw the arrow when dragging pointer outside the scroll arrow. --- gtk/gtkmenu.c | 16 ++++++++++++---- 1 files changed, 12 insertions(+), 4 deletions(-)
This fixes the issue from the 3rd patch, only a bit differently: 2007-04-25 Michael Natterer <mitch@imendio.com> * gtk/gtkmenu.c (gtk_menu_handle_scrolling): fix ACTIVE state of scroll buttons (we were setting the state to ACTIVE but immediately overwriting it with NORMAL or PRELIGHT). Also got rid of many separate calls to gdk_window_invalidate_rect() by remembering the old button state and only invalidating the area if the state has changed (addresses parts of bug #433242, Tommi Komulainen). (gtk_menu_scroll_to): change the arrow states only if changing from or to INSENSITIVE state, so we don't overwrite the ACTIVE state set by above function.
Should this be closed then ?
Yes, this is basically INVALID as apparently it is intentional that the sensitive area includes the menu borders which makes the menu arrows infinitely more useful when they are against the screen edges.