Bug 170488 - Window sizes should not be constrained on resolution changes
Summary: Window sizes should not be constrained on resolution changes
Status: RESOLVED NOT A BUG
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: git master
Platform: unspecified Linux
: NOR wishlist
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-09-05 23:02 UTC by Tom Adams
Modified: 2011-06-21 19:04 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Adams 2008-09-05 23:02:25 UTC
Version:           3.0 (using KDE 4.1.1)
OS:                Linux
Installed from:    Unlisted Binary Package

(zsnes is the only application I use which uses SDL, and so fullscreening in zsnes involves changing the resolution. It may be SDL or the resolution-changing that's at fault here.)

When I fullscreen and unfullscreen zsnes, it resizes gnome-terminal windows to be 20 lines high (I'd use KDE's only it doesn't allow resizing by line/column) and it resizes Dolphin windows to span from the top of the screen to the top of the panel (but not change their horizontal size). It always affects these two applications and nothing else.

This didn't happen in the previous version (KDE 4.1.0, I think).
Comment 1 Jaime Torres 2010-10-10 11:32:32 UTC
I see something similar, in KDE 4.6 development, doing the following:
mplayer -vo sdl <any video>
Switch mplayer to full screen (F), switch back to window (F).
All the windows that were touching any of the screen edges are now resized. (and I have screen edges effects disabled)
Comment 2 Julien Gouesse 2011-06-21 00:37:50 UTC
I have the same problem with Warmux on Mageia 1 with KDE SC 4.6.3.
Comment 3 Julien Gouesse 2011-06-21 00:39:24 UTC
Related bug on Mageia: https://bugs.mageia.org/show_bug.cgi?id=1859
Comment 4 Julien Gouesse 2011-06-21 00:39:58 UTC
Related bug on Mageia 1: https://bugs.mageia.org/show_bug.cgi?id=1859
Comment 5 Thomas Lübking 2011-06-21 01:13:33 UTC
That "Mageia" (what's a mageia?) bug is not related at all.

1. i cannot reproduce (as of 4.6.4, sorry got no old version to try) the "bug" described in the original post which reads like "random clients should not adjust their size on resolution changes" (at least not with dolphin, got no gnome terminal here) and that would be no kwin wish/bug.

2. the bug linked in comments #3/4 is rather unrelated mostly about java "fullscreen" applications keeping the panel on top of them.
can you please run konsole and call:
   kwriteconfig --file kwinrc --group Windows --key LegacyFullscreenSupport true
qdbus org.kde.kwin /KWin reconfigure
(in doubt: restart "kwin --replace &" after the kwriteconfig call)

3. The flash issue described is likely unrelated to even 2. and derives from the focus stealing protection and an incooperative firefox flash usage, see bug #253900
Comment 6 Julien Gouesse 2011-06-21 10:21:29 UTC
Mageia is a new Linux distro based on Mandriva Linux 2010. The bug report I quoted deals with a strange behavior with Warmux which uses SDL and plain C too, not only about Java. Should I write another separate bug report for this problem that concerns only KDE?
Comment 7 Julien Gouesse 2011-06-21 10:31:33 UTC
Ok I will try this command at home. At work the bug is not reproducible.
Comment 8 Thomas Lübking 2011-06-21 13:55:34 UTC
The bug you quoted is "KDE 4 taskbar is always on top of fullscreen applications" - that's not our bug #170448 but bug #224600 at best 
(and my stomach says: java doesn't go "fullscreen" but maximizes and removes the titlebar. you could try whether the fullscreen setting in the alt+f3 window menu works)
Comment 9 Julien Gouesse 2011-06-21 14:37:42 UTC
The bug 224600 has been fixed whereas the bug concerning specifically Java has not been fixed. The bug 224600 does not seem to concern Java, it deals with Firefox.
Comment 10 Thomas Lübking 2011-06-21 14:53:08 UTC
No, it deals with the fact that kwin denies the fullscreen state to windows which are not on top of the stack, what was and actually is a persisting violation of the NETWM spec, worked around by rising a window before tagging it fullscreen.

Also this does not make this bug your linked mageia bug at all.

Your bug (since it hits only one class of a really retarded UI, java has a history on this) is -likely- "i don't know what a fullscreen is" while /this/ bug here was *completely* different and about windowsize changes induced by resolution changes, so we're basically polluting this bug with an unrelated discussion.

Please check the two things mentioned and feel free to open a new bug on this particular issue.
Thanks.
Comment 11 Julien Gouesse 2011-06-21 17:08:19 UTC
I remind you that the mageia bug I quoted deals with 2 problems and the second one concerns applications (not Java related) in fullscreen that have a strange behavior on exiting. I do the following steps:
- launch Mageia Control Center
- maximize it
- launch Warmux
- change its resolution
- put it into fullscreen
- exit

Then, the MCC is no more maximized, I did not expect that the size of this window (MCC) should be constrained to the resolution change done by Warmux. I hope it is clear now.

The bug concerning Java does not concern only a single class, it concerns both AWT and Swing. I have opened another bug report here:
https://bugs.kde.org/show_bug.cgi?id=276159

Another one has been opened at Oracle.

Thanks for explaining that some applications use a workaround.
Comment 12 Thomas Lübking 2011-06-21 17:30:15 UTC
more clear than "the taskbar icons are then not displayed correctly."
-> Does it happen to any other application (under this condition) or just the Mageia Control Center?
Also there's quite a good chance that it won't apply on latter 4.6.x or at least 4.7 versions (if the maximized state is mandantory) since the maximization state has been completely unlinked from the geometry.


The NET_WM fullscreen spec is no "workaround" but the way that is supposed to be used for ten years now. If it's not used 
The workaround is unrelated, in kwin and alignes stack position and activation status of fullscreen windows.
Comment 13 Julien Gouesse 2011-06-21 18:58:12 UTC
I have just checked, it happens only with the MCC, it is not very important.

Ok, you say that Java should do the same, rising a window before tagging it fullscreen, don't you?
Comment 14 Thomas Lübking 2011-06-21 19:04:51 UTC
No, that bug is rather a corner case issue and derives from clicking the panel.