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
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
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?
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"?
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.
Created attachment 65486 [details] My xorg.conf file, generated by nvidia-settings
(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?
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")
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.
"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)
"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.
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.
FYI: it's likely bug #285967 (which itself is likely a dupe of bug #183694) - please hook on there for status updates.
please check (if you can) whether https://git.reviewboard.kde.org/r/103121/ fixes it for you, thanks
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.
> 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.
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
(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.
@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.
"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.
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)
./screensize QRect(0,0 1280x1024) QRect(1280,0 1920x1080)
Then what sizes are stored when you close it on the big screen?
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
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)
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.
Thomas Lübking , please look at this bug 284207, so I'm not the only who has this problem.
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.
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.
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 ...)
Created attachment 68203 [details] My "kwinrulesrc" file
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?)
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.
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?
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?
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
Stored size is unconditionally 906x485 - does that match the restored window size? If not, what is the restored window size?
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?
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?)
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?).
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
*** Bug 309521 has been marked as a duplicate of this bug. ***
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
*** Bug 319866 has been marked as a duplicate of this bug. ***
*** Bug 326716 has been marked as a duplicate of this bug. ***
(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)
fixing patch against kdelibs, in case you compile yourself: https://git.reviewboard.kde.org/r/114484/
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!
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!!!
The review is not marked as submitted and this bug will receive a message when it is.
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
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)
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.
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
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.
(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 ;-)
(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
*** Bug 338433 has been marked as a duplicate of this bug. ***
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... :-(
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.
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.
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.
Firefox in particular is unrelated to this bug since it doesn't use kxmlgui or any KDE class.
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.
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!
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
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!
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