On 09/21/2014 04:55 AM, Carlos R. Mafra wrote: > On Sat, 20 Sep 2014 at 22:56:24 -0500, Doug Torrance wrote: >> If a user moves a window which is currently maximized, the current behavior >> is >> to keep the window geometry and maximized status unchanged. This can lead to >> peculiar behavior. For example, suppose a user maximizes a window to the >> right half of the screen (either through the window menu, keyboard shortcut, >> or >> new snapping feature), then moves it, and then attempts maximize it to the >> right half of the screen again. Instead of the expected result, the window >> is >> unmaximized and returned to its original geometry. >> >> This patch changes the behavior by unmaximizing any maximized window which is >> moved. This is consistent with other desktop environments, e.g., GNOME, >> Unity, >> and Windows. > I think it's even more peculiar to start moving a window and it suddenly > changing its size.
Fair enough. > I just tested it to check the WTH effect, and it's big. I started to > move a right-half maximized window and it changed to another size., it's > a big surprise. Not at all what one expects when moving a window. > > When moving a window the user expects it to _move_, not change > its size. As I mentioned in the patch, they might, as the proposed behavior is already standard in GNOME, Unity, Windows, and possibly others (that's all I tested). Perhaps I could still add it as a configurable option? > The peculiar behavior you described is of second order compared to > this. And the surprise effect is much smaller since the user is > expecting the window size to change anyway. > > Perhaps you can change this behavior by clearing the "memory" > of its past geometry when moving a window, that's is what > causes the window to return to its original geometry. Sounds good. I'll play around with that and submit a new version. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
