| Summary: | Some fullscreen apps are getting a window decoration | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | tim |
| Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | cedric.bregardis, cnlobracco |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
tim
2004-01-26 03:00:40 UTC
See bug #69635 for that specific case. I'm afraid I can't test Vice City. Could you attach xwininfo and xprop output for its window? I missed to describe a important point about the Vice City problem: when switching to fullscreen doesn't work, it seems to try again, leaving the game in a loop switching between the menu in a window frame and a blank fullscreen screen several times a second. Every time it goes to the blank fullscreen it repositions the cursor at 0/0, which makes it quite difficult to click into the window. That makes it quite difficult to use xwininfo (the system is unsuable until I kill wine), but somehow I managed to get some output from wininfo/xprop:
xwininfo: Please select the window about which you
would like information by clicking the
mouse in that window.
xwininfo: Window id: 0x4c00004 "Wine DirectDraw HAL"
Absolute upper-left X: 0
Absolute upper-left Y: 0
Relative upper-left X: 0
Relative upper-left Y: 0
Width: 1280
Height: 1024
Depth: 24
Visual Class: TrueColor
Border width: 0
Class: InputOutput
Colormap: 0x4600001 (installed)
Bit Gravity State: ForgetGravity
Window Gravity State: NorthWestGravity
Backing Store State: NotUseful
Save Under State: no
Map State: IsViewable
Override Redirect State: no
Corners: +0+0 -0+0 -0-0 +0-0
-geometry 1280x1024+0+0
WM_STATE(WM_STATE):
window state: Normal
icon window: 0x0
_NET_AM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_CHANGE_DESKTOP
_NET_WM_DESKTOP(CARDINAL) = 0
_KDE_NET_WM_USER_CREATION_TIME(CARDINAL) = 21683490
_WIN_LAYER(CARDINAL) = 10
_NET_WM_STATE(ATOM) = _NET_WM_STATE_FULLSCREEN, _NET_WM_STATE_ABOVE, _NET_WM_STATE_STAYS_ON_TOP
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x3, 0x0, 0x0, 0x0, 0x0
WM_LOCALE_NAME(STRING) = "en_US"
WM_CLASS(STRING) = "wine", "Wine"
WM_HINTS(WM_HINTS):
Client accepts input or input focus: True
Initial state is Normal State.
WM_NORMAL_HINTS(WM_SIZE_HINTS):
user specified location: 0, 0
user specified size: 1280 by 1024
program specified minimum size: 1280 by 1024
program specified maximum size: 1280 by 1024
WM_CLIENT_MACHINE(STRING) = "cookie"
WM_ICON_NAME(STRING) = "Wine DirectDraw HAL"
WM_NAME(STRING) = "Wine DirectDraw HAL"
Hmm. It has maximum size specified as well. I guess I'll have to redo the code to check the maximum size dynamically :-/. The krdc suggestion given in the other bugreport remains, though. Subject: kdebase/kwin CVS commit by lunakl: Don't disallow fullscreening for windows that have maximum size set, way too many apps apparently think setting a maximum or fixed size and then requesting fullscreen is ok. CCMAIL: 73509-done@bugs.kde.org M +5 -4 geometry.cpp 2.49 --- kdebase/kwin/geometry.cpp #2.48:2.49 @@ -1395,12 +1395,13 @@ void Client::resetMaximize() bool Client::isFullScreenable( bool fullscreen_hack ) const { - return isFullScreen() // necessary, because for fullscreen windows isMaximizable() returns false - || (( isNormalWindow() || isOverride()) - && ( isMaximizable() || fullscreen_hack )); + if( fullscreen_hack ) + return isNormalWindow() || isOverride(); + else // don't check size constrains - some apps request fullscreen despite requesting fixed size + return !isSpecialWindow(); // also better disallow only weird types to go fullscreen } bool Client::userCanSetFullScreen() const { - return isFullScreenable() && isNormalWindow() && fullscreen_mode != FullScreenHack; + return isNormalWindow() && fullscreen_mode != FullScreenHack && isMaximizable(); } *** Bug 73564 has been marked as a duplicate of this bug. *** |