Bug 286146 - Window size/geometry not always restored on TwinView
Summary: Window size/geometry not always restored on TwinView
Status: REPORTED
Alias: None
Product: frameworks-kxmlgui
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: kdelibs bugs
URL: https://git.reviewboard.kde.org/r/114...
Keywords:
: 309521 319866 326716 338433 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-11-08 23:12 UTC by Valdas
Modified: 2022-11-06 18:26 UTC (History)
15 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
My xorg.conf file, generated by nvidia-settings (1.72 KB, text/plain)
2011-11-10 17:48 UTC, Valdas
Details
QDesktopWidget's opinion on screensizes (344 bytes, text/x-c++src)
2011-11-19 23:15 UTC, Thomas Lübking
Details
My "kwinrulesrc" file (368 bytes, text/plain)
2012-01-26 19:26 UTC, Valdas
Details
"kwrinrulesrc" from fresh accaunt (165 bytes, text/plain)
2012-01-26 22:17 UTC, Valdas
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Valdas 2011-11-08 23:12:12 UTC
Version:           unspecified (using KDE 4.7.3) 
OS:                Linux

In KDE version pre 4.7.2 window of started app appears in position and size same as when they was closed. After KDE update windows of all applications appears in default position - top-left of screen and default size.

Reproducible: Always

Steps to Reproduce:
For example start Kate, adjust window position to screen center and size, close, start - window appears in top-left corner in different size.
Or for example KCalc: every time it start in top-left corner of screen.
Same with Krusader, Muon software center,....
This is really annoying.

Actual Results:  
Opened windows does not remember their last state.

Expected Results:  
Opened windows must remember their last state.

As mentioned, this bug appears in KDE versions >=4.7.2
Comment 1 Thomas Lübking 2011-11-08 23:26:13 UTC
This is unlikely a kwin issue.

Clients store and restore their sizes themselves (or not) - kde applications in ~/.kde/share/config - check eg. the "[MainWindow]" section in katerc.
Ensure you have write permissions on those files - in doubt try a fresh account.

The position is set by kwin unless the client demands one. There are several placement policies in the last tab of "kcmshell4 kwinoptions" - one of them is "zero-cornered" which matches your observations.
If the placement policies have no impact you can use "kcmshell4 kwinrules" to force kwin to "ignore requested geometry".
If setting such rule for a window "fixes" the client actually demanded the position.

If it only affects KDE applications, try another style, esp. if you use the translucency features of bespin/qtcurve/oxygen
Comment 2 Valdas 2011-11-09 19:25:35 UTC
 Yes, I have write permissions to config files of apps. I tested newly created account - same result. I tried to change "Placement policy" from "Smart" to other - windows obey it.
 After analyzing "katerc" and other rc files I learned that many applications not store option of position of window.
 Also I found that size of window is remembered but not always. After further investigation I realize that "not crucial factor to My mind" is crucial: it is somehow related to TwinView (I purchased second monitor around 4.7.2 release date :) ) that I use - window size is remembered only if before closing window it was placed in another monitor.

I should open new bug report? Which section and component I should relate to?
Comment 3 Thomas Lübking 2011-11-09 20:51:11 UTC
Applications usually don't manage the position, but only the size. That is ok.
It's no necessary to open a new bug, i've altered this one (at least wrong position is a kwin issue, but the topleft corner is a failsafe when the window attempts to show up out of the screen and also kwin restricts the window size in that regard)

- is this related to session management (ie. only affects re-login autostarting applications)?
- Is it _really_ TwinView (nvidia prop. xrandr multiscreen alternative)?
- Do the screens have different resolutions?
- How are the screen set up? (overlapping, ie. "clone", vertical/horizontal stack)
- Does it matter on which screen the application is opened?
- Do you open applications on the same screen as you close them?
- what is checked in "kcmshell4 xinerama"?
Comment 4 Valdas 2011-11-10 17:46:56 UTC
 I use Nvidia propertary drivers v280.13.
 I sure that I use twinView: in "nvidia-settings" -> "X Server Display Configuration" -> "configuration" states "TwinView". I use two monitors, second monitor extends desktop space (horizontal stack):
 - laptop monitor is main ("primary" in nvidia-settings, "1" in "kcmshell4 xinerama", resolution is 1440x900, position is "Absolute" +1366+0 (from nvidia-settings);
 - second monitor is on left of main laptop monitor, resolution is smaller 1366x768, position is "Absolute" +0+0.

 I tested session restore: position and size of window (Kate) is always restored correctly, no matter on which main or secondary monitor I left open window before log-off.

 Newly opened windows is always positioned in top left corner of monitor:
 - if desktop is empty then windows appears in monitor in which that app is opened (I use Alt+F2 command window [Krunner ?]) [pff.. not always];
 - if desktop contains some windows then new window appears in monitor with active window (sometimes window appears bottom-left, or in other corner).

 I found that size of window is saved only when window was in monitor which coordinates is +0+0 (tried reverse arrangement: main laptop monitor is in +0+0, and secondary is on right).

 If I remove second monitor (in nvidia-settings, without save to xorg.conf, without restart - which I think is not necessary), then size of windows is saved, but windows always opens in top-left corner.

 Non KDE apps (f.e. eagle or firefox) their position/size/state restores correctly

 In "kcmshell4 xinerama":
 - all checkboxes in Multimonitor section is checked;
 - "monitor 1" (which is main laptop) x:1366, y:0, w:1400, h:900;
 - "monitor 2" (secondary on left) x:0, y:0, w:1366, h:768;
 - "show unmanaged windows on:" - "monitor 1".

 Also I attached my "xorg.conf" file.
Comment 5 Valdas 2011-11-10 17:48:34 UTC
Created attachment 65486 [details]
My xorg.conf file, generated by nvidia-settings
Comment 6 Thomas Lübking 2011-11-10 19:28:15 UTC
(In reply to comment #4)
>  Non KDE apps (f.e. eagle or firefox) their position/size/state restores
> correctly

Quick check to rule it out: please try whether "kwrite --style plastique" works as expected.

Also, have you looked up the stored geometries for the applications in the [MainWindow] section of their config files?
What do they look like?
Is your virtual horizontal resolution present or are there values for 1440, resp. 1366 (or both)

What's your distributor or do you compile yourself?
Do you recall the kde version you've used before?
Comment 7 Thomas Lübking 2011-11-10 19:35:20 UTC
Oh, forgot: please try another placement than smart (preferebly "centered") so we can figure whether this is a miscalculation or a fix-invalid-geometry case.

Last: you can have the active monitor follow the pointer (focus tab in "kcmshell4 kwinoptions")
Comment 8 Valdas 2011-11-10 21:13:20 UTC
 I tried to open Kate with command "kate --style plastique": same behaviour.

 I analyzed dynamics of "MainWindow" section of applications (Kate and Arc): there is two "Width" and two "Height" config lines, f.e. "Height 768=365" and "Height 900=204". As I understand, each line is bond with separate monitor: if I close window in secondary monitor (+0+0) then changes "Height 768=..." (values not excess max), if in main monitor (+1440+0) - then second line changes.
 Seems size is saved, but it restores only from monitor +0+0 configuration line.

 I installed Kubuntu from official site. KDE is constantly updated from repository "http://ppa.launchpad.net/kubuntu-ppa/ppa/ubuntu" (via package manager KpackageKit (previously) or Muon (now), so I used all official releases.

 I tired "Centered" placement policy - same behaviour (except that window appears in center).

 "Active monitor follow the pointer" fixes nasty "window opens in monitor (+0+0) which are turned off" situation. Thanks.
Comment 9 Thomas Lübking 2011-11-10 22:32:46 UTC
"Windows opened in monitors which are turned off" like by
a) power button? (you should turn it off via nvidia-settings to relax the GPU)
b) nvidia-settings?

"centered" centers windows but "smart" always places them on the top left corner?
(or was only the size affected)
Comment 10 Valdas 2011-11-10 23:37:40 UTC
 "Windows opened in monitors which are turned off" I meant same monitor "+0+0" which is not main. When I turn off secondary monitor then desktop space stays same even pc is started with detached secondary monitor.
 I power-on secondary monitor only when I need him (I save el. power :) ). This is simpler than launch app and configure settings then toggle switch - time and attention consuming. I don't think that soft turn-off by switch on monitor (stand-by) stresses electric circuitry or GPU "brain" (stresses?).

 Behaviour to open window in "+0+0" monitor (which is not main) I experience since when I installed second monitor (in midsummer).

  When policy is changed to "Centered" then changes only behaviour of window placement: from top-left (as with "Smart" policy) to center of monitor. Window size behaviour stays same: size "saved" only when window is closed in "+0+0" monitor.
Comment 11 Valdas 2011-11-11 13:45:15 UTC
 I tested Krusader.
 Closed in normal state (not maximized):
 - size and position is correctly restored, no matter in which monitor it is closed: f.e. if window previously was in main monitor, and I open it in secondary monitor (which contains some active window, mouse makes active monitor ["active follow mouse" rule]) then window opens in main monitor in same position and size as before closing.
 Closed in maximized state:
 - it opens in monitor which are currently active;
 - if it opens in monitor "+0+0" then their state is "maximized" as should be;
 - if it opens in monitor "+1366+0" then it opens not in maximized but always in previously saved size of "normal" state (seems from old save point in monitor +0+0, I not yet figured how to trigger to change that "old saved size") and in top-left corner.

 I also I tested Kate: it correctly saves and opens in maximized state no matter in which monitor it closes or opens, it always opens in active monitor.

 If I turn of desktop effects (Shift+Alt+F12) then Kate shows to me additional "trick": if before close Kate was in not in maximized it always opens maximized horizontally. Tired log-off log-on - same result. Btw if change Kate's shape to other than maximized horizontaly and move window to other monitor then when I drop window it reshapes to maximized horizontally. If I turn on efects or swith style that "trick" remains. Kate stops doing that if I remove katerc file. uh... cannot reproduce this anymore...

 Ok. So I tested effects off, effects off and style "Plastique" (global), effects on and style "Plastique", every time I logged off and logged on. Symptoms of windows of Kate ("healed") and Ark not changes.
Comment 12 Thomas Lübking 2011-11-11 14:03:16 UTC
FYI: it's likely bug #285967 (which itself is likely a dupe of bug #183694) - please hook on there for status updates.
Comment 13 Thomas Lübking 2011-11-12 20:59:46 UTC
please check (if you can) whether https://git.reviewboard.kde.org/r/103121/ fixes it for you, thanks
Comment 14 Valdas 2011-11-13 15:21:10 UTC
 I installed Kubuntu in to VirtualBox and updated to latest 4.7.3 (from official repositories). In virtual Kubuntu I configured two monitors - second monitor is at main monitor left (main monitor have an absolute offset), size of second monitor is smaller that main monitor, second monitor extends desktop area.
 I can reproduce all above mentioned behaviour with Kate:
 - size and "maximized" state is saved only if window is closed in "+0+0" monitor;
 - position of newly opened window is always left-top of monitor;
 - if desktop has no windows then new windows opens in secondary monitor - Alt+F2 command I invoked in main monitor and configuration is "open unmanaged windows in main monitor".

 Mow I ready to test that fix. Would be good if there was a repository ("daily snapshot" I think) with packages of compiled (binary) files so I can simply add that repo, update and test.
Comment 15 Thomas Lübking 2011-11-13 17:08:33 UTC
> Would be good if there was a repository ("daily snapshot" I think) with 
> packages of compiled (binary) files so I can simply add
> that repo, update and test.

You're offering a free build server (HW + transfer)?
:-P

You btw. still would have to compile yourself since the patch has yet not been committed.
Comment 16 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 17 ml 2011-11-19 20:00:29 UTC
(In reply to comment #16)
> 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


Tried your patch in kde-4.7 - windows still starts with wrong size and position.
Maybe you have it working with 2 monitors with identical resolutions, but I have it broken since a51735beb74a0712d1ba1a097369ed07d08b29e0 commit "fix KMainWindow size storing with multiple monitors" - and every time before compiling kdelibs I forced to revert this commit.
Comment 18 Thomas Lübking 2011-11-19 21:31:48 UTC
@ml
This bug was only cc'd because of comment #11 ;-)

However the patch seems correct both aspects, so the issue must be in a third place.

Do you have "kcmshell4 xinerama", "Enable multiple monitor maximize support" UNchecked?

Otherwise, please with an application of your choice (eg. kwrite) 
a) Open _one_ instance (to rule out every other mess)
b) remove the geometries in the MainWindow groups (eg. in ~/.kde/share/config/kwriterc)
c) maximize the window
d) close the window
e) inspect the MainWindow group of that config file. What geometries have been added with what values. How are they related to your screen setup.
Comment 19 ml 2011-11-19 22:53:39 UTC
"Enable multiple monitor maximize support" checked.

Correct geometries in ~/.kde/share/config/kwriterc saves only I close window on second smaller monitor which have position +0+0(left side), and then restores correctly on both monitors, but if I close window on first monitor +1280+0 it restores size which was remembered at second monitor.
Comment 20 Thomas Lübking 2011-11-19 23:15:08 UTC
Created attachment 65853 [details]
QDesktopWidget's opinion on screensizes

I've seen such interim (while debugging the other bug) and the kephal sources have a comment that QDesktopWidget can get confused about changing geometries (therefore QDesktopWidget is not used by kephal, ie. kwin & plasma but still by stuff in kdelibs which does not link kephal - don't ask)

Can you compile and run the attached test? (it has compile instructions in the first line)
Comment 21 ml 2011-11-19 23:28:30 UTC
./screensize 
QRect(0,0 1280x1024) 
QRect(1280,0 1920x1080)
Comment 22 Thomas Lübking 2011-11-20 00:22:00 UTC
Then what sizes are stored when you close it on the big screen?
Comment 23 ml 2011-11-20 12:39:03 UTC
Big screen
cat .kde4/share/config/katerc |grep -A 12 "\[MainWindow\]"
[MainWindow]
Height 1080=731
State=AAAA/wAAAAD9AAAAAAAAA2oAAAKqAAAABAAAAAQAAAAIAAAACPwAAAABAAAAAgAAAAEAAAAWAG0AYQBpAG4AVABvAG8AbABCAGEAcgEAAAAAAAADGgAAAAAAAAAA
ToolBarsMovable=Disabled
Width 1920=874

[MainWindow0]
Height 1080=731

Change size and close:
cat .kde4/share/config/katerc |grep -A 12 "\[MainWindow\]"
[MainWindow]
Height 1080=950
State=AAAA/wAAAAD9AAAAAAAAA7sAAAOFAAAABAAAAAQAAAAIAAAACPwAAAABAAAAAgAAAAEAAAAWAG0AYQBpAG4AVABvAG8AbABCAGEAcgEAAAAAAAADGgAAAAAAAAAA
ToolBarsMovable=Disabled
Width 1920=955

[MainWindow0]
Height 1080=950

Start again, size is not that should be, close:

cat .kde4/share/config/katerc |grep -A 12 "\[MainWindow\]"
[MainWindow]
Height 1080=166
State=AAAA/wAAAAD9AAAAAAAAA7sAAAOFAAAABAAAAAQAAAAIAAAACPwAAAABAAAAAgAAAAEAAAAWAG0AYQBpAG4AVABvAG8AbABCAGEAcgEAAAAAAAADGgAAAAAAAAAA
ToolBarsMovable=Disabled
Width 1920=794

[MainWindow0]
Height 1080=166
Comment 24 Thomas Lübking 2011-11-20 15:07:36 UTC
a) the client apparently picks the proper dimensions when storing it's geometry
-> it's not that QDesktopWidget would be wrong on window dimensions. Also i frankly have to doubt that this could be related to the mentioned commit at all (are you sure that reverting "this" and not "TO this" commit "fixes" it for you?)

b) i assume you closed @ ~955x950 and the window opened @ ~794x166, correct?
Any panels on any screen? (and their location/dimension)

c) does this only affect kate (or other kuniqueapplication applications) or also (please test with) eg. kwrite (do NOT use the "open" or "new" dialog to open new windows to ensure the client doesn't mess up with it's windows internally)
Comment 25 ml 2011-11-20 15:53:36 UTC
a) I usually revert this commit by git revert a51735beb74a0712d1ba1a097369ed07d08b29e0.
b)Correct, I have one panel by each screen.
c) It's affect kate, dolphin, konsole,ktorrent,kmail, akregator and allmost all kde applications.
Comment 26 ml 2011-11-26 18:42:48 UTC
Thomas Lübking , please look at this bug 284207, so I'm not the only who has this problem.
Comment 27 Thomas Lübking 2011-11-26 20:16:51 UTC
a) i didn't question the issue exists, did I
b) this is _for sure_ not this bug because Valdas suggested his would be a maximized windows only problem, therefore is suggest to rather attach to, stress and support that bug (by posting the intel you gathered here over there) - picking the wrong geometry to restore is not an issue with the window manager, so your bug is completely OT here.

on a last note: "kate, dolphin, konsole,ktorrent,kmail, akregator" as well as konqueror (on bug 284207 and at least if called through kfmclient) all only run in one process by default - this could really matter.
If you cannot reproduce it with eg. kwrite (which does also NOT spawn new instances if you use the "open" menu but should if you call it as usual, like through krunner or from konsole etc.) we'd have an important hook.
Comment 28 Valdas 2012-01-26 18:35:41 UTC
 I updated KDE to v4.8.00. I don't know if patch is applied, but bug is still there. F.e. kwrite: window always opens in top-left position of active screen, maximized state is saved only if window was in secondary screen.
Comment 29 Thomas Lübking 2012-01-26 18:49:32 UTC
the patch is in and fixes the other bug.
this bug was only cc'd for "smells related"
did i btw. ask whether you've set up any window rules in ~/.kde/share/config/kwinrulesrc ? (forgetting the size is one thing but that topleft thing confuses me ...)
Comment 30 Valdas 2012-01-26 19:26:06 UTC
Created attachment 68203 [details]
My "kwinrulesrc" file
Comment 31 Thomas Lübking 2012-01-26 19:44:15 UTC
Not, it's not ;-)

No idea what that's supposed to be, but it's no kwinrulesrc - it's not even a halfwise legal ini file. If you've more stuff like that around in your config path, prepare for all kinds of breaks.

Does the issue also occur with a fresh user account?
(and if not, is there a ~/.kde/share/config/kwinrulesrc and what does it look like?)
Comment 32 Valdas 2012-01-26 22:17:32 UTC
Created attachment 68211 [details]
"kwrinrulesrc" from fresh accaunt

 I tried with freshly created new user: same behaviour. I must make correction:  "always top-left" must corrected to "always default position (or something like that)", because if top-left is occupied by some window then new window appears in bottom-right or in other position.
Comment 33 Thomas Lübking 2012-01-26 22:51:57 UTC
Ok, that looks more like the normal kwinrulesrc.

Since the placement is no issue, can you please attach the config of a window which restores the wrong size:

a) after closing the window, but before re-opening it
b) after reopening it

(i guess kwirte makes a good testcase - you can inspect the config before and scratch any private data like last file paths etc. Only the geometry storage is actually relevant, but given the first kwinrulesrc attachment, i wonder whether config writing is broken on your system)

The setup of comment #4 is still valid?
Comment 34 Thomas Lübking 2012-01-26 22:59:48 UTC
ps:
looking at the commit ml mentioned, i guess i know what happens (just not why) - can anyone of you inject some simple debug patch into kdelibs/kdeui/widgets/kmainwindow.cpp?
Comment 35 Valdas 2012-01-27 00:40:00 UTC
 Yes, setup of comment #4 is still valid. 

 I tested with new user:
 - opened kwrite and placed window in center of secondary screen,
 - closed window and then inspected kwriterc file,
 - opened kwrite and then inspected kwriterc.
 In both inspections I found no changes, section always looks same:

[MainWindow]
Height 768=485
Height 900=485
State=AAAA/wAAAAD9AAAAAAAAA4oAAAGgAAAABAAAAAQAAAAIAAAACPwAAAABAAAAAgAAAAEAAAAWAG0AYQBpAG4AVABvAG8AbABCAGEAcgEAAAAA/////wAAAAAAAAAA
ToolBarsMovable=Disabled
Width 1366=906
Width 1440=906
Comment 36 Thomas Lübking 2012-01-27 01:01:02 UTC
Stored size is unconditionally 906x485 - does that match the restored window size?
If not, what is the restored window size?
Comment 37 Valdas 2012-01-27 01:37:03 UTC
 Visually it matches. For more precise values I looked in window special properties (where window rules can be set) - 910x512. Maybe these values for window with borders, shadows?
Comment 38 Thomas Lübking 2012-01-27 01:56:20 UTC
It's +/- the decoration (titlebar & frame)

So... what size should it have been then? (Ie what size did you leave it, or in other words: where is the bug?)
Comment 39 Valdas 2012-07-27 15:10:05 UTC
Hello,

 now I able to help better hunt that bug - finally, I compiled KDE and QT from sources. I used "build-tool" and "kde-trunk-recipe". KDE was compiled in "Fedora 17" 64bit (with Gnome), which was in VirtualBox.
 In compiled KDE I configured two monitors: second monitor was smaller and "Left of" first monitor. "Primary output" was first (bigger) monitor.
 Bug still there: I started KWrite, maximized it in first (bigger) monitor, then closed. When started again Kwrite appears in second (smaller, on left) monitor in "normal" window state. Or new behavior: no matter where KWrite was placed and what window state was before Close, it always opens in primary (bigger) monitor in maximized state (not updating settings?).
Comment 40 Thomas Lübking 2012-07-27 18:04:38 UTC
To give you a re-cap:
------------
The clients in general open on the active screen unless they demand different and i doubt that information is store with KMainWindow.
The active screen can be configured to follow the mouse ("kcmshell4 kwinfocus")
Rule of thumb is that "active screen is where you last acted" - so if you launch kwrite from the primary screen, it will always show up there (unless you force it somewhere else - there's no screen rule, but you can "apply initially" a fixed position on the desired screen. They combine their dimensions, so if you've 1280x1024 on the left and 1920x1200 on the right, "600,300" is a valid position on the left screen and 1600x300 a valid position on the right one)

When the (KMainWindow) client closes it should store its size in its config - depending on the screen geometry!
Ie. if you've two screens of different sizes and close kwrite on one screen and restart it on another, *it will NOT have the dimensions of the just closed window but of the window last time closed on /that/ screen.

If the window size coveres the ddesktop geometry, KWin will set it maximized, because KMainWindow does not store that state.

For kwrite there's more.
If you click the "new" button, you don't get another kwrite instance, but just another window in the same process and afaics that uses the same last stored geometry as its oldest ancestor.

Ie: open kwrite, has w1xh1 px -> click new -> resize new window to w2xh2 px -> close new window -> click new -> opens at w1xh1 px despite being closed at w2xh2

----

You've not answered the question about how what you expected to see differed from what you ultimately saw.
If you just experience the above mentioned, that's no bug and you'll have to file a wish against KMainWindow
Comment 41 Martin Flöser 2013-01-07 17:04:13 UTC
*** Bug 309521 has been marked as a duplicate of this bug. ***
Comment 42 Davide 2013-05-24 11:57:23 UTC
I was able to reproduce this only when the primary monitor is not on 0,0 coordinates (for example with the secondary monitor on the left), instead if I set the secondary monitor on the right everything works fine
Comment 43 Thomas Lübking 2013-05-30 21:01:30 UTC
*** Bug 319866 has been marked as a duplicate of this bug. ***
Comment 44 Thomas Lübking 2013-12-15 11:42:09 UTC
*** Bug 326716 has been marked as a duplicate of this bug. ***
Comment 45 Alex 2013-12-28 19:37:03 UTC
(In reply to comment #42)
> I was able to reproduce this only when the primary monitor is not on 0,0
> coordinates (for example with the secondary monitor on the left), instead if
> I set the secondary monitor on the right everything works fine

exactly the same here (with Ubuntu 13.10 , KDE 4.11.3 )
thx for the workaround with the monitor on the right (even if this is annoying, too ;) )

oddly, I had no problems with Linux Mint 15 (KDE 4.10.x)
Comment 46 Thomas Lübking 2013-12-28 19:50:02 UTC
fixing patch against kdelibs, in case you compile yourself:
https://git.reviewboard.kde.org/r/114484/
Comment 47 Alex 2013-12-30 21:26:29 UTC
I don't always compile basic system libs, but when I do, I crash my whole system ;)
I hope it will be included in the next updates.

Thank you for fixing the bug 
and a Happy New Year!
Comment 48 numkem 2014-01-29 16:38:35 UTC
Do we know if this patch has been accepted and merged to kdelibs?

It's very annoying for me and I hope to see it in 4.12.2!!!
Comment 49 Thomas Lübking 2014-01-29 17:53:58 UTC
The review is not marked as submitted and this bug will receive a message when it is.
Comment 50 matthias sweertvaegher 2014-08-07 20:31:08 UTC
This bug has been annoying me for years and although I am to blame for only reporting it now, I am very glad to see you guys have already been working at it dauntlessly (also for years, so it seems :)). Thomas, you have my eternal gratitude if this ever gets released ;)
Anyway, does the patch need any more testing or is it just awaiting approval..? (also, I don't understand why this bug has status "unconfirmed")

again, thanks
matthias
Comment 51 Thomas Lübking 2014-08-08 11:54:39 UTC
The "bug" is pretty much as old as KDE ;-)
Code was simply multiscreen unaware (pre xinerama, probably) than and was never really made capable of it in this regard. (the "pre 4.7.2" claim is not reliable in this regard, must be "random" incidence)

The patch you find on reviewboard is ok, it will work.
However, I doubt such fix will actually ever make it into KDE4 but KF5 only (without the negative number fix, I assume) - you'd have to apply it locally (and recompile kdelibs)
Comment 52 Thomas Lübking 2014-08-08 11:58:05 UTC
PS: the bug is not tagged confirmed since it's actually invalid.
KWin - or any WM - should not, did not, does not and will not ever maintain window geometries across client destructions.

For KMainWindow I've seen multiple complaints and there's probably some matching bugreport, but I could not find it.
Comment 53 matthias sweertvaegher 2014-08-11 18:11:45 UTC
thanks for your explanation, Thomas.
Yeah, I guess I noticed the bug for the first time when I started using a dual head setup in 2009.
I'll try compiling kdelibs myself, not sure I'll be getting there but I heard things got easier these days ;)

If I understand you well, this bug is unconfirmed because it is filed against the wrong product? Is it possible to migrate this bug to the correct product so it doesn't get out of sight for KF5? I read KF5 and Plasma5 have had their first release. So a fix could be imminent? :]

cheers
Comment 54 matthias sweertvaegher 2014-08-12 19:21:05 UTC
okay.. so after a day of trying to compile an old version of kdelibs using kdesrc-build, it dawned on me that it was probably 100x easier to source install kdelibs package and then just download the kdelibs tarball for the correct version, apply patch and compile from there. lol! the important thing is I got a big fat patched .so in the end (54MB). I remedied this by "strip --strip-unneeded". Anyway, in order not to get too far off topic, I shared the .so file in case anyone can use it too: 
https://drive.google.com/file/d/0BxPHYs2NR_wQZ01nYTVzMmpEVjA/edit?usp=sharing

it's the libkdeui.so.5.10.5 (yes, that's a 5 in front) which is suitable for kde sc 4.10.5 which happens to be the stable version in opensuse 12.3. you can replace it in /usr/lib64. In a virtual machine I tried a kde sc 4.11.5 too which is the stable version in opensuse 13.1 but no luck so far.

this patch combined with focus follows mouse and window placement under cursor finally scratched my itch. Thanks again to everyone involved.
Comment 55 Thomas Lübking 2014-08-12 20:11:42 UTC
(In reply to matthias sweertvaegher from comment #53)
> If I understand you well, this bug is unconfirmed because it is filed
> against the wrong product?

Yesno. Since the bug is in the client, every client has to be fixed.
For most KDE applications the fix to KMainWindow in (former) kdelibs will cover them, but this had no impact on eg. Firefox - and afaik Muon is plain Qt as well.

> I read KF5 and Plasma5 have had their first release. So a fix could be imminent? :]

The code got moved around and at least there's a special handling of maxmized windows, but it seems to still operate on the single screen geometry to choose a size to restore, what will make it run into the problems listed in the review.

-> I'll prepare another patch (there seem other efforts in the new code, got to read sense into it first ;-)
Comment 56 matthias sweertvaegher 2014-08-13 07:25:24 UTC
(In reply to Thomas Lübking from comment #55)

> Yesno. Since the bug is in the client, every client has to be fixed.
> For most KDE applications the fix to KMainWindow in (former) kdelibs will
> cover them, but this had no impact on eg. Firefox - and afaik Muon is plain
> Qt as well.

thanks, i understand

> -> I'll prepare another patch (there seem other efforts in the new code, got
> to read sense into it first ;-)

thank you for following this up in KF5. Let us know if/when we should test something.

for anyone interested:
here is the libkdeui.so.5.11.5 file for kde sc 4.11.5 (stable version on opensuse 13.1)
https://drive.google.com/file/d/0BxPHYs2NR_wQNWhMbEl2WG9xZXM/edit?usp=sharing
Comment 57 Albert Astals Cid 2014-08-23 13:22:52 UTC
*** Bug 338433 has been marked as a duplicate of this bug. ***
Comment 58 gianogli 2016-01-07 00:27:22 UTC
I can confirm this bug.

I have 2 monitors with different resolutions and nvidia driver. When I reopen some kde software (kmail, system_setting, kwrite, ...) the previous window size/geometry is not restored.
I'm using debian testing with KDE Frameworks 5.16.0 and Qt 5.5.1.

Has anyone solved the problem?
Are there some news?
This bug is very annoying... :-(
Comment 59 Mike Goodwin 2016-06-03 00:42:46 UTC
I can confirm that this bug still persists in fedora, and I spent a great deal of time trying to figure out what was wrong. 

I am confirming on the basis that I previous thought that the window sizes would not save at all, until I saw this bug and attempted to move the window first to the leftmost screen (I have three screens in a horizontal configuration) 

When I drag the window to the leftmost screen _and only the leftmost_, it does in fact persist the window size. 

This is extremely annoying.
Comment 60 Mike Goodwin 2016-06-03 00:46:03 UTC
I can confirm that this bug still persists in fedora, and I spent a great deal of time trying to figure out what was wrong. 

I am confirming on the basis that I previous thought that the window sizes would not save at all, until I saw this bug and attempted to move the window first to the leftmost screen (I have three screens in a horizontal configuration) 

When I drag the window to the leftmost screen _and only the leftmost_, it does in fact persist the window size. 

This is extremely annoying. 

If at all useful, I also have a nvidia card if this turns out to be nvidia driver related, as bizarre as that sounds.
Comment 61 HD 2016-08-10 18:06:49 UTC
I'm using radeon and seem to be affected by the same bug. What's strange is the firefox window does kind of remember its size even on my secondary monitor (the one on the right on my dual monitor setup), but only as long as that size is smaller than the resolution of my first (the one on the left) monitor! My left monitor is smaller, which is why I noticed. 

In case it helps, I seem to be running plasmashell 5.6.5 and kwin 5.6.5, in debian stretch.
Comment 62 Thomas Lübking 2016-08-10 19:02:54 UTC
Firefox in particular is unrelated to this bug since it doesn't use kxmlgui or any KDE class.
Comment 63 HD 2016-08-10 19:19:02 UTC
Alright, sorry about comment pollution. Weird that it also seems connected to dual monitor setups though.

Other than that I can only confirm to have the same behavious as the others, then. Windows like dolphin's are only remembered if the resizing is done on the first (left) even when closing them on the second (right).  It *seems* like the middle of the window has to have crossed the monitor boundary for the size to be remembered.
Comment 64 Justin Zobel 2022-10-22 00:00:12 UTC
Thank you for reporting this bug in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version?

If you can reproduce the issue, please change the status to "CONFIRMED" when replying. Thank you!
Comment 65 Valdas 2022-10-22 05:19:54 UTC
Now I have two identical monitors connected (one through HDMI another through DP) and I don't experience this bug. 

Operating System: Arch Linux
KDE Plasma Version: 5.26.1
KDE Frameworks Version: 5.99.0
Qt Version: 5.15.6
Kernel Version: 5.15.74-1-lts (64-bit)
Graphics Platform: X11
Processors: 16 × AMD Ryzen 7 1700X Eight-Core Processor
Memory: 15.6 GiB of RAM
Graphics Processor: NVIDIA GeForce GTX 1080 Ti/PCIe/SSE2
Comment 66 Bug Janitor Service 2022-11-06 05:07:11 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 67 matthias sweertvaegher 2022-11-06 18:25:37 UTC
unfortunately, I can confirm this bug is still existing on dual head setups with different resolutions.

Here is my setup:
2 monitors nvidia twinview
- left 1920x1080 
- right 1680x1050 

opening and closing on the primary (left) monitor works properly but on the secondary monitor it fails to save the window geometry or restore it correctly. 
I made a video to demonstrate the problem (i'm constantly confused because irl my monitors are switched around =) but i wanted to leave the default order to rule that out as a cause):
https://www.youtube.com/watch?v=8pZJzKYHhN4