! 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 !
Disable maximized-without-borders mode by default
Status:
RESOLVED: FIXED
Severity:
enhancement

Comments

Description Benedikt Meurer editbugs 2006-09-03 14:24:43 CEST
The new maximized-without-borders mode (-> full maximization) in xfwm4 doesn't work properly with most applications. I.e. with most editors (gvim, emacs) that looks rather weird, since the editor window cannot use the full size allocated to it. Also the missing borders IMHO reduce the usability of maximized windows in Xinerama mode, because with two windows maximized there's no visual separator between them anymore.

I'm not sure what was the motivation to change maximization this way, but IMHO this should be disabled by default, as full maximization - if needed - can already be gained by using Alt+F11.
Comment 1 Jean-François Wauthy editbugs 2006-09-03 14:25:43 CEST
i second the proposal
Comment 2 Olivier Fourdan editbugs 2006-09-03 19:41:52 CEST
No sorry, that won't be reverted and that will not be configurable.

But, I'm wondering what you mean by "doesn't work properly with most applications."

Can you provide a screenshot?
Comment 3 Benedikt Meurer editbugs 2006-09-03 19:49:19 CEST
http://xfce.org/~benny/tmp/gvim-fullscreen.png

As you can see the editor window doesn't cover the whole area, but since the window manager assigns the space all the application can is "ignore" the additional space.

What cannot be shown in screenshots is that the new behaviour feels like part of the text is "hidden" in the monitor borders. Dunno if one can get used to that. But right now that looks and feels broken. I usually have a vim window maximized on one monitor without any panels on that monitor, which probably explains why nobody else complained about this before as I guess the common case is that atleast a top/bottom panel gives the feeling of seperation between the window content and the monitor borders.

What was the actual reason to change the maximization this way?
Comment 4 Olivier Fourdan editbugs 2006-09-03 20:00:46 CEST
The reason is bug#1750, and its listed in the Change Log for RC1. FYI, all modern WM work like that (that's for fitt's law or something, ppl keep asking for that)

I still fail to see anything wrong with your screenshot, how the editor cannot use the full size allocated to it? The text start at top, ends at bottom, the line starts at left and ends at right.

As for the feeling of separation between the window and the screen edge, that's exactly the goal of that change.
Comment 5 Benedikt Meurer editbugs 2006-09-03 20:09:45 CEST
The scrollbar is not where it should be, but there's additional space between the scrollbar and the window edge. Changing the font size adds additional space at the bottom (with emacs I cannot even find a font size so that it doesn't look odd).

I didn't use window managers other than xfwm4 for a long time, so I don't know what other window managers are doing (not that I'd care).

While I see that this might be useful to some people (tho I fail to understand why they don't use Alt+F11 instead, which would even remove the title bar), to me this is just broken.

If it cannot be reverted, it'd be nice if there'd be atleast a hidden option (nothing for the tweaks plugin) to get back to the original behaviour with borders to separate the window content from the monitor borders.

Currently it requires a lot of concentration to work with my editor window, because it's dark outside and I'm used to have a black window background, which means atleast the left edge of the editor window is not visually separated from the monitor. Same for terminal windows, tho, since I'm using a pseudo transparent background that's atleast less of a usability problem than with the editor windows.
Comment 6 Benedikt Meurer editbugs 2006-09-03 20:19:35 CEST
http://espresso.foo-projects.org/~benny/tmp/unusable-maximization.png

A better example that illustrates the problems with the new maximization (that's also reproducable with smaller font sizes, but the large font size makes up for a good example).
Comment 7 Olivier Fourdan editbugs 2006-09-03 20:24:43 CEST
That's because you changed the font size while maximized. Just unmaximize/remaximze your window when you change the font size (and thus the size increments) - That's really a non issue, how often do you change font size in your maximized terminal window? So yes, I definitely call this "usable", to reply your question.

So to say, "The new maximized-without-borders mode (-> full maximization)
in xfwm4 doesn't work properly with most applications." reads it looks weird
with gvim in Terminal ;)

I'll see for a hidden option, let's say it's like a special favour :o
Comment 8 Benedikt Meurer editbugs 2006-09-03 20:27:39 CEST
I did indeed remaximize the window. If I don't remaximize after changing the font, it looks like this:

http://espresso.foo-projects.org/~benny/tmp/unusable-maximization-1.png
Comment 9 Olivier Fourdan editbugs 2006-09-03 20:36:29 CEST
That looks like a bug either in vte or in vim you are running, I'm not seeing such behaviour here.

The app should not try to allocate a larger area than the one alloted by the WM.
Comment 10 Benedikt Meurer editbugs 2006-09-03 20:39:57 CEST
Problem is probably that the app tells the window manager that it can only be sized in chunks of dx/dy, but the window manager allocates another size. Anyway, as said, that is not the main problem, just another oddity. My main problem is the visual separation. If there's a possibility to disable the new behaviour, I'll be more than happy with it. ;)
Comment 11 Olivier Fourdan editbugs 2006-09-03 22:25:13 CEST
The option is "borderless_maximize". Just set it to false to get the older behaviour.

Closing that bug, please reopen if you have any problem with it.
Comment 12 Benedikt Meurer editbugs 2006-09-03 22:26:15 CEST
Already updated. ;-)

Perfect, thanks.
Comment 13 Olivier Fourdan editbugs 2006-09-04 19:41:26 CEST
Option added to the WM tweak plugin, allowing on-the-fly change.
Comment 14 Scott H 2006-09-05 19:36:43 CEST
Glad to see it was added as an option, I strongly don't like this default either. Keep up the good work :)
Comment 15 Olivier Fourdan editbugs 2006-10-09 09:24:12 CEST
*** Bug 2390 has been marked as a duplicate of this bug. ***

Bug #2257

Reported by:
Benedikt Meurer
Reported on: 2006-09-03
Last modified on: 2009-07-14
Duplicates (1):
  • 2390 Maximizing windows without borders creates flickers with xemacs

People

Assignee:
Olivier Fourdan
CC List:
3 users

Version

Attachments

Additional information