emilk
Resizing a window moves it
Hello,
Resizing a Window can cause the window to go outside of the boundaries of the screen and allows the window to be extended over the side or top panels, where it normally cannot be dragged. This can be reproduced more easily on a smaller screen space on desktop.
I wanted to fix this, but I think this is by design. Looking at the following snippet: https://github.com/emilk/egui/blob/f5c372910c0ad659526397d03404b179f14e22a5/egui/src/context.rs#L487-L516
Now the discussion is, should we limit it to the screen size or should we keep as designed?
One idea I have is to make it configurable. If a overlap_panels flag is set then overlap the panels, if not go under them.
I thought this a good first issue for me so I'll try to add that flag. If I succeed I will send a PR.
I had actually tried playing around with this method as to simply constrain the window bounds within the area but could still drag it outside of the screen, so I suspected that something else might be going on here. However, I could've totally missed something!
Before adding anything like this though, its probably better getting @emilk 's input on the matter.
👋
To understand the motivation of the current behavior: resize the egui frame window to the size of a phone screen (or open the web demo on a mobile phone). Some windows are too wide to fit the screen, and all need to be able to cover the side bar to fit. When the screen is wide enough, however, I think it makes sense to only allow the windows on the central panel area. I agree this is a bit confusing. An option to toggle the behavior would not solve the core problem. I think the best solution (from a UI perspective) is to have a collapsible side bar so that for phone screens the side bar becomes a hamburger-menu or similar. That way the "allow windows to overlap sidebar" feature wouldn't be needed.
Some of the other confusing behavior in the gif comes from making the widget windows very large. In many cases it may make sense to have a maximum width, or restricting the resizing mouse cursor to the inside of the screen.
There is also the separate issue of moving a window by dragging the top edge of it: this is more of a bug, or an artifact of how resizing is done. It is a bit hard to handle it well in immediate mode without frame delay.
