@Julian Eisel (Severin) 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

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 ;)

Thanks a bunch Severin.

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.

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

@Don Hopkins (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.