Early on Builder had the concept of layered settings. You had an application default layer the user could control. You also had a project layer which allowed the user to change settings just for that project. But that was about the extent of it. Additionally, these settings were just stored in your normal GSettings data repository so there is no sharing of settings with other project collaborators. Boo!
With Foundry, I’d like to have a bit more flexibility and control. Specifically, I want three layers. One layer for the user’s preferences at the application level. Then project settings which can be bundled with the project by the maintainer for needs specific to the project. Lastly, a layer of user overrides which takes maximum preference.
Of course, it should still continue to use GSettings under the hood because that makes writing application UI rather easy. As mentioned previously, we’ll have a .foundry directory we place within the project with storage for both user and project data. That means we can use a GKeyFile back-end to GSettings and place the data there.
You can git commit your project settings if you’re the maintainer and ensure that your projects conventions are shared to your collaborators.
Of course, since this is all command-line based right now, there are tab-completable commands for this which again, makes unit testing this stuff easier.
# Reads the app.devsuite.foundry.project config-id gsetting
# taking into account all layers
$ foundry settings get project config-id
# Sets the config-id setting for just this user
$ foundry settings set project config-id "'org.example.app.json'"
# Sets the config-id for the project default which might
# be useful if you ship multiple flatpak manifest like GTK does
$ foundry settings set --project project config-id "'org.example.app.json'"
# Or maybe set a default for the app
$ foundry settings set --global project stop-signal SIGKILL
That code is now wired up to the FoundryContext via foundry_context_load_settings().
Next time I hope to cover the various sub-systems you might need in an IDE and how those services are broken down in Foundry.