Need a config system #3
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
It could just be a wrapper around dconf, but dconf is owned by GNOME. Not only is this not cross platform (we'd need another implementation for other systems), but depending on anything GNOME related is a horrible idea. Additionally, holding all settings within a single file is kind of a bad idea.
The configuration system should:
The API could look like:
Alternatively, the pattern used for canvases and textures could be used, providing more explicit ownership of resources (in this case a goroutine):
One thing I didn't consider is that any callback given in OnChange will run in the backend's event loop. Now, this is the Tomo application framework, but having a system running in another goroutine magically be able to run callbacks in the main event loop is ridiculous and will cause problems. What if the backend is not running? It should not depend on Tomo at all, ideally. Perhaps OnChange could be replaced with a Changes function that returns a channel of names:
Each time a value is modified, the name of that value would be sent along the channel. Each time this function is called, a new channel will be returned, and all of them will get the same information. When a receiver closes a channel, the Config will remove it from the list and stop sending to it. When the Config is stopped, all returned channels are closed.
Never mind that last comment. When there is no backend, tomo.Do simply does nothing. The application ought not to be running while there is no backend anyways. The simplicity gains from having it call tomo.Do outweigh the cursedness. What gosh darned application developer wants to manage goroutines just to stay updated on config values?