> It is part of this topic because project settings interact with user > settings, it cannot be ignored.
As long as the current functionality is not degraded and continues to be supported, I think it can be treated separately once the core/base settings are all using GSettings. > how are asynchronous changes handled? On a case-by-case basis. In Mousepad, where everything is "properly GObject-ified" I bound lots of stuff together using GObject property binding and GSettings binding, and binding both ways, and this lead to a few racy-like bugs and not helping to reduce settings spaghetti. In this PR for Geany, I try to only for now reproduce the directionality of the settings changes, thinking about which way(s) they should go. By being careful (as at present) what updates what, we can assure some useful settings transcend instances while others only store to settings and affect new instances. For example I probably don't want a "fullscreen" GSetting to affect all running instances, but I might want it to affect new instances. Conversely, I might want a setting like "editor-font" to affect all running instances (or not). In this PR and related ones, this behaviour is completely open for discussion, since "live updating" of settings was not previously possible. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/1257#issuecomment-251866813
