Wesnoth does not save preferences when closed by window managers 'X'-button

[sevu]

Wesnoth saves the preferences when quitting. Seems it's not everywhere case when quitting via the top-right X-Button.

In my tests on Linux with KDE and X11 it worked. But what indicates it's not for everybody the case:

• Recently someone complained in the Discord chat that discovered units in the help are reset after application restart
• https://r.wesnoth.org/p658060 (also @Hejnewar )

Maybe it only happens on Windows or Mac.

For testing, I used the chat command /friend someone, and checked if it is in the savefile after closing Wesnoth. Tried both closing Wesnoth with the X and confirming the popup, and by clicking the X button multiple times instead (which closes Wesnoth regardless of the popup).

[CelticMinstrel]

At least on Windows, I believe clicking the X multiple times kills the application rather than just sending it a quit message, so that particular part of the test might not be relevant…

[Wedge009]

Need to find out what the specific cases of 'not working' are. I just checked a change of language and using the window manager 'X' was equivalent to the Quit menu button in both Windows and Linux. I was using the 1.14.13 release.

[stevecotton]

For X11, it probably depends on the window manager. There's several possible ways that the 'X' button can work.

[Wedge009]

Apparently the complaints weren't from Linux users but same as sevu I am using KWin on X11.

[AI0867]

At least on Windows, I believe clicking the X multiple times kills the application rather than just sending it a quit message, so that particular part of the test might not be relevant…

While we might argue that that's not our fault, it's still annoying to the user. We could consider the following solutions:

• saving on change
• preemptively saving before we show the confirmation window

[gfgtdf]

At least on Windows, I believe clicking the X multiple times kills the application rather than just sending it a quit message, so that particular part of the test might not be relevant…

I'm quite sure that this is wrong.

[CelticMinstrel]

It's a simplification of what happens, but it's definitely possible to force-kill a Windows application by clicking the X button. It might only work if the application is not responding though? I'm not quite sure.

[gfgtdf]

It's a simplification of what happens, but it's definitely possible to force-kill a Windows application by clicking the X button. It might only work if the application is not responding though? I'm not quite sure.

Yes it is possible if the application is not responding but that unrelated to the issue here.

[CelticMinstrel]

Yeah, if it's only when not responding then it's not relevant here.

[Wedge009]

Any further information on this? I didn't see any in the linked forum thread. I'm inclined to close this if not.

[ProditorMagnus]

I have relied on this feature to leave without waiting when I know I did not change preferences file.

[AI0867]

It's undocumented (besides bug reports and occasional forum threads, I expect) behaviour that is hardly intuitive. It can be useful for people who understand it, but I expect it's more frequently a cause of issues for people who don't.

If I didn't know the internals, I would expect the method I use to quit the game not to affect whether the preferences are saved, unless (or even if!) I force-quit/kill/crash the game. (one might expect the preferences to be saved the moment you exit the preferences menu, rather than on exit)

If being able to change preferences without saving is a feature that we (probably just the devs) want, it would be better to make it an explicit, if hidden, feature.

[stevecotton]

All the comments before the bug report was closed were that it was an intermittent bug with the root cause not yet identified, but the last two comments suggest it's a fully understood (but undocumented) feature.

@AI0867, please would you add some details about what the internals are here?

[ProditorMagnus]

I do not need it as feature, it was just that nice exit takes long enough time waiting.

[AI0867]

All the comments before the bug report was closed were that it was an intermittent bug with the root cause not yet identified, but the last two comments suggest it's a fully understood (but undocumented) feature.

@AI0867, please would you add some details about what the internals are here?

Not sure if it's still the case, but:

The internals are IIRC, fairly simple: the preferences are stored in a class that is initialized from the preferences file, optionally modified by commandline arguments, and then more by the preferences menu, kept in memory, and finally written to disk during a clean, regular exit, which for some reason (probably rigid internals), a window manager quit event isn't or wasn't, in every case.

If it still exists, but not generally, I would expect this to be during modal dialogs.

[Wedge009]

It's been a while since I looked into this in detail, but my recollection is that Preferences are saved in memory (remain active for as long as Wesnoth remains open) while they are only written to disk once Wesnoth closes - this seems to match the description above. In my experience, I have been unable to exit Wesnoth without having the Preferences written to disk irrespective if the game was closed via:

• Exit button from main menu
• Exit menu item during a game
• Keyboard short-cut for closing windows (including Ctrl+Q and Alt+F4)
• Clicking the window's 'X' button

This applies to Windows and Linux. Short of forcing an abnormal program termination via the OS process manager, I don't recall encountering this issue.

[stevecotton]

I normally launch Wesnoth from a Linux command line, and if I'm testing often exit with a Ctrl+C on that command line. There was a long time when that would intermittently deadlock in SDL's cleanup routines, which would be a possible root cause of this issue too.

However, it was rare and the response to Ctrl-C didn't seem a priority to debug.

[ProditorMagnus]

It probably relies on HDD to ensure saving takes long enough time.