search

bbidulock / icewm

A window manager designed for speed, usability, and consistency
Other
597 stars 99 forks source link

Unmaximize when dragging action (from a window title) starts #780

Closed Code7R closed 2 weeks ago

Code7R commented 4 months ago

Hi,

there is a certain behavior which has been implemented long time ago by "a certain software company" in their OSes, i.e. about 15 years ago. Which is: when the user touches the window title, clicks, and start moving, then the window starts moving. And this ALWAYS MUST WORK! I.e. no matter whether the window has been in maximized mode or not (i.e. if it was in maximized state, then the maximized state is removed and the window returns back to the "native size" and then the window gets moved around when cursor moves).

Unfortunately, this is not the case for IceWM. If the window is maximized, when $user clicks on the title and starts dragging, then NOTHING happens. Okay, almost, the cursor icons changes to "moving cross" icon (which you would expect) but the window itself is NOT MOVING. This is really counter-intuitive, like nya-nya-I-could-move-but-I-refuse-TO. I wish it would behave more like certain-SW-company-OS, so it just does what the user expects.

gijsbers commented 4 months ago

I'll revert this, since holding down the Shift key while dragging already does what you want. Isn't that documented?

Code7R commented 3 months ago

I don't know where this is documented. When I read icewm(1) and search for "drag", it does not actually give me an idea about using Shift.

Also, even using Shift & drag, the moved window still keeps the Maximized state, so any click into it later makes the window jump back to its original position. That is not like what we are used to on Win7+, when the window mutates to unmaximized while it's being moved with the mouse cursor.

gijsbers commented 2 weeks ago

On July 24th commit 92961de documented the Shift+drag behavior. There is no design goal to behave like XYZ to a degree such that users of XYZ have zero surprises.