Add flag to prevent window move unless dragging title bar

[ZelimDamian]

Currently window drawn by ImGui::Begin() will move when dragged by any empty area. Occasional accidental clicks very often mess up my ui by moving windows about.

Is there an easy way to find out if title is hovered apart from checking mouse coordinates and distance to the top of the window?

Or add a flag such as: ImGuiWindowFlags_MoveOnlyByTitleDrag?

[ocornut]

Is there an easy way to find out if title is hovered apart from checking mouse coordinates and distance to the top of the window?

There isn't at the moment (#823), will look at that. Adding the flag also seems sensible.

[sherief]

Keep in mind that you'll also need code to make sure the title bar remains visible at all times in this case, otherwise you can be stuck with a window you can't reposition because the title bar is off-screen.

[fuzzybinary]

I had this come up and was able to wrie a quick implementation, if you're still interested in this flag, what should it be called? I added it as "ImGuiWindowFlags_TitleMove" immediately after ImGuiWindowFlags_NoMove. I could issue a PR if poeple are still interested.

[ocornut]

Hello,

The main reason for stalling has been that I don't want to exhaust flags :)
The navigation branch and docking are introducing new flags and we'll run out at some point. We could switch to 64-bits flags but I don't know how that would affect language bindings. I guess moving the internal flags somewhere else would give us some leeway.

The other reason for stalling this is that the sort of flag I suspect interested users would want to pass everytime to Begin(). So maybe we should provide imgui-wide flags to alter behaviors (the same way we have io.OSXBehaviors, and the same way we will want to introduce flags to alter the style and behavior or common widgets such as sliders)

So:
I don't mind adding it as a window flag right now as you aren't the first person to request it, but I'll reserve the possibility to obsolete that flag if we end up transitioning to another system! So I'd take a PR.

ImGuiWindowFlags_MoveOnTitleBarOnly would work?

Please add new flag at the bottom of the public list to minimize issues with people who have duplicated flags in their language bindings. We can re-order the flags occasionally but there's no need to do it every time.

(
Tangential note:
In the current work-in-progress Docking/Tabs system #351, I was experimenting locally with limiting docking to when dragged from the title bar (vs whole window body). The reasoning is that docking overlays are quite aggressive to display at all time and when moving windows. And imgui apps by nature of often overlaying an existing software often requires lots of window moving. So restricting the docking features to when dragging from a smaller region seemed like a good idea to lower the display of those aggressive overlay. But of course it is arbitrary and this thread is a reminder that maybe some user would naturally always drag from the title bar. Maybe I'll solve this problem by adding an explicit subtle drag location on the title bar that acts as a Docking enabler?
)

[dmitsuki]

The issue for me is, and correct me if I'm misunderstanding something, but if I have a widget that is an image for example, but is actually a render target, I would like the person to be able to click and possibly drag from inside that RT. The problem of course is that any left click actions that drag move the entire window.

I don't see any way to stop this as most widgets in the demo have this behavior, but if I'm incorrect in that assumption and can disable dragging for specific widgets that would be useful. (Or to put it better, consume window events when a specific widget is hovered over)

[ZelimDamian]

@dmitsuki The way I got around this as suggested in one of the other issues is by using an ImageButton:

ImGui::ImageButton(texId, ImGui::GetContentRegionAvail(), ImVec2(0.0f, 1.0f), ImVec2(1.0f, 0.0f), 0);

[ocornut]

Literally any interactive widget will prevent window from being moved. What is your code doing?

Image() won't be enough as it's not an interactive widget.
But you can use an ImageButton() or you can use InvisibleButton() and then draw the game render yourself, etc.

[dmitsuki]

"Literally any interactive widget will prevent window from being moved. What is your code doing?"

I don't think it's a code thing, I think I just erroneously assumed graph widgets were interactive because they highlight current elements, but I was wrong. All buttons and the like work properly, and the solution works as well. Sorry for the confusion.

[ocornut]

This is a good point, "interactive" is not the term, PlotHistogram() highlight stuff but they don't have a unique identifier. It's actually generally the button behavior that requires a unique identifier. Hovering can be detected without a button behavior. Someone asked me the same thing recently, they didn't know what made a click not move a window. Hopefully we can clarify better in the docs later.

[Jamather]

you can make a child window that takes up pretty much the entire main window, save for the title bar, and enable the nomove flag on the child.
This is good for weird edge cases where you want to click and drag theoretical objects that exist only as drawlist entries. (Posting for future visitors)

[Wizzard033]

I've been forced to use range4life's hack fix for my custom widget to work right.
It's really quirky, and so I want to give my 👍 on prioritizing this issue.

[ocornut]

@Wizzard033 how does your custom widget works? There’s no eg InvisibleButton based interaction? Please provide as much context as possible, because I don’t think the OP request is the right solution for that widget issue discussed above.

[Wizzard033]

I'm drawing an image and supporting click+drag interaction on it.
Users are allowed to click+drag on the very edge of my image.
If a user slightly misses the edge of the image, I don't want the whole window moving.
So, I created a nomove child area around the image as a buffer to fix these just-off-the-edge misclicks.

My main reason for not liking this solution is that I now have extra padding around my widget.
It'd look better without this padding, and so the fix feels quirky, as I said.

Additionally, I don't like this form of window movement in the first place.
I come from a Windows-only background, which only allows moving from the title bar.
Although I'm not strongly opposed, I'd now like a flag to change it, which I will use as default.

[ocornut]

Thanks for the explanation, makes sense.

I think we could move this to ConfigFlags.

• It would affect the clamping of window position: if we can only move them from the title bar the clamping needs to make sure the title bar is always visible.
• On a window with ImGuiWindowFlags_NoTitleBar I presume we need to allow moving everywhere.

I'm flagging this for an upcoming release 1.61~1.62.

[Wizzard033]

That sounds great, thanks!

[ocornut]

This feature was added yesterday as a global toggle bool ConfigWindowsMoveFromTitleBarOnly in the ImGuiIO structure.
It should also work as expected in the Docking branch.

[ocornut]

Question to everyone using io.ConfigWindowsMoveFromTitleBarOnly:

Right now I ignored the flag on windows that have no title bar, so e.g. popups would still be moveable.
I'm now getting a request to fully disable moving on those windows.

Do you have any opinion on that?

I was hesitant because I'm worried it would remove that little bit of flexibility that could be useful in some situations (e.g. misplaced popups). For example I personally like to be able to move the color picker popup sometimes. And in many situation the programmer can still use ImGuiWindowFlags_NoMove if they want to enforce not moving.

It would however definitively feel more consistent. I'm not a user of io.ConfigWindowsMoveFromTitleBarOnly myself but I assume for people who are enabling this, it would feel backward to have the current behavior enabling moving popups.

So most likely I am going to make that change now but any feedback/opinion are welcome...

And maybe I should aim to allow for another form of interaction to move windows.

(Bonus: I should mention that it is possible to move windows with the navigation system, currently holding CTRL+Tab then using Arrows or Shift+Arrows allows you to move and resize windows. I assume this is not well known! This was designed for the Gamepad controls and I left it for keyboard because I should it was convenient and not harmful.)

[Wizzard033]

As someone using io.ConfigWindowsMoveFromTitleBarOnly, moving popups feels good. It'd be a shame if they were changed in a way that I can't revert back to the current behavior. I agree that "MoveFromTitleBarOnly", when taken literally, does imply popups would not be able to be moved. I think it'd be convenient if both were supported.

I'm glad to know there is keyboard shortcuts to move things, but I'm skeptical about adding new interactions to move windows. I feel that it'd be potentially intrusive to some of peoples' many widget interactions they already have created. As far as I know, the only ways to move a window on Windows are to (1) click+drag title bar (2) use keyboard shortcut windowskey+arrows while window is selected or (3) right click the window in the task bar and select move.

[dmitsuki]

I think requiring the popup to have a title bar if you wish to be able to move it is fine and Windows works itself IIRC.

[Wizzard033]

Can the color picker popup be forced to have a title bar?

[ocornut]

I think requiring the popup to have a title bar if you wish to be able to move it is fine and Windows works itself IIRC.

The BeginPopup() removes the title bar and there's no way to re-enable it presently.
Specifically in the case of the default color picker popup we could add a title bar but that wouldn't cover the majority of user's popups.

[dmitsuki]

Is it too much bloat then to have optional BeginPopup(flags.ForceDragable) then, so movement is opt in?