[haiku-development] Re: Design question.

  • From: looncraz <looncraz@xxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Wed, 31 Mar 2021 20:37:22 -0500

My preference:

There's no need for the server to care about temp/permanent settings, it should treat everything as a simple state change. The server should keep a default for each setting available and also be able to send a message with all active settings.  It does not keep a history of changes made, though logging changes made could be quite useful for troubleshooting in the future.

The preflet should contact the server and request the current settings, which will be a BMessage.
The preflet should then save a copy of this message to retain the original settings from when it launched.
The server should be able to handle any combination of settings being changed in a single BMessage and make them immediately effective or send back an error message to the sender.
The preflet can send a dedicated message for resetting all settings to defaults, it will then request the active settings and update the interface as appropriate.

Only the server reads and writes the settings file, no other utility can do so.  The only shared code are message 'what' definitions, everything is done through messaging... you can change settings using 'hey' if you so chose, in keeping with BeOS's fully scriptable goals.

I think this should be standard practice and is more or less how the app_server operates for colors and color updates... you can change any set, or even all, colors in a single BMessage and they take immediate effect.

--The loon

(resent directly to list)

On 31/03/2021 16.28, Alexander G. M. Smith wrote:

Heh heh, evil laugh - use Git to store all versions of the settings :-)

Though we actually do something like that for the active packages so you can select old installation states from the boot menu.

Maybe in the BMessage, have a boolean flag that says permanent change or temporary change.  The server doesn't save temporary changes to the settings file.  Possibly also have a "reload settings" command to the server that reloads its state from the settings file.  And another one for "default settings" to use built-in defaults.

- Alex

On 2021-03-31 5:15 p.m., fredrik@xxxxxxxxx wrote:
So right now it looks like the settings handling will be moved to the kit.
Changes will be send to the server and saved when it quits.. in there somewhere we will store the old value so we can do a one time undo.




Other related posts: