Opened 7 years ago
Last modified 4 years ago
#14181 new enhancement
Deskbar preferences are not persistent across reboots
Reported by: | closequarters | Owned by: | nobody |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | Preferences/Deskbar | Version: | R1/Development |
Keywords: | preferences deskbar setting | Cc: | |
Blocked By: | Blocking: | ||
Platform: | All |
Description
I am working on ticket https://dev.haiku-os.org/ticket/5026, which involves pulling Deskbar preference settings and using them to limit "recent folders" on Backgrounds preflet. During my development process I noticed that the Deskbar settings file isn't properly created, but yet the Deskbar settings were still persisting. Then I realized that because the Deskbar is always running, the settings are being changed in memory but when you reboot Haiku the preferences return to the defaults because they cannot be loaded from the settings file (since it was never created).
I'm planning to fix this issue as part of #5026 since without the fix I can't get Backgrounds working the way the ticket intended, but I wanted to record this as an issue for tracking purposes.
I found this issue in hrev51985
Change History (10)
comment:1 by , 7 years ago
comment:2 by , 7 years ago
The deskbar works as expected...
The "settings" file is created at startup if you delete the file while the deskbar is running the settings aren't persisted. Can be this your scenario?
comment:3 by , 7 years ago
Janus you are correct. I deleted the settings file and that lead to this scenario. I retested this and confirmed that on startup the Deskbar creates the settings file, and then when the Deskbar shuts down normally (only on a planned reboot), the settings are saved. When starting up again the settings are restored.
This process doesn't work well for components that might want to use the Deskbar settings but are not running at the time that the settings are changed. For example in 5026 I need to use the recent folders count setting, but if it's been changed since startup, it's not available in the settings file. There's probably some interprocess communication that I could do to retrieve the setting, but getting from the file seems much more straightforward.
I think the Deskbar should update the saved settings any time the user closes the Deskbar Preferences window. Thoughts?
comment:4 by , 7 years ago
- The binary compatibility prevent to add a method in BDeskbar (https://www.haiku-os.org/legacy-docs/bebook/BDeskbar.html)
- You could use the roster function AddToRecentDocuments(), GetRecentDocuments() with the app signature (but then you have the images in a submenu in the recent applications menu).
Maybe someone with a better knowledge of the deskbar can give you better advice.
comment:5 by , 7 years ago
I just saw the code of GetRecentDocuments doesn't keep into account the number saved in the deskbar preferences. I think every app chooses a sensible number, maybe Background can do the same.
comment:6 by , 7 years ago
I consider it a bug or undesired behavior in Deskbar that the settings file is not recreated if deleted upon Deskbar shutdown, but based on discussion a few weeks back this ticket is no longer valid. I resolved #5026 simply using a constant recent folder count specific to the Backgrounds preferences app.
Please cancel/close/withdraw this ticket
comment:7 by , 7 years ago
Well, it is still valid, it is unexpected that if you delete the file, DeskBar does not manage to recreate it. This also probably means it keeps the file open all the time, instead of opening it on-demand when the settings change.
So it is less urgent than initially thought, but still unexpected and worth investigating.
comment:8 by , 6 years ago
Deskbar does not keep the file open the whole time, it reads the file in at startup into a data structure, modifies the data structure while running and then when the app quits (typically on reboot) it opens the settings file and writes the changes back to disk. I don't think it is doing any checks to see if the file got deleted in the meantime.
comment:9 by , 4 years ago
Milestone: | R1 → Unscheduled |
---|---|
Type: | bug → enhancement |
It's the Deskbar's settings file. I don't think anyone should make any assumptions about it. If there is data in there that is interesting for 3rd parties, we should make this available via an API.
comment:10 by , 4 years ago
I tried to expose these recent counts via the BDeskbar API but Jerome said that it was a “terrible addition.” I gather because he would prefer this setting to be moved from Deskbar to BRoster instead: https://review.haiku-os.org/c/haiku/+/320.
Might this be a regression?