Bug 484327

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