Updating demo with ImGuiWindowFlags_ResizeFromAnySide (was: Adding mouse cursor support in backends)

[amc522]

Several of the platform examples have been updated with cursor support. Some have not been updated because I do not have the build dependencies or proper computer to test on.

[ocornut]

Hello @amc522,
Thanks for the PR.

I think there are a few issues:

A) I haven't run your Win32 use case but having tried this approach myself, I'm pretty sure it is causing conflicts with Windows owns handling of cursors. Try to hover around the OS window borders and you'll notice that the resize cursors get overridden by ours.

We are normally supposed to answer to the WM_SETCURSOR message however that approach has another problem where it only sends the message when moving or clicking, so on the frame where we "land" on an imgui location that changes the cursor it won't be updated until the mouse moves again.
I was looking into the GLFW approach of mixing both and testing the client rectangle for the first part which I think may be the right (but a little ugly) solution. Sorry I should have mentioned I had done a bit of research on this in #822 thread earlier.

If you have a suggestion on how to tackle this another way I'd be interesting.

B) For the 2 missing diagonal cursors see glfw/glfw#427, if you have some time to help the author of GLFW with adding those (depending on what she decided as the discussion was still dangling) I'd gladly appreciated it.

C) The code is too long. How about using ImGuiMouseCursor_Count_ sized arrays instead? Don't worry about it too much, I can refactor, solving the problem in A) is the most important part here.

[amc522]

A) Definitely see the issue and this is a way trickier problem than I thought it would be. I'll play around with some code and see what conclusions (and maybe solutions) I come to.
B) Can look into the glfw library to help out.
C) Really easy to move this into arrays.

[amc522]

Updated imgui_impl_dx11.cpp with some working code that handles WM_SETCURSOR and plays well with ImGui. It's not pretty, but seems to work well to me. Let me know what you think, and if you can find any cases that don't work.

[ocornut]

Hello @amc522, I am putting on hold because I'll be reworking the main bindings structure to support multiple windows, cross-window drag and drop and other advanced features. (See #1542), and some of that is having an effect on mouse cursors. I'll merge isolated bits or integrate equivalent-feature code over the course of the month probably.

[ocornut]

@amc522 Same feature was implemented today on the 3 DirectX, 3 GLFW based examples and 2 SDL based examples. I took the logic and code from my other branches (less code, a little more tested and following imgui coding style more closely).
GLFW is still lacking the diagonal resize cursors otherwise it works well.

I am keeping this PR open and renaming it because I would like to add the "ResizeFromAllSide" feature in the demo. However considering going via a route that we have flags to specify what the backend can do, and this feature is automatically enabled if the backend claims it supports mouse cursor.

[amc522]

This looks great. Your code definitely looks cleaner and more sane than mine. I think enabling resize on all borders and corners by default if the back end says it supports mouse cursors is a great idea.

One minor note regarding the corner resize grips. Why is there still a special case for the lower right grip to always be visible, even when there are multiple resize grips (imgui.cpp:5515)? I think it would be nicer if either all the grips were always visible, or, if there's more than one grip, not showing any of the grips until they are interacted with. So the code would be:

Grips invisible until interacted with

if (held || hovered)
    resize_grip_col[resize_grip_n] = GetColorU32(held ? ImGuiCol_ResizeGripActive : hovered ? ImGuiCol_ResizeGripHovered : ImGuiCol_ResizeGrip);

Grips always visible

resize_grip_col[resize_grip_n] = GetColorU32(held ? ImGuiCol_ResizeGripActive : hovered ? ImGuiCol_ResizeGripHovered : ImGuiCol_ResizeGrip);

Thoughts?

[ocornut]

I think it would be nicer if either all the grips were always visible, or, if there's more than one grip, not showing any of the grips until they are interacted with. So the code would be:

All grips always visible would be visually too noisy with the look they have.

The right direction seem to be that the grip should be invisible before you hover/active it (which you can currently get by locally setting the ImGuiCol_ResizeGrip color to 0). However users frequently have combination of resizable and auto-resized windows in their app, and it could make a little confusing to remove the visual cue. Perhaps clearing the ResizeGrip color in default theme would be appropriate.

[ocornut]

There's no a standard way for back-end to communicate the features they support,
io.BackendFlags |= ImGuiBackendFlags_HasMouseCursors

What it means is that maybe we can retire the ImGuiWindowFlags_ResizeFromAnySide flag and make it the default behavior if the back-end claim to support mouse cursors.

[amc522]

I think ImGuiBackendFlags_HasMouseCursors is a great addition. That would work for my use cases. As long as its well documented about what being assumed that you implement when enabling that backend flag.

[ocornut]

@amc522 I have pushed a change to remove the ImGuiWindowFlags_ResizeFromAnySide flag and replaced it with a global setting io.OptResizeWindowsFromEdges = true.

// [BETA] Enable resizing of windows from their edges and from the lower-left corner. 
// This requires (io.BackendFlags & ImGuiBackendFlags_HasMouseCursors) because it needs mouse cursor feedback. 
// (This used to be the ImGuiWindowFlags_ResizeFromAnySide flag)
bool          OptResizeWindowsFromEdges;              

I'm currently not making it the default because the behavior is not satisfying enough (because of how we don't detect it when hovering slightly outside of window rectangle + probably we should have a stateful system where once the resize cursor is offered, we should allow the mouse to wander a little more without losing that possibility).

Whenever the behavior is improved we'll make it the default.

For now I think we can close this topic!

[amc522]

Thanks for the update on the change. I dont have a lot of time right now, but maybe in a month or two i can start investigating how to use the mouse slightly outside the window.