Pie menu breaks if spawned near window edge #49029

New Issue

Hadrien Brissaud · 2016-08-06T12:34:37+02:00

Hadrien Brissaud commented

2016-08-06 12:34:37 +02:00

Pie menus are sort of "clamped" in that if they are spawned closer to the window edge than their spread radius (UserPreferencesView.pie_menu_radius), instead of spawning partly offscreen, instead they will spawn stuck to the edge and will automatically validate the menu item that's in that direction. To make it clearer, here is a capture.

This is a problem because pies can hardly be spawned in cramped workspaces - for instance inside a graph editor occupying the lower third of a standard 16:9 monitor, unless the radius is set super small.
This happens on Windows.

Pie menus are sort of "clamped" in that if they are spawned closer to the window edge than their spread radius (UserPreferencesView.pie_menu_radius), instead of spawning partly offscreen, instead they will spawn stuck to the edge and will automatically validate the menu item that's in that direction. To make it clearer, here is a capture. ![piemenuclamp.gif](https://archive.blender.org/developer/F333395/piemenuclamp.gif) This is a problem because pies can hardly be spawned in cramped workspaces - for instance inside a graph editor occupying the lower third of a standard 16:9 monitor, unless the radius is set super small. This happens on Windows.

Hadrien Brissaud commented

2016-08-06 12:34:37 +02:00

Changed status to: 'Open'

Hadrien Brissaud commented

2016-08-06 12:34:37 +02:00

Added subscriber: @hadrien

Sergey Sharybin commented

2016-08-09 12:09:35 +02:00

Added subscribers: @JulianEisel, @Sergey

Julian Eisel was assigned by Sergey Sharybin

2016-08-09 12:09:35 +02:00

Sergey Sharybin commented

2016-08-09 12:09:35 +02:00

@JulianEisel, is it something for you?

Hadrien Brissaud commented

2017-03-05 17:54:20 +01:00

@JulianEisel Just a heads up, no pressure, wanting to know if this could possibly be looked into before 2.8 ? I know you guys are pretty busy.

Hadrien

@JulianEisel Just a heads up, no pressure, wanting to know if this could possibly be looked into before 2.8 ? I know you guys are pretty busy. Hadrien

Julian Eisel commented

2017-03-05 20:00:41 +01:00

I've got this on my radar though I admit it's not the highest priority for me. Can't really tell you when I'm going to investigate it but it should definitely happen before the 2.8 release ;)

Hadrien Brissaud commented

2017-03-05 22:19:56 +01:00

Thanks a bunch Severin.

Hadrien Brissaud commented

2018-06-20 12:53:54 +02:00

I hate to nag you guys about this, but seeing as there's work on including pie menus in default 2.8 config -which imho is a good move- it seems the right moment to do so. If there was any chance this could be looked at it would be neat. Let me know if it needs clarification.

Don Hopkins commented

2019-03-12 03:41:09 +01:00

Added subscriber: @SimHacker

Don Hopkins commented

2019-03-12 03:41:09 +01:00

Hi! I'd love to contribute to the Blender pie menus and user interface in general, and this issue seems like a good way to start learning my way around.

I've implemented pie menus on other platforms, and here's a patch for one approach to solving this problem using mouse warping that I've tried and like.

But it needs to be tested on other platforms, which I don't have set up myself. And I hope it does not astonish users too much. Plus there should be a user option to enable and disable it, of course.

One possible way to handle the window edge problem is to "warp" the cursor by the same offset as you had to move the menu to keep it on the screen.

That is instead of using the UI_PIE_INITIAL_DIRECTION delay technique.

This is just a quick ugly hack and I'm not familiar with the code, so I don't know how the popup animation may interact with it, or if I'm causing any memory leaks or heisenbugs.

For some reason, to keep from crashing, I had to create an empty eventstate because it was NULL, and wm_window_ensure_eventstate was private to wm_window.c, so I just inlined the code to allocate it.

I'd appreciate other developers and users trying it and letting me know if it works and feels ok, please.

It seems to work on a Mac, but I don't know how well this technique will work on other platforms (especially X-Windows with its slimy asynchronous nature).

Reading then warping the cursor properly on different platforms can be tricky and involve hard-to-test race conditions (especially if you're handling a bunch of queued events at once). And it's important that it work reliably with mouse-ahead gestures when the system's sluggish (like when my laptop inhales cat fur and overheats then intel speed step knocks it down to TRS-80 speed).

Other pie menu implementations (for slower old computers) use a more elaborate technique of delaying the menu window pop-up until the cursor stops moving (mouse-ahead display pre-emption), and only then do they warp the mouse (so you never have to warp the mouse if the user gestures smoothly and quickly enough without hesitating that it doesn't need to display the menu).

In the edge case of delayed popup with screen edge warping (when the user gestures near the screen edge in some direction, but hesitates before confirming), you need to be sure to warp the cursor relative to its current position (not the initial down click position, so you don't lose any motion from a quick gesture).

Delaying popping up the menu is a big deal for making pie menu mouse-ahead gestures reliable and trustworthy on sluggish and networked computers (not wasting time drawing the menu after the selection's already been made), but things are fast enough now (barring cat fur incidents) that it may not be necessary to inhibit popping up the menu, and you can get away with instantly warping the cursor on the initial mouse-down event, then merrily playing animations.

Here's a demo of an X10 pie menu window manager (X10 is what came before X11, of course ;) that shows screen edge handling (starting at 3:50):

https://youtu.be/IJhvB6kwmog?t=3m50s

Here's a demo of ActiveX pie menus, that shows mouse ahead display pre-emption (and some weird experiments in alternative shapes and layout techniques):

https://www.youtube.com/watch?v=nnC8x9x3Xag

File: interface_region_popup.c

Line 65:

include "wm_event_system.h"

Line 570:

if 0

		if (U.pie_initial_timeout > 0)
			block->pie_data.flags |= UI_PIE_INITIAL_DIRECTION;

else

		int cx, cy;
		if (window->eventstate == NULL) {
			window->eventstate = MEM_callocN(sizeof(wmEvent), "window event state");
		}
		wm_get_cursor_position(window, &cx, &cy);
		WM_cursor_warp(window, cx + x_offset, cy + y_offset);

endif

Hi! I'd love to contribute to the Blender pie menus and user interface in general, and this issue seems like a good way to start learning my way around. I've implemented pie menus on other platforms, and here's a patch for one approach to solving this problem using mouse warping that I've tried and like. But it needs to be tested on other platforms, which I don't have set up myself. And I hope it does not astonish users too much. Plus there should be a user option to enable and disable it, of course. One possible way to handle the window edge problem is to "warp" the cursor by the same offset as you had to move the menu to keep it on the screen. That is instead of using the UI_PIE_INITIAL_DIRECTION delay technique. This is just a quick ugly hack and I'm not familiar with the code, so I don't know how the popup animation may interact with it, or if I'm causing any memory leaks or heisenbugs. For some reason, to keep from crashing, I had to create an empty eventstate because it was NULL, and wm_window_ensure_eventstate was private to wm_window.c, so I just inlined the code to allocate it. I'd appreciate other developers and users trying it and letting me know if it works and feels ok, please. It seems to work on a Mac, but I don't know how well this technique will work on other platforms (especially X-Windows with its slimy asynchronous nature). Reading then warping the cursor properly on different platforms can be tricky and involve hard-to-test race conditions (especially if you're handling a bunch of queued events at once). And it's important that it work reliably with mouse-ahead gestures when the system's sluggish (like when my laptop inhales cat fur and overheats then intel speed step knocks it down to TRS-80 speed). Other pie menu implementations (for slower old computers) use a more elaborate technique of delaying the menu window pop-up until the cursor stops moving (mouse-ahead display pre-emption), and only then do they warp the mouse (so you never have to warp the mouse if the user gestures smoothly and quickly enough without hesitating that it doesn't need to display the menu). In the edge case of delayed popup with screen edge warping (when the user gestures near the screen edge in some direction, but hesitates before confirming), you need to be sure to warp the cursor relative to its current position (not the initial down click position, so you don't lose any motion from a quick gesture). Delaying popping up the menu is a big deal for making pie menu mouse-ahead gestures reliable and trustworthy on sluggish and networked computers (not wasting time drawing the menu after the selection's already been made), but things are fast enough now (barring cat fur incidents) that it may not be necessary to inhibit popping up the menu, and you can get away with instantly warping the cursor on the initial mouse-down event, then merrily playing animations. Here's a demo of an X10 pie menu window manager (X10 is what came before X11, of course ;) that shows screen edge handling (starting at 3:50): https://youtu.be/IJhvB6kwmog?t=3m50s Here's a demo of ActiveX pie menus, that shows mouse ahead display pre-emption (and some weird experiments in alternative shapes and layout techniques): https://www.youtube.com/watch?v=nnC8x9x3Xag File: interface_region_popup.c Line 65: # include "wm_event_system.h" Line 570: # if 0 if (U.pie_initial_timeout > 0) block->pie_data.flags |= UI_PIE_INITIAL_DIRECTION; # else int cx, cy; if (window->eventstate == NULL) { window->eventstate = MEM_callocN(sizeof(wmEvent), "window event state"); } wm_get_cursor_position(window, &cx, &cy); WM_cursor_warp(window, cx + x_offset, cy + y_offset); - endif

Stefan Werner commented

2019-03-13 22:29:56 +01:00

Added subscriber: @Stefan_Werner

Hadrien Brissaud commented

2020-10-10 20:58:22 +02:00

@SimHacker hadn't seen your answer. Thanks for your interest! I don't think mouse warping can work with devices that communicate an absolute pointer position (tablets)? My idea was more in line with spawning the menu partly offscreen, just as if the interface actually extended beyond the screen's edge. This works on paper because the minimum necessary interaction area for pie menus (or even regular ones) is much smaller than their entire displayed size, and one way to interact with them is to simply flick the pointer in any direction, with no need to actually reach the desired button with the pointer. However, I think pointer warping can be desirable for when the user uses a mouse and when the invoked menus are small enough that they don't cover the entire editor.

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Pie menu breaks if spawned near window edge #49029

include "wm_event_system.h"

if 0

else