[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwin
Subject:    Re: Maximization broken
From:       Thomas =?UTF-8?B?TMO8Ymtpbmc=?= <thomas.luebking () gmail ! com>
Date:       2011-09-30 19:16:11
Message-ID: 20110930211611.1f74299f () gmail ! com
[Download RAW message or body]

Am Fri, 30 Sep 2011 15:49:49 +0200
schrieb Lubos Lunak <l.lunak@suse.cz>:
>  Hello,
Hi.

>  can somebody please explain to me bug #279529 and what these days
> 'maximized' is supposed to mean?
You get the maximum size permitted by this window.
This includes the maximum size hint in WM_NORMAL_HINTS as well as
geometry restrictions like aspect ratio and base increment.

To put the reason in one line:  "the client asked for them."

KWin used to ignore them by default when "maximize" was pressed what
worked for or somehow "fixed" clients like xterm (but still failed on
others like emacs which simply fought this ignorance by multiple
configure requests) and kinda "broke" clients like video
players (eg. mplayer) which set (in this case the aspect ratio) it for
a good reason.

Since the clients either has a good reason for such a restriction or has
not (i don't quite understand it for xterm and the gtk-terminal classes)
this was inverted to support those clients with a good reason by
default, you'll have to "fix" the others by a rule.

As consequence the "maximize" button now reflects the
_NET_WM_STATE_MAXIMIZED_* hints, not the actual geometry.
This also means that a client with a (former rule caused) restricted
geometry can now be restored as well as a window with geometry
restrictions in WM_NORMAL_HINTS can now be maximized (to what is
possible)

I am deeply sorry that not all conditions under all optional kwin
features were immediately covered by the change.
I hope they meanwhile are, but the bug you mentioned was fixed.

No feature should be lost, but emacs is under control..., and windows
with intact restricted geometry (formerly by rule) can be restored.
The only change is the requirement to add a rule to xterm and the
gtk-terminal based applications in case you want them to be able to
cover the entire screen (and resize them freely in general) despite
they actually don't want (in some case: "at all")

As a side note: it's not an intention and no way a reason, and i
figured after providing the review requests, but compiz actually acts
pretty much the same way.

> (try e.g. to change the screen size while having such "maximized" windows).
Errr... yes? The client remains maximized and shrinks to the bounds of
the new screenarea (minus struts) here (4.7 and master)
Would you expect a different behaviour?
It would probably helpful to understand the issue if you'd name the
client in particular.

Cheers,
Thomas
_______________________________________________
kwin mailing list
kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin
[prev in list] [next in list] [prev in thread] [next in thread]