Bug 285967 - Vertical Panel on screen 2 interfere with window maximization.
Summary: Vertical Panel on screen 2 interfere with window maximization.
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: multi-screen (show other bugs)
Version: 4.7.3
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 243732 286161 287349 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-11-07 09:23 UTC by Antonio Orefice
Modified: 2011-11-25 12:58 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.8


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Antonio Orefice 2011-11-07 09:23:49 UTC
Version:           4.7.3 (using KDE 4.7.3) 
OS:                Linux

Here is my layout:

+-------+  +-------+
|P      |  |       |
|P  2   |  |   1   |
|P      |  |       |
+-------+  +PPPPPPP+

I'm using a vertical panel on left screen 2 and an horizontal one on right screen 1.
Both panels are always visible and windows cannot cover them.


Reproducible: Always

Steps to Reproduce:
- Have a multihead (twinview?) layout as specified.
- Open dolphin on screen 2
- Maximize dolphin
- close dolphin while maximized
- open dolphin on screen 2 again
- unmaximize it resize it to a lower width
- Drag the dolphin window to screen 1
- ** See that dolphin window width is automatically resized to screen 1 width
- Resize it again and lower the dolphin window width again
- Close dolphin
- open it again
- ** See that window size is wide as the screen, it has not been saved



Actual Results:  
- ** See that dolphin window width is automatically resized to screen 1 width
- ** See that window size is wide as the screen, it has not been saved

Expected Results:  
* To not resize the window automatically when it changes screen
* To correctly save the window width on closing

Workaround 1:
Open $HOME/.kde4/share/config/dolphinrc
See that under [MainWindow] section there is the line:
Width 1280=1281
Delete it and save.

Workaround 2:
Never close a maximized window if you're using a similar layout :(
Comment 1 Antonio Orefice 2011-11-07 09:58:30 UTC
Waiting for a proper fix, i run this in background:
#!/bin/bash
while true ; do
    echo "fixing..."
    find /$HOME/.kde4/share/config/*rc -type f -exec sed -i 's/Width 1280=1281/Width 1280=1200/' {} \;
    echo "done..."
    sleep 20
done

#(You have change the width(s) accordingly to your resolution.)

Setting 1280=1200 makes every window which is maximized back to the size of 1200px, this works because my leftmost panel is narrower than 80px
Comment 2 Thomas Lübking 2011-11-07 13:16:23 UTC
sounds like a dupe of bug #183694

a) "See that dolphin window width is automatically resized to screen 1 width" this should not happen at all for not maximized windows - can you please run
"xprop| grep -iA3 wm_state" in konsole and when the cursor turns a cross, click the window you intend to drag over? Then post the output.

b) "See that window size is wide as the screen, it has not been saved" - this is matter of the client, kwin doesn't store the size.

1. Does it only happen with dolphin?
2. Dolphin and some other apps are "special" in this regard.
   => ensure there's _no_ kwrite open, run "killall kwrite" (gets rid of all possible instances), then "kwrite&" (runs a new kwrite) use that for your checks, don't use it to open a(nother) file before.
Comment 3 Antonio Orefice 2011-11-07 13:37:31 UTC
What i did:
open kate on leftmost screen, maximized it, closed it, reopened on leftmost screen, demaximized and set W and H to 1/2 screen.
then run xprop on the window which is *NOT* maximized:
--
WM_STATE(WM_STATE):
                window state: Normal
                icon window: 0x0
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 94372083
--
_NET_WM_STATE(ATOM) = _NET_WM_STATE_MAXIMIZED_HORZ
_KDE_NET_WM_USER_CREATION_TIME(CARDINAL) = 9352842
_NET_WM_ICON(CARDINAL) =        Icon (16 x 16):
--

...happens on kwrite too.
Comment 4 Thomas Lübking 2011-11-07 13:47:58 UTC
This explains the wrong size storage in the config file, how do you maximize/restore the window?
Titlebar button? Resize? Quick maximization?

Rightclicking the maximize/restore button should toggle the horizontal maximization.
a) what happens? (does it visually horizontally demaximize)
b) can you unset the _NET_WM_STATE_MAXIMIZED_HORZ this way?
c) does ultimately the issue disappear by fixing this?
Comment 5 Antonio Orefice 2011-11-07 13:58:39 UTC
...It seems that kwin goes crazy because of the leftomost panel, anyway:

Maximizing/restoring method seems to make no difference (tried maximize button, drag to border and double click on titlebar)

a) Yes, it visually demaximize
b) xprop reports that the window is not maximized anymore
c) it fixes the issue all the way.
Comment 6 Antonio Orefice 2011-11-07 14:01:21 UTC
(here's another bug i submitted some time ago, maybe it is related, i can't say)
https://bugs.kde.org/show_bug.cgi?id=243732
Comment 7 Antonio Orefice 2011-11-08 11:17:33 UTC
Your tip solved the same problem, it occured even if differend "heads" had different resolutions:
https://bbs.archlinux.org/viewtopic.php?id=129824
Comment 8 Thomas Lübking 2011-11-08 11:37:35 UTC
I've so far failed to reproduce this, therefore i need to know about the exact multiscreen setup (i've only tried nvidia's twinview which is similar to xrandr multiscreen)

Do you use
- nvidia twinview
- xrandr
- two X screens w/  xinerama
- two X screens w/o xinerama

- Is the horizontal bottom panel any important? (in doubt just set it autohiding or allow windows to cover it)
- I do understand correctly that the vertical panel is mandatory? Eg. changing it as suggested above for the bottom panel would remove the issue?
- do you allow maximized windows to have a border (kcmshell4 kwinoptions) and what about quick maximization and tiling (kcmshell4 kwinscreenedges)
Comment 9 Antonio Orefice 2011-11-08 12:48:15 UTC
I use nvidia twinview too, so no xrandr nor xinerama.

Allowing maximized applications to have a border does not solve the fact that the window open in horizontal maximized state even if it was closed totally maximized, but at least it allows to resize by dragging borders, that way the window exits from horizontally maximized state.

About quickmaximization, there's nothing to say, when a window appears in the state of horizontally maximized, you can freely drag over the screen, it stays in that state.

The vertical panel is *not* important, i'm sorry about that, my fault.
(read on, maybe it is important in vertically spanned display)

if two heads has the same resolution, the horizontal panel 
on right screen is mandatory to reproduce the bug,
in fact, if i set it to autohide, all works as expected.
If it is always visible, see what happens:

-i open kwrite on left screen
-maximize kwrite and get window state by xprop:
  _NET_WM_STATE(ATOM) = _NET_WM_STATE_MAXIMIZED_VERT,
  _NET_WM_STATE_MAXIMIZED_HORZ
-close kwrite
-reopen kwrite on left screen and get state:
  _NET_WM_STATE(ATOM) = _NET_WM_STATE_MAXIMIZED_HORZ

...it is no more vertical maximized, and i think that's because of the bottom
panel on right screen, in fact there's blank space at the bottom, (that space
is the same of bottom panel).

So kwin just fails to restore the window correctly, maybe not considering the fact that the panel does NOT spans over the left too?

->the same happens with no panels at all with the left screen to 1280x1024
->and the right one to 1280x960

All this happens only when closing/reopening the application; everything works as it should if i maximize/restore it repeatedly whithout closing the window.

To summarize, i think we're talking about 3 bugs here:
The first is that if two screens are spanned in horizontal and one head has an "always visible" horizontal panel (/or less available lines), when the window is opened again on the head without panel (/or with more available lines), kwin fails, and reserve that space in that head too, leaving blank space.
Oviously, this makes that window no more vertical maximized, but it is still horizontally maximized. 

The second bug (a feature?) is about how kwin reacts when you click on the "restore" button in the titlebar or double click.
When i click the restore button i'd expect kwin to demaximize the window in both dimensions, but it doesn't, in fact it 'restores' the window to the previous state which is "horizontal maximized".

Third: if i manually resize a window by dragging the border or by alt+right mouse and that window maximized in just one dimension (H or V is the same) it stays maximized in that dimension.
A workaround for this is to allow window borders around maximized window. 


As a side note, there is another inconsistence:
if i rightclick on the task manager of a "just horizontally" maximized window, the "maximize" checkbox is checked.
if i rightclick on the titlebar of that window, the "maximize" checkbox is not.
Comment 10 Thomas Lübking 2011-11-09 09:43:03 UTC
*** Bug 286161 has been marked as a duplicate of this bug. ***
Comment 11 Steffen Schloenvoigt 2011-11-11 06:48:04 UTC
Hi, I'm the initiator of bug 286161 and Thomas asked there for the xprop output. Here it is:
WM_STATE(WM_STATE):
                window state: Normal
                icon window: 0x0
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 113246809
--
_NET_WM_STATE(ATOM) = _NET_WM_STATE_MAXIMIZED_HORZ
_NET_WM_ICON(CARDINAL) =        Icon (16 x 16):
           ░░░░░░░░░    
          ░         ░  

This is, before moving the window and the window is NOT maximized horizontally (as one could assume when seeing that output)...

Best regards
Steffen
Comment 12 Steffen Schloenvoigt 2011-11-11 06:53:28 UTC
Oh and contrary to the other posters, I don't have a nvidia card.
Mine is an ATI Mobility Radeon X1400 and I'm using the default oss radeon drivers. Screens the internal TFT (LVDS) and an external HP w2207 (VGA-0) each with a resolution of 1680x1050. Screen setup is VGA-0 left of LVDS with a complete resolution of 3360x1050. Screens are setup through the KDE Display Settings which should mean xrandr if I'm correct.
Comment 13 Thomas Lübking 2011-11-11 13:55:38 UTC
Ok, i
a) can reproduce the issue now (it's *crucial* that the screens have the very same resolution, that's where i've failed so far)
b) have a good idea where it fails
c) noticed that the strut is on the wrong (left, /not/ primary) screen - that means the panel is on the right screen, but maximized windows cover the entire area there and leave place for the panle on the left one instead (anybody else with this?)
Comment 14 Thomas Lübking 2011-11-12 21:01:00 UTC
https://git.reviewboard.kde.org/r/103121/ should do, confirmation would be nice, but i'm quite confident it does =)
Comment 15 Thomas Lübking 2011-11-13 17:53:45 UTC
Git commit c64f22c20ba8947ff1259ad2b3d14037f671f7d7 by Thomas Lübking.
Committed on 12/11/2011 at 21:39.
Pushed by luebking into branch 'master'.

Move maximization when managing client

Maximization of oversized windows must happen BEFORE keepInArea() is called
because that will through resizeWithChecks() lead to an artificial constrainment
to the WorkArea which is the combination of all screens minus all struts
this fails if only one screen struts and as a result the window is no more
bigger than FullArea which is used as maximization enforcing condition.
(Maximization must also happen AFTER placement, because otherwise the window
will eventually be maximized to the wrong MaximizeArea - Screens(s) - (local) struts
depending on xinerama settings)

BUG:285967
CCBUG:286146
CCBUG:183694

FIXED-IN:4.8

M  +32   -20   kwin/manage.cpp

http://commits.kde.org/kde-workspace/c64f22c20ba8947ff1259ad2b3d14037f671f7d7
Comment 16 Antonio Orefice 2011-11-15 07:42:10 UTC
Thank you very much for fixing this
Comment 17 tony 2011-11-15 07:43:54 UTC
*** Bug 243732 has been marked as a duplicate of this bug. ***
Comment 18 Thomas Lübking 2011-11-25 12:58:25 UTC
*** Bug 287349 has been marked as a duplicate of this bug. ***