! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Window Manager reverts windows vertically maximized on move
Status:
RESOLVED: MOVED

Comments

Description Steve Lamont 2015-06-21 01:34:05 CEST
When a window is maximized vertically, attempting to drag it to a new position causes the window to revert to its original size.

A suboptimal workaround is to use the "Fill window vertically," which does not revert when the window is dragged but it also does not allow the user to toggle between vertical maximization and default size.

Could either the "Fill window vertically" Window Manager->Keyboard action be modified to toggle or the "Maximize window vertically" behavior be modified to suppress the reversion on drag?

Thanx.
Comment 1 Eric Koegel editbugs 2015-06-21 10:58:04 CEST
Moving to xfwm4, it handles the windows.
Comment 2 Joel Brobecker 2015-07-02 19:31:02 CEST
+1.

The "Fill window vertically" also does not always work, because some windows might already be displayed and "get in the way" of full maximization.
Comment 3 Olivier Fourdan editbugs 2015-07-03 09:15:16 CEST
That's by design and on purpose, moving a maximized window (even partially) will un-maximize it.
Comment 4 Joel Brobecker 2015-07-03 15:40:02 CEST
For me at least, this is unhelpful 99.9% of the time. It would be really helpful if there was a way for us to either: have a setting that turns this behavior off, or else provide another operation, similar to maximize, but with the auto-unmaximize-when-move feature turned off.

Thank you!
Comment 5 Steve Lamont 2015-07-04 00:05:39 CEST
Created attachment 6362 
prevent_unmaximize_on_move
Comment 6 Steve Lamont 2015-07-04 00:07:24 CEST
I confess I don't understand why this design feature exists.

Every other window manager I've used (and I've use a lot of them, going back to tvtwm on a Sun 4 and whatever that horrid Display Postscript abomination was on the early SGIs) and any window manager that supported toggling maximization, full, horizontal, or vertical, did what I've come to believe is the Right Thing by not unmaximizing when repositioning the window.

I'm willing to be educated on this point, however.

Be that as it may, I spent a little time hacking on the window manager and have at least a provisional solution.

I've added a boolean configuration setting "prevent_unmaximize_on_move" (I defaulted it to TRUE but I suppose so as not to startle any users expecting the original behavior it could be defaulted to FALSE) and a test in moveresize.c.

Patch submitted above.
Comment 7 Steve Lamont 2015-07-20 00:50:25 CEST
Followup: I've been running this modified window manager for the last couple of weeks with no problems.

May I humbly request that this change be integrated into the next iteration of xfwm4 at your earliest convenience?
Comment 8 Olivier Fourdan editbugs 2015-07-20 08:38:06 CEST
This option has been removed on purpose:

http://git.xfce.org/xfce/xfwm4/commit/?id=d995192

I reckon the original code was more complete that this patch, but again, that was removed because it was causing issue with tiling.

You may wan to use an older version of xfwm4 which had this options or revert the commit in your own builds.
Comment 9 Joel Brobecker 2015-07-20 17:31:45 CEST
I fear that either suggestion is unfortunately impractical for the majority of people. Even for someone like me, who has been working on Free Software projects such as GDB for nearly 15 years, I would much rather spend my time on projects that I dedicated myself to (familiarity leading to more efficient use of time), rather than hack on the WM. Imagine what it's going to be like for those less comfortable with hacking.

How do other WMs handle the situation? There has to be an answer there...
Comment 10 Steve Lamont 2015-07-20 18:12:28 CEST
Perhaps rather obviously, I agree with Joel.

While I can indeed maintain my own version of the window manager, it is something that I'd rather not do, just from the annoyance factor.

As I have mentioned previously, every other window manager I've used in the past 25 or so years which provides a "maximize" option has not insisted upon reverting the size of the window when the user moves it. To do so, in my humble opinion, fails the Principle of Least Astonishment.

Perhaps I am missing something and, again, as said above, I'm willing to be educated on this point.  Maybe it's a matter of terminology: I'm not precisely clear on what is meant by "tiling." I assume it has to do with positioning of the window upon creation. If I'm all wet there, I'd be curious to know what the term means in the context of the XFCE lexicon.

Having said all of the above, I don't think it would be a huge imposition to include an option (as I have demonstrated) to retain the maximization on window drag.  I'd be perfectly happy to have it defaulted to the current standard window manager behavior, just as long as there's a setting to defeat it.

That seems fair to me though I freely admit I might be totally nuts.
Comment 11 Joel Brobecker 2015-09-19 21:37:56 CEST
Any update on this topic? An option would be sufficient, and seems easy enough to implement. Or else another operation which permanently changes the window's size so as to be the maximum vertical size would also work well, I think.

Thanks!
Comment 12 Steve Lamont 2015-09-19 22:00:02 CEST
I prefer the ability to toggle.  As mentioned above is a "Fill window vertically" which sort of works (it has some quirks when other windows are present -- if a window on the screen is above the window you're trying to maximize, it only expands the window to the bottom of the other window -- if that makes any sense at all).

I've been running my modified xfwm4 for a couple of months now and have had no problems with it whatsoever.

Again, I've not seen any explanation for the design decision other than "That's of seldom use and is not compatible with tiling" which, to me, at least, is not terribly edifying.  Of course, I'm not a window manager designer or maintainer. . . just someone who wants to use the darned thing.
Comment 13 Martin Walter 2015-09-23 15:03:17 CEST
Strong support for Steve and Joel. The current behavior is really annoying. Why not make it optional? Please do not reduce the previous very good ability to customize xfce.
Comment 14 Olivier Fourdan editbugs 2015-09-23 15:11:05 CEST
(In reply to Martin Walter from comment #13)
> Strong support for Steve and Joel. The current behavior is really annoying.
> Why not make it optional? Please do not reduce the previous very good
> ability to customize xfce.

My reply is in comment 3, and that has not changed.

I explained the rationale behind removing this option in comment 8 and I am personally happy with this.

Ability to customize has never been a project goal, quite the opposite actually. As far as I am concerned, this is a no-go, it's been said before and I am not willing to change that.
Comment 15 Steve Lamont 2015-09-23 16:31:13 CEST
> I explained the rationale behind removing this option in comment 8 and I am
> personally happy with this.

Perhaps I am just rather dense (always a good first hypothesis) but with all due respect the "rationale" presented in comment 8 is not clear to me.  "[I]t was causing issue with tiling" is a non-answer.  How does it interfere with tiling?  In fact, what the heck is "tiling" in the first place.  I understand the term from a computer graphics and animation standpoint of subdividing surfaces for rendering but it is meaningless to me in the context of window management.

> Ability to customize has never been a project goal, quite the opposite
> actually. As far as I am concerned, this is a no-go, it's been said before and
> I am not willing to change that.

Seriously?

*Sigh*

Back to KDE then.

No need to reply to this comment.
Comment 16 Joel Brobecker 2015-10-10 01:35:05 CEST
Olivier Fourdan,

To see how this change was perceived by the users, I decided to try a quick poll. Only 15 people answered (not including myself), but I think a fairly clear picture emerged.

Question #1: How often do you use Window Maximization?

Number of answers for each option:
  Occasionally: 4
  Often:        4
  All the time: 5

  (no one answer "never" or "rarely")

Question #2: On a scale from 1 (annoying as hell) to 7 (very useful), how useful do you find the fact that moving maximized windows causes them to be resized back to their original size (please answer "N/A" if you do not use this feature)?

  1 answered: N/A (??? I suspect they meant to answer "1" instead)
  2 answered: 1
  1 answered: 2
  1 answered: 5
  6 answered: 6
  4 answered: 7

The answers certainly surprised me, as I cannot imagine how someone can find this useful; but the fact is more people find it useful than a nuisance.

However, as the distribution shows, there are only strong opinions about this.

So, my conclusion from the survey is that window maximizing is a feature that gets used quite a bit, by nearly everyone. ~65% are happy with the fact that the windows get automatically un-maximized when moving them. ~35% are strongly dissatisfied with this behavior.

Personally, and I know what I think may not matter in the grand scheme of things, but my feedback is that this is getting so much in my way that, unless you reconsider adding an option, I will probably switch away to something else.
I have no idea whether the 35% polled feel that way, but I suspect I'm not going to be the only one.
Comment 17 Konstantin Svist 2015-12-18 23:44:37 CET
I hope this change can be brought back. I use maximized windows all the time, on several monitors. When I move a maximized window to another monitor, I usually want it to re-maximize.
If I didn't want it re-maximized, I would keep it away from the top of the screen and life went on.

If it's incompatible with tiling, then make those options mutually exclusive. I don't care for tiling at all, actually, and always keep it off.

If you want to change the feature to "only tile maximized windows" that's fine by me.
Comment 18 Git Bot editbugs 2020-05-29 12:06:46 CEST
-- GitLab Migration Automatic Message --

This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfwm4/-/issues/189.

Please create an account or use an existing account on one of our supported OAuth providers. 

If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests

Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev

Bug #12000

Reported by:
Steve Lamont
Reported on: 2015-06-21
Last modified on: 2020-05-29

People

Assignee:
Olivier Fourdan
CC List:
4 users

Version

Version:
unspecified

Attachments

prevent_unmaximize_on_move (3.69 KB, patch)
2015-07-04 00:05 CEST , Steve Lamont
no flags

Additional information