Saving history and favorites on unusual situations (e.g. cutting off of power cord)

[BEST8OY]

Describe the bug
GD can't save the latest state of History and Favorites on Arch Linux if GD is in background and you initiate a restart or shutdown.

To Reproduce
Steps to reproduce the behavior:

1. Search some words and star some words
2. Close GD to background
3. Restart
4. Open GD and your searches and favorites are not there (Of course the saving interval is on 0)

Expected behavior
It should save them.

OS and software versions

Goldendict-ng 24.01.22 at 2024-01-23T17:36:50
Qt 6.6.1 GCC 13.2.1 20230801 arch linux 6.7.0-arch3-1 x86_64-little_endian-lp64
Flags:USE_XAPIAN MAKE_ZIM_SUPPORT USE_ICONV MAKE_CHINESE_CONVERSION_SUPPORT

[xiaoyifang]

I guess the reason is that when restart the os ,the gd got no chance to save the config file.

[BEST8OY]

I guess the reason is that when restart the os ,the gd got no chance to save the config file.

Is there any way to overcome this?
Windows closes all the apps before initiating shutdown or restart thus no problem I suppose!?
Is it not the same on Linux?

[xiaoyifang]

Can you test this PR #1389

[BEST8OY]

Can you test this PR #1389

I built from that branch with cmake
executed it
did some stuff and rebooted
but the last state was not saved

[xiaoyifang]

Thanks for you effort . gd-ng need a chance to save the config .

Has no clue right now.

[fanguohao]

Thanks for you effort . gd-ng need a chance to save the config .

Has no clue right now.

I found the latest favorite words can only be archived to local config file <favorites.txt> when the app is properly exited. Is it possilbe to synchronize the local config file with the cache/swap file loaded by the flatpak when a new favorite word is added?

Environment: Ubuntu 22.04

[shenlebantongying]

Saving history/favorite at interval already exists

goldendict-ng/src/ui/mainwindow.cc

Line 886 in d5037de

history.setSaveInterval( cfg.preferences.historyStoreInterval );

We should set an initial value of maybe 15 mins.

---

I check how Qt6's timer is implemented.

QTimer wraps QBasicTimer which wraps std::chrono::steady_clock which wraps clock_gettime.

The QBasicTimer is a global timer, and all other timers merely register timers. For the default Qt::CoarseTimer, registering arbitrary number of timers has almost no impact on CPU usages 😅.