Bug 335617

the window probably still has size constraints (the aspect ratio) when requesting to be mapped, thus kwin denies "isFullScreenable()", assuming the window (video) would get a wrong aspect - i assume those are withdrawn when the window gets fullscreened at runtime (and mpv adds black borders)

leaving open, kwin could ignore geo restrictions on mapping to rank the clients fullscreen request (state can be assumed to come from there) stronger than the aspect request.

I don't think mpv removes the aspect size hints (it always sets PAspect when calling XSetWMNormalHints() -  unless mpv is started with --no-keepaspect). But note that for fullscreening after map, a _NET_WM_STATE message is sent to toggle the state. And reportedly, fullscreening works after the window was created.

Status quo:
KWin applies fullscreen mode for client messages unconditionally, but on mapping "isFullScreenable()" is tested (ever since), which will return false since fixing bug #324733

We should pick one behavior.
Since both hints can be assumed to come from the client (and the mapping state even more than the message) I'd vote for relaxing and removing the ::isFullScreenable() test on ::manage()

Users still won't be offered to fullscreen windows w/ fixed aspects (since it's not certain whether the client can deal with that in a sane way) but the client can request the state at runtime AND initially.

I'm not sure what's this about forcing aspect in fullscreen - obviously the client doesn't expect that the aspect hints are honored when the client requests going into fullscreen.

The user can move _any_ window to fullscreen by context menu or KWin shortcut.

The check on ::manage() predates the git history (there was a branch change in early 4.0 times) - I don't know why it's there (but not on the client message response)

The manage code by this also doubles the rule check (breaking the "apply initially" condition), so I assume it's cruft (the code could date back to 1998 when there was no _NET_WM_STATE ;-)

> Since both hints can be assumed to come from the client (and the mapping
> state even more than the message) I'd vote for relaxing and removing the
> ::isFullScreenable() test on ::manage()

"The Window Manager SHOULD honor _NET_WM_STATE whenever a withdrawn window 
requests to be mapped."

sounds to me like we need to honor it.

> The check on ::manage() predates the git history (there was a branch change
> in early 4.0 times) - I don't know why it's there (but not on the client
> message response)

one can get past that point by nice combinations of git log and blame, but I 
wouldn't be surprised if it goes back to initial commit

Git commit 43229afee9fac4303e3d280ea63f96f034b3ffb5 by Thomas Lübking.
Committed on 05/06/2014 at 18:23.
Pushed by luebking into branch 'KDE/4.11'.

allow FS mapping of geometry restricted windows

and copy isSpecialWindow() check as rulebook input
to setFullscreen()

Client::isFullScreenable() checks:
* fullscreen rule
* fullscreen_hack (-> for normal windows)
* geometry restrictions
* special window

Client::manage() for fullscreeining checks:
* fullscreen rule (with correct "initial" parameter)
* fullscreen_hack

-> this breaks the fullscreen rule for geometry restricted windows
and causes inconsistent behavior between client requests at runtime
(which do not test ::isFullScreenable()) and on mapping.

Otoh, the specialWindow() protection should apply generally - those
kind of windows should not be fullscreened since the user can not
exit this state via kwin for them - and there's hardly a good reason
for them to be fullscreen, esp. not to enter that state at runtime

REVIEW: 118442
FIXED-IN: 4.11.12

M  +1    -1    kwin/geometry.cpp
M  +1    -1    kwin/manage.cpp

http://commits.kde.org/kde-workspace/43229afee9fac4303e3d280ea63f96f034b3ffb5

Git commit 75a298a4fbea8ec8dccd2e78aaa5ecc6f830846f by Martin Gräßlin, on behalf of Thomas Lübking.
Committed on 05/06/2014 at 18:23.
Pushed by graesslin into branch 'master'.

allow FS mapping of geometry restricted windows

and copy isSpecialWindow() check as rulebook input
to setFullscreen()

Client::isFullScreenable() checks:
* fullscreen rule
* fullscreen_hack (-> for normal windows)
* geometry restrictions
* special window

Client::manage() for fullscreeining checks:
* fullscreen rule (with correct "initial" parameter)
* fullscreen_hack

-> this breaks the fullscreen rule for geometry restricted windows
and causes inconsistent behavior between client requests at runtime
(which do not test ::isFullScreenable()) and on mapping.

Otoh, the specialWindow() protection should apply generally - those
kind of windows should not be fullscreened since the user can not
exit this state via kwin for them - and there's hardly a good reason
for them to be fullscreen, esp. not to enter that state at runtime

REVIEW: 118442

Cherry-picked from kde-workspace
43229afee9fac4303e3d280ea63f96f034b3ffb5

M  +1    -1    geometry.cpp
M  +1    -1    manage.cpp

http://commits.kde.org/kwin/75a298a4fbea8ec8dccd2e78aaa5ecc6f830846f