Opened 19 months ago

Last modified 17 months ago

#14181 new bug

Deskbar preferences are not persistent across reboots

Reported by: closequarters Owned by: nobody
Priority: normal Milestone: R1
Component: Preferences/Deskbar Version: R1/Development
Keywords: preferences deskbar setting Cc:
Blocked By: Blocking:
Has a Patch: no 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 (8)

comment:1 by korli, 19 months ago

Might this be a regression?

comment:2 by Janus, 19 months 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 closequarters, 19 months 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 Janus, 19 months 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.

Last edited 19 months ago by Janus (previous) (diff)

comment:5 by Janus, 18 months 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 closequarters, 18 months 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 pulkomandy, 18 months 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 jscipione, 17 months 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.

Note: See TracTickets for help on using tickets.