[Octave-bug-tracker] [bug #65499] Use separate GUI settings for Octave releases

[John W. Eaton]

Follow-up Comment #13, bug #65499 (group octave):

"This seems to be more complicated than I thought. Since cset
http://hg.savannah.gnu.org/hgweb/octave/rev/ad014fc78bd6 there is no single
settings object which is created at startup and provided by the resource
manager later on. This single object could have been defined with a different
path, depending on an environment variable. Instead, each time the settings
file has to be accessed, a settings object is created with the standard
constructor that generates the path from the company and application name,
which are both set at startup."


There seems to be some confusion about how the QSettings objects work.  I know
I was confused about it before I wrote the changes in
http://hg.savannah.gnu.org/hgweb/octave/rev/ad014fc78bd6.  I tried to explain
in my commit message for that change that there *is* supposed to be only one
global settings database for the application.  The individual QSettings
objects that are created locally allow thread-safe access to that global store
of settings values.  This design means that users of the settings can access
the global data from any thread without having to worry about locking - that
is managed by the QSettings object itself.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65499>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/