SUMMARY After upgrading to 6.0 the initial size of the Kmail main window, the composer window and the attachment selection window are not what I would expect them to be. When I start Kmail after logging in, it appears in a rather small window, about 760x830. I had it maximized before ending the session and I can reproduce this even when just quitting Kmail and restarting it. So I have to maximize it after every start. Once maximized, it will open composer windows also maximized (it does not do that before it got maximized itself) After manually unmaximizing the composer window (and closing it either by canceling or sending) any new composer is created in non-maximized form for a while (have not been able to determine yet when it resets to maximized). In almost ironic opposition, the dialog for selecting attachments is always opened with minimal size (screenshot attached). STEPS TO REPRODUCE 1. Start Kmail 2. Open composer (new mail or reply, shortcut or toolbar) OBSERVED RESULT Kmail main window does not restore its maximized state. Composer window seems to follow the main windows maximized state. Attachment dialog is too small. EXPECTED RESULT Kmail main window is restored to the size it had when closing. Composer opens in the size it had last. Attachment dialog can be used right away without needing to be resized to actually see files. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: KDE Neon 6.0 (available in About System) KDE Plasma Version: 6.0.2 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 ADDITIONAL INFORMATION
New observation: main window and composer seem to access the same size information. I just realized that the observed 760x830 mentioned in the report are the size of my non-maximized composer window. To verify I resized the composer to some new shape and then quit Kmail after closing the composer. On restart Kmail came up with that new geometry. If I do not un-maximize the composer and quit Kmail then it restarts in maximized state.
I was just about filing a bug about the initial window size of the composer window and saw this one, which seems to already describe the issue I see. It seems like one of the problems has been resolved meanwhile: The main window restores its size (not its position) when restarting. So maybe, it's about also restoring the position (I'm not on Wayland, I know that positioning is not possible on Wayland!). The other problem remains: The composer window inherits the size of the main window. This is a regression compared with the Qt5/KF5 version of KMail, where the composer remembered its own size and position. I see this exact behavior using KMail 6.0.2 on Artix and also still using 6.1.0 on Gentoo.
(In reply to Tobias Leupold from comment #2) > It seems like one of the problems has been resolved meanwhile: The main > window restores its size (not its position) when restarting. Just had this one again after the upgrade to 6.1 and also verified that I also still see the other two issues.
I can confirm this is still present in Kmail 6.2. Both the main window and the composer window open with the same size when the program starts. So, if you make the mail composer window smaller because you want it that way (as I do), the next time you open Kmail it will apply that smaller size to the main window too. Moreover, I haven't been able to solve this using window rules, as both window classes are called "kmail org.kde.kmail2", and I can't find a way to tell them apart in the window rule creator menu.
Scratch the last thing I said: I could tell both window types apart using the window roles (kmail-mainwindow and kmail-composer). Despite this workaround, the bug still stands. It's never been necessary to use window rules to remember the different KMail window sizes before now.
I didn't have had a look at the code yet, but I'm pretty sure that this is due to KDE now separating the state stuff (which is possibly underlying constant changes and does not need to be backed up) from actual config stuff. I also stumbled upon this while porting KPhotoAlbum to Qt6/KF6. In Qt5/KF5 times, the window state was saved in ~/.config/whateverrc. With Qt6/KF6, it goes into ~/.local/state/whateverstaterc. My .local/state/kmail2staterc only contains a [MainWindow] section. My bold assumption would therefore be that the state of the composer window is simply not stored and/or read correctly (yet), which is of course a regression, thus causing to some default setting being applied. I'll check the sources. Maybe, I can find it.
That's interesting, thanks for the explanation. In my .local/state/kmail2staterc I've got lots of sections that store window or dialog sizes: [AccountConfigOrderDialog], [AddHostDialog], [AddTransportDialog], [AgentTypeDialog], [CollectionPropertiesDialog], [CompletionConfigureDialog], [DistributionListDialog], [FolderConfigureSettingsDialog], [GpgSettingsDialog], [MailSourceWebEngineViewer], [MainWindow] and [SubscriptionDialog]. As you can see, there's no [ComposerWindow] (or whatever it's supposed to be called),l so perhaps you're right.
Reported symptoms hopefully fixed by commit https://invent.kde.org/pim/kmail/-/commit/28480aeb
I knew it was caused by that stuff! Thanks a lot for the follow-up! I can confirm that 28480aeb at least partially fixes the problem, I tested the patch against v24.08.0 on my Gentoo system. The main window and the composer window now get their own sizes back on startup or when launching the composer respectively. But: The positions are not restored. (Yeah, I know about the Wayland stuff and that we can't position windows using Wayland atm – I see this using X11, where positioning and resizing works with other KXmlGuiWindow apps): The main window always shows up on the upper left edge of the screen, and the composer window always appears centered on the screen. Having the right geometry, but not the right position. So: Is this a bug or a feature?! ;-) Anyway, thanks for fixing the size, this really eliminates a big annoyance of KMail 6 :-)
Thanks a lot Tobias for debugging/testing and Jonathan for creating the patch! As an additional note: I can no longer reproduce the issue I originally had with the file dialog for adding attachment.
Restoring the window positions, even on X11 where it is supported, may not work because of a combination of intended KMail design and KXmlGui. KMainWindow saves the window position along with the size as intended, but restoring the size in KMainWindow::applyMainWindowSettings() looks at a saved setting "RestorePositionForNextInstance" in the application state config. If this flag is set to false then the window size is not restored. If it is true, then the window position is restored and then the flag is reset to false so that the next instance of the window does not open in exactly the same place. When the window is closed, the flag is reset to true by KMainWindow::closeEvent() so that the next window opened will again have its position restored. The problem in KMail is that a KMail::SecondaryWindow, which the composer and reader are subclasses of, implements its own closeEvent() to handle the system tray persistence. If the system tray icon is present, this does not call KMainWindow::closeEvent() so the flag is not reset to false and the window positions will never be restored from then on. You can confirm this by looking at the [Composer] section in ~/.local/state/kmail2staterc and it will probably have a setting "RestorePositionForNextInstance=false". If you quit KMail, remove this setting and restart KMail, it will restore the position of the next composer window that is opened, but subsequent ones will again open with the default window manager placement. It may be possible to work around this by copying the KMailWindow::closeEvent() code, by doing: KConfigGroup grp = stateConfigGroup(); if (grp.isValid()) grp.deleteEntry("RestorePositionForNextInstance"); immediately before the saveAutoSaveSettings() in SecondaryWindow::closeEvent().
seems fixed in last master
A possibly relevant merge request was started @ https://invent.kde.org/pim/kmail/-/merge_requests/141
Git commit 2b7c3723f92f283c71b73fdf23b20a4c9ccf8cd1 by Jonathan Marten. Committed on 24/09/2024 at 12:08. Pushed by marten into branch 'master'. Fix saving and restoring of window position as well as size Commit 28480aeb implemented the use of the state configuration to store window size and position for the composer and reader windows. However, to also correctly restore the window position, as noted in the referenced bug, it is necessary to clear the flag used by KMainWindow to ensure that multiple windows do not open in exactly the same position. This is normally done by KMainWindow::closeEvent() but has to be done by SecondaryWindow itself for these windows. The main window is also changed to use the state configuration, so that its size will be correctly restored. Restoring its position works when KMail is run without a system tray icon, but with the icon the main window always seems to open at the top left of the screen. Possibly this is a result of KWin overriding the application specified window placement only in this case. M +3 -5 src/editor/kmcomposerwin.cpp M +3 -5 src/kmmainwin.cpp M +2 -4 src/kmreadermainwin.cpp M +23 -2 src/secondarywindow.cpp https://invent.kde.org/pim/kmail/-/commit/2b7c3723f92f283c71b73fdf23b20a4c9ccf8cd1
Git commit c77a26db9379818073d29cfb5250ac1ada5d8115 by Jonathan Marten. Committed on 13/10/2024 at 15:00. Pushed by marten into branch 'master'. Fix saving and restoring of window position as well as size Commit 28480aeb implemented the use of the state configuration to store window size and position for the composer and reader windows. However, to also correctly restore the window position, as noted in the referenced bug, it is necessary to clear the flag used by KMainWindow to ensure that multiple windows do not open in exactly the same position. This is normally done by KMainWindow::closeEvent() but has to be done by SecondaryWindow itself for these windows. The main window is also changed to use the state configuration, so that its size will be correctly restored. Restoring its position works when KMail is run without a system tray icon, but with the icon the main window always seems to open at the top left of the screen. Possibly this is a result of KWin overriding the application specified window placement only in this case. M +3 -5 src/editor/kmcomposerwin.cpp M +3 -5 src/kmmainwin.cpp M +2 -4 src/kmreadermainwin.cpp M +23 -2 src/secondarywindow.cpp https://invent.kde.org/pim/kmail/-/commit/c77a26db9379818073d29cfb5250ac1ada5d8115
Git commit d0bf95c807833b4014925fb29c9aa256af9922ad by Jonathan Marten. Committed on 19/09/2024 at 14:11. Pushed by marten into branch 'master'. Fix saving and restoring of window position as well as size Commit 28480aeb implemented the use of the state configuration to store window size and position for the composer and reader windows. However, to also correctly restore the window position, as noted in the referenced bug, it is necessary to clear the flag used by KMainWindow to ensure that multiple windows do not open in exactly the same position. This is normally done by KMainWindow::closeEvent() but has to be done by SecondaryWindow itself for these windows. The main window is also changed to use the state configuration, so that its size will be correctly restored. Restoring its position works when KMail is run without a system tray icon, but with the icon the main window always seems to open at the top left of the screen. Possibly this is a result of KWin overriding the application specified window placement only in this case. M +3 -5 src/editor/kmcomposerwin.cpp M +3 -5 src/kmmainwin.cpp M +2 -4 src/kmreadermainwin.cpp M +23 -2 src/secondarywindow.cpp https://invent.kde.org/pim/kmail/-/commit/d0bf95c807833b4014925fb29c9aa256af9922ad
Thanks a lot! This rocks, because 1. It actually completely fixes the problem/annoyance 2. You show how it's done, so one can steal your approach ;-) Thanks a lot!
I just updated to KMail 24.08.3 (Tumbleweed packages) and this fix still hasn't landed. Does anyone know in what version will it be included? Or it already has, and I'm missing something? Thanks!
Seems like it didn't land in 24.08.3 yet, but you can apply 28480aeb36b99e89a876e99ece70180fb071807e and d0bf95c807833b4014925fb29c9aa256af9922ad manually to make it work (that's what I did on my Gentoo machine).
The following version(s) have fixed it for me KMail: 6.3.0 (24.12.0) KDE Frameworks: 6.9.0 Qt: Using 6.8.1 and built against 6.8.1 KDE neon 6.2 (Xcb)