KXMLGui saves window sizes already. It should also save window locations, presumably by storing the window's origin and the the id of the screen that the window was on when it closed.
Apparently this used to work, and the fact that it no longer does is a bug.
*** Bug 377283 has been marked as a duplicate of this bug. ***
*** Bug 363223 has been marked as a duplicate of this bug. ***
*** Bug 412885 has been marked as a duplicate of this bug. ***
*** Bug 326064 has been marked as a duplicate of this bug. ***
*** Bug 409675 has been marked as a duplicate of this bug. ***
*** Bug 424631 has been marked as a duplicate of this bug. ***
I'm working on this. I have a crude proof-of-concept working that needs a lot of refinement to handle cases like multi-screen (also save the screen that the window is on), multiple screen arrangements (save settings per screen arrangement) and multiple instances of the same app (cascade the new window? set no position at all and let the window manager decide? Something else?). See: - https://invent.kde.org/frameworks/kconfig/-/tree/work/ngraham/save-window-positions - https://invent.kde.org/frameworks/kxmlgui/-/tree/work/ngraham/save-window-positions and I will keep working on it, but help would of course be appreciated. :)
So I've run into a bit of a conceptual issue here. I've created new functions KWindowConfig::saveWindowPosition() and KWindowConfig::restoreWindowPosition() in KConfig. We can automatically save the position of apps' main windows by calling the new saveWindowPosition() function from kxmlgui in KMainWindow, but to save the position of *every* window, we'd need to add a new KWindowConfig::saveWindowPosition() function call to every individual KDE app that calls KWindowConfig::saveWindowSize() for sub-windows, dialog windows, settings windows, etc. grep shows 92 such instances throughout the KDE apps I have source checkouts for. So this would be possible and feels most conceptually correct, but it would be a lot of work and in practice the roll-out would probably take months or years. An alternative you be to make KWindowConfig::saveWindowSize() automatically save the window's position as well. This would provide the feature for free for basically all KDE apps that already save the sizes of their windows. However doing this would make the function name inaccurate, and would represent a behavioral change that might be undesirable. Perhaps there are apps that manually save their window positions, though this is speculative and theoretical. Though in practice those would probably be exceptions and we could make them stop manually saving window positions when we find them. The other alternative is to abandon this idea and put work into making KWin do it instead (Bug 15329), which would fix this issue for all KDE app windows as well as all other 3rd-party app windows as well. Apparently that will eventually be possible on Wayland once some protocol is merged upstream, but we don't have enough information on X11 to do it. However perhaps that's something that can be overcome. If I had a nickel for every time a developer told me that something was technically impossible only for someone else to figure out how to get it done, I'd be a rich man! Comments welcome.
If you go with the first approach, can you make the change just for Kate since there are several reports of the bug? If it works and people are happy, then the functionality is there and tested if other KDE apps have similar bug reports. If there are complications after the fact, deal with them as they arise, and maybe pull it back out if needed. Not a great answer, but it limits the scope and you know you have people using Kate who see this all the time who can test and verify.
Kate will get it automatically for its main window, along with all other KDE apps that use a KXMLGui main window. It's the non-main-windows that need manual work.
I suspect it's the Main window people are most complaining about. In my case, the upper left corner of the main Kate window is about the middle of my monitor and most of the window is off the bottom and right side of the monitor. Fixing that would be fantastic. Down the road if people want other dialog positions saved/restored, you have the framework avaiable.
Yep, and that's where I'm starting here, for sure. I have the common case working and just need to handle the more complicated cases of multiple screens and per-screen positions. I hope to dig into that in the next few days.
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kxmlgui/-/merge_requests/9
Git commit 1434257972de28f183e701cb7da3bd333fa71f3c by Nate Graham. Committed on 02/08/2020 at 14:52. Pushed by ngraham into branch 'master'. Add functions to save and restore window positions on non-Wayland platforms These functions allow an application to save and restore the positions of its windows. Positions are stored on a per-screen-arrangement basis. For example with a single screen connected, the config file would have entries like this in it: eDP-1 XPosition=140 eDP-1 YPosition=340 When a second screen is connected, the following gets saved: eDP-1 HDMI-1 XPosition=3878 eDP-1 HDMI-1 YPosition=29 This ensures that each separate screen arrangement can have its own saved window position, which is handy for the use case where you have a laptop that you plug into an external screen some of the time. It also allows the position to get restored to the correct screen when there are multiple screens. This is a necessary first step to getting KDE apps to save their window positions on X11 The next step would be calling the new functions from KXMLGui and Kirigami apps, and then porting all apps that manually invoke KWindowConfig::saveWindowSize() and KWindowConfig::restoreWindowSize() to also invoke KWindowConfig::saveWindowPosition() and KWindowConfig::restoreWindowPosition() in the same places. The functions only work on X11 or other non-Wayland platforms. On Wayland, the compositor has sole dominion over window positioning so a compositor-specific solution much be adopted instead, such as https://bugs.kde.org/show_bug.cgi?id=15329. M +58 -0 src/gui/kwindowconfig.cpp M +27 -0 src/gui/kwindowconfig.h https://invent.kde.org/frameworks/kconfig/commit/1434257972de28f183e701cb7da3bd333fa71f3c
Git commit bbcfcc53429783b365b3b323d652108980d00b5f by Nate Graham. Committed on 20/08/2020 at 16:51. Pushed by ngraham into branch 'master'. Save and restore position of main window This commit invokes the new KWindowConfig::saveWindowPosition() and KWindowConfig::restoreWindowPosition() added to KConfig in https://invent.kde.org/frameworks/kconfig/-/merge_requests/14. As a result, KDE apps using KXMLGui now automatically save and restore the positions of their windows on a per-screen-arrangement basis. FIXED-IN: 5.74 M +39 -2 src/kmainwindow.cpp M +1 -0 src/kmainwindow.h M +3 -0 src/kmainwindow_p.h https://invent.kde.org/frameworks/kxmlgui/commit/bbcfcc53429783b365b3b323d652108980d00b5f
I wonder if this option is turned on by default and if we can switch it on/off? Considering your last commit I'm afraid not. In this moment behavior of appearing windows in my KDE/Plasma looks like below: Following option I have turned on: "System Settings -> Windows Behavior -> Advanced -> Window placement: Under mouse" and it is fine for me. Please consider I don't need to window position would be always saved, rather I would prefer only to be saved its size. I think your improvement is not safe for me, and probably for others who have similar displays configuration. Below please find my explanation. I have multi monitors configuration. Both displays are always connected, only the second one is turned on occasionally - just because this is projector. Unfortunately Plasma sees it always as available (separate bug report I sent), even device itself is turned off. I suppose this is happen because xrandr returns always both displays as connected, what is truth of course, but the issue is that one of them is turned off. In result any window placed there will be not achievable normally. Without option I described on top one happened that some windows appeared sometime on this not visible, but connected screen, what of course was the problem to achieve them. I'm afraid that with your improvement If I will close any window placed on projector screen and at the next day when I will have projector turned off and I will run the same application then it will appear on desktop placed on not visible screen, so window will be not achievable normally. That's why I wish I had an option to be able to choose if want save position and size or only position or only size. Would be nice to have such.
So in System Settings > Displays & Monitor, you always see your projector listed there even when it's unplugged and turned off? Can you mention the bug report you filed? Let's continue the conversation there.
> So in System Settings > Displays & Monitor, you always see your projector > listed there even when it's unplugged and turned off? Yes. If projector is connected (in my case by HDMI) and turned off I can see it in System Settings > Displays & Monitor. Of course firstly was detected correctly by plasma, only doesn't disappear when I turn it off, which is happen in Windows systems. Some workaround for this is just disable projector in System Settings or by command "xrandr --output HDMI2 --off" and of course when I need to use project then I need to activate this screen in Plasma (manually) or let Plasma detects it again. > Can you mention the bug report you filed? Let's continue the conversation > there. There are couple bugs I reported. Bug 425185 - Display Configuration allows to replicate screen for turned off screen Bug 421116 - Multimonitor support works randomly Bug 420881 - In case two screens and after very first start of Plasma, window of application appears on not primary screen Bug 416556 - Application window is displaying on not working currently display Bug 400765 - Cannot move application window to another display Bug 399774 - Switching desktop made that desktop from external screen is visible Here I tried to find solution (without success). https://bbs.archlinux.org/viewtopic.php?pid=1919689#p1919689 https://www.reddit.com/r/linuxhardware/comments/i5mstl/is_there_a_way_to_detect_whether_an_external/ Isn't possible to add for your improvement the switcher to be able to choose if user want to save position and size or only position or only size? Would be nice to have such and it would be fix issue I described in previous post. Option could be set on by default. You set this report back as "RESOLVED", whereas there are still not resolved problems here :/. I can report another bug report if you prefer.
In general, when two features conflict, the solution is to fix the bug or conflict, not make one disable-able. :) Based on their titles, I don't see which bug report tracks the projector appearing in the kscreen KCM when turned off.
> In general, when two features conflict, the solution is to fix the bug or > conflict, not make one disable-able. :) This feature is very useful, but mostly for thous who works with single monitor or with multi-monitors which always tuned on. Please notice there is/are some bug(s) in support of multi monitor configuration in KDE/Plasma, and developers ignore it. Seems you even didn't read any of my list :/. And issue is pointed in very first. Your improvement causes issue because of saving position of windows in other than main display. I listed only mine reports, I suppose there are more. Notice that even is not built in an option to bypass this if any window stuck in invisible/unreachable screen. I mean 'Move to display' available in icon of application present in taskbar. Such option is only available in title bar, which is useless for me. How can I reach it if window stuck on display which is turned off. Yes, you can say - just turn on projector, by this is not comfortable, because it takes time to start it up. BTW. I'm not sure how well it (display turn on/off) is handle in GNOME and if it is able to detect whether display is turned on/off. > Based on their titles, I don't see which bug report tracks the projector > appearing in the kscreen KCM when turned off. I didn't mention about projector directly, because this is general issue. Quotation from very first (Bug 425185): > > I have multi monitors configuration (monitor+projector and both connected via HDMI), but > > do to not correct support in Linux distribution or DE itself (turned off screen connected > > via HDMI is treated as normally working and considered by Plasma to display content) Bug 416556 - Application window is displaying on not working currently display Issue refers to appearing application window on non visible screen, only connected but not tuned on (previously was turned on, so Plasma detected it and saved in kscreen conf.) Bug 399774 - Switching desktop made that desktop from external screen is visible Quite old (sent 2 years ago) report of issue (not resolved) referring to this that Plasma sees desktop on display which is turned off, because shows its wallpaper though split of second during switching virtual desktops. If you have multi-monitor configuration please try to turn off (by power button) your second display, and try to move mouse there, move window and eventually check settings in "System Settings > Displays & Monitor" to find out if turned off display is considered by Plasma as reachable. Please notice I tested this issue on different machines and different distributions (KaOS and Manjaro - live version) with the same result. Today I'll try to test it with recent neon-developer Linux distribution (dated on 20200821).
> developers ignore it Developers don't ignore tickets. Multiscreen issues are nearly impossible to debug, because 1) you need a matching hardware configuration to be able to reproduce, 2) several software components are involved (xrandr, kscreen, Qt, Plasma, not to mention X11 and Wayland differences), and 3) timing issues caused by hardware detection (on connect, disconnect, reconnect, on power down, on power up, on suspend and sleep modes, ...).
FWIW I'm working on a way to disable this behavior on X11 for people who don't like it or who can't use it due to other bugs. If all goes well, it should appear in the Window Management KCM in Plasma 5.20.
See https://invent.kde.org/frameworks/kxmlgui/-/merge_requests/14
...and https://invent.kde.org/plasma/kwin/-/merge_requests/211 for a GUI to expose it.
As I promised. I retested issue on neon-developer and met the same behavior - the newest (unstable) Plasma sees desktop coming from turned off display. Nevertheless I need to apologize what I said about multi monitor configuration in Windows. I claimed that on Windows this works well. Unfortunately doesn't. I tested multi monitor configuration with Windows 10 Professional (so not the newest build) and turned out that Windows behaves the same like Plasma, so desktop coming from turned off display is achievable.
(In reply to Nate Graham from comment #24) > See https://invent.kde.org/frameworks/kxmlgui/-/merge_requests/14 Thanks a lot for adding switcher (enable/disable). Your option is very nice and I'm sure that a lot of users will be happy having it in yours KDE/Plasma. I would be very happy, and maybe others also, if option for moving window between displays would be available for taskbar icon (for running and/or minimized application). Reported last year bug: https://bugs.kde.org/show_bug.cgi?id=407647
(In reply to Christoph Feck from comment #22) > > developers ignore it > > Developers don't ignore tickets. Multiscreen issues are nearly impossible to > debug, because 1) you need a matching hardware configuration to be able to > reproduce, 2) several software components are involved (xrandr, kscreen, Qt, > Plasma, not to mention X11 and Wayland differences), and 3) timing issues > caused by hardware detection (on connect, disconnect, reconnect, on power > down, on power up, on suspend and sleep modes, ...). I apologize because too harsh words about developers. I face with this issue some time and didn't saw iny reply on my bug reports. Only in first (the oldest on list I put in one post) one developer suggested that my hardware is broken :(, which wasn't truth. I'm not sure where lies the problem of detecting if display is turned on/off. Maybe in possibility of communication by DDC protocol, which seems my display (NEC EA275WMi) and some other like my projector (Optoma) and another monitor produced by DELL doesn't have, or maybe xranr or different X application is not able to get this information from display. I thought that checking and detecting problems with multi monitor configuration isn't so hard if user uses graphics with open source drivers like Intel integra, where is usually uses driver i915 and second thing is just xorg for X11 session. And BTW. Is possible to provide all details about hardware users have, but I noticed nobody asks for it. Maybe some configuration might similar to this what developer has. Anyway I'm not going to push on fixing this issue if event this problem happens in the most popular in the world desktop operating system.
Git commit 39f7171d5ef3dea7a911b9d9b8088420c39df81a by Nate Graham. Committed on 28/08/2020 at 16:38. Pushed by ngraham into branch 'master'. Allow opting out of remembering window positions on X11 Various people have requested this, for reasons that seem sensible enough to me: - Some people like the KWin positioning modes and want all windows to follow them - It might be annoying to have only KDE apps follow this setting and preferable to not use it at all for pepole who use mostly non-KDE apps - The per-screen-arrangement memory feature may interact strangely or in a buggy manner for some people's screen arrangements For those reasons, it seems reasonable to allow disabling the feature, though it still remains on by default. This commit turns it off if `AllowKDEAppsToRememberWindowPositions=false` is set in the user's `kdeglobals` file. A GUI to toggle this will be added in a separate commit to some System Settings KCM. M +14 -6 src/kmainwindow.cpp https://invent.kde.org/frameworks/kxmlgui/commit/39f7171d5ef3dea7a911b9d9b8088420c39df81a
Git commit 5ba3793cf977479faf70075de09d21577514b457 by Nate Graham. Committed on 28/08/2020 at 16:43. Pushed by ngraham into branch 'master'. [kcmkwin/kwinoptions] Add option to disable window position memory for KDE apps This adds a setting to the window options KCM to disable KDE apps remembering their own window positions on X11, and instead always use the KWin placement modes. The setting sets an option in `kdeglobals`, rather than kwinrc, as it is not a KWin-specific option *per se*. The UI is also hidden on Wayland, as it it not relevant there because the functionality it disables does not work on Wayland. Instead, remembering window positions will eventually be implemented in a different way and affect all windows, not just KDE windows. See https://invent.kde.org/frameworks/kxmlgui/-/merge_requests/14 for more details. M +1 -0 kcmkwin/kwinoptions/CMakeLists.txt M +12 -2 kcmkwin/kwinoptions/advanced.ui A +15 -0 kcmkwin/kwinoptions/kwinoptions_kdeglobals_settings.kcfg A +6 -0 kcmkwin/kwinoptions/kwinoptions_kdeglobals_settings.kcfgc M +4 -3 kcmkwin/kwinoptions/main.cpp M +1 -0 kcmkwin/kwinoptions/main.h M +15 -4 kcmkwin/kwinoptions/windows.cpp M +3 -2 kcmkwin/kwinoptions/windows.h https://invent.kde.org/plasma/kwin/commit/5ba3793cf977479faf70075de09d21577514b457
Hi, On my system, Operating System: Mageia 8 KDE Plasma Version: 5.19.5 KDE Frameworks Version: 5.74.0 Qt Version: 5.15.1 Kernel Version: 5.8.10-desktop-1.mga8 OS Type: 64-bit Processors: 4 × Intel® Core™ i5-6600K CPU @ 3.50GHz Memory: 15.6 Gio of RAM Graphics Processor: GeForce GTX 1660 Ti/PCIe/SSE2 This functionality breaks this setting on X11: In KDE System Settings-Window Management-Window Behaviour-Advanced tab-Window placement. whatever you select (centered, minimal overlapping, random, left-corner,...), all new instance of already launched GUI app use last position, overlapping integrally the n-1 window. Tiling function is broken. Select "Centered" for example. You expect all new window are at the center of the screen. Nope, if you have already the app in the past, it will use past position, not the center of the screen. So functionality of above setting is broken, misbehaving. Even I know there will be a GUI toggle in Plasma Workspace 5.20, this is not the case on 5.19.5. So, no, this is broken. The release of this functionality should be delayed until availability of GUI option. This should have been released in the same time of Plasma Workspace 5.20. I know it is a side effect of KF5 released each month and Plasma every 4 month or so.
Also, KF5.74 was released on September 06th, 2020 and Plasma 5.20 milestone is set to be released on October 13th, 2020. So too long time. We already have users on Magiea who don't understand what is going on. This functionality should has been released with KF 5.75 (October release) and Plasma 5.20 launched on same date, we can't ship Plasma Workspace 5.20 currently in Beta state.
Indeed. :( Unfortunately it's too late now. We can't remove public API in frameworks or backport UI changes to bugfix Plasma releases. Also the change doesn't backport cleanly as it's based on functionality added in Plasma 5.20. Finally, there are no more Plasma 5.19 releases planned. It's not an ideal situation, I know. I didn't anticipate how many people actually liked the current functionality, given the sheer number of duplicates on this bug report and Bug 15329 (23 in total). In the meantime, Distro packagers should feel free to patch out the frameworks change until the new Plasma version is shipped. It should revert cleanly.
As for the mismatch in schedules, it's a frustrating thing. I couldn't land the Frameworks change in 5.75 because technically Plasma 5.20 depends on Frameworks 5.74. Shipping a Plasma feature that has no effect unless you actually have 5.75 is not technically appropriate, even if by happenstance it would probably work because those versions would be released close together. A distro could theoretically package Plasma 5.20 with Frameworks 5.74 and then the new checkbox in the KWin KCM wouldn't work. Maybe someday I'll achieve my dream of unifying the Plasma, Release Service, and Frameworks schedules so that this class of bug is entirely eliminated. Someday...
(In reply to Nate Graham from comment #34) > As for the mismatch in schedules, it's a frustrating thing. I couldn't land > the Frameworks change in 5.75 because technically Plasma 5.20 depends on > Frameworks 5.74. Shipping a Plasma feature that has no effect unless you > actually have 5.75 is not technically appropriate, even if by happenstance > it would probably work because those versions would be released close > together. A distro could theoretically package Plasma 5.20 with Frameworks > 5.74 and then the new checkbox in the KWin KCM wouldn't work. > > Maybe someday I'll achieve my dream of unifying the Plasma, Release Service, > and Frameworks schedules so that this class of bug is entirely eliminated. > Someday... It's a race... ;) and don't get me wrong: You make a great job for Plasma, each new day! Our congrats. And, yeah, these releases should be aligned.
Thanks for the kind words! And sorry to have caused a problem for your users. :(
*** Bug 423191 has been marked as a duplicate of this bug. ***
*** Bug 422604 has been marked as a duplicate of this bug. ***
*** Bug 302858 has been marked as a duplicate of this bug. ***