Agree with Torsten.
Having separate GUI settings files for e.g., each major release helps to avoid issues for not only developers but also for users that invoke more than one release of Octave on their box.
To me it is also a principle of sound SW design.

Until now I haven't been able to test the partial solution (that is apparently meant more for developers) yet.

This report seems fixed and could be closed.  However, there was a suggestion by Markus that the environment variable OCTAVE_GUI_SETTINGS perhaps have a different name.  Do we care to make that change?  Or should we just close this bug and move on?

"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.

Thank you for that change. Looks good to me. It would probably help for my use-case.

Should we maybe use a different name for that environment variable? Maybe "OCTAVE_QT_APP_NAME"? Or something else that makes it a bit clearer where it applies. Is the application name only used for the name of the settings file?

Is it a restriction by Qt or is it a restriction due to the cset you refer to?

In the context of this feature request, IMO different paths aren't strictly required but different GUI settings files are.
IIUC we already have different executable names decorated with the release number, would that help?

Some environment setting just for developers would be handy, if at all feasible.

Would we need to discuss this on Discourse?

In summary, would the following do & not be too demanding to program and maintain?

• Environment setting, for developers. (Probably much more robust then copying gui settings files hence and forth like I used to do.)
• For all other users, during installation, import as many setting as possible from the latest gui settings file and save them to a new "octave-gui-XX.ini".

BTW: a use case I didn't mention yet is that occasionally I try the OF packages I maintain with very old Octave releases (oldest I have installed is 4.2.0). AFAICS some older Octave releases used settings files with a different name so start in the default layout, but some other releases screwed up the settings for newest releases (I use to keep backups for those cases).

(sorry, a bit in nitpicking mode)

> Octave checks at startup for setting file octave-gui-XX.ini, where XX is the ...

... version of Octave that is started.

Your suggestion seems good to me.

But I hope selecting existing GUI settings files won´t be too complex to program and doesn't lead to a can of worms. E.g., I noted Qt5 GUI settings using with Octave compiled with Qt6 differ as regards Octave overall main window size; hopefully an unwary user wouldn´t interpret that new window size, different from what he/she probably expects, as a bug in Octave - that sort of thing.

An easier alternative would be to just offer to "import" as much settings as possible from the latest GUI settings file that is present. I assume that would do for the vast majority of users including me.

Some disclaimers might be needed anyway, either in the selection menu or in the simple alternative above.

@Markus ? what do you think?

@Torsten:
First off, I don't know much about Qt and GUI development. So my perhaps naive thinking goes as follows:

I don't follow the issue with e.g., editor styles in older Octave versions. At first sight I'd think separate settings files per version would rather be cleaner as they're not "polluted" (exaggerated term, sorry) with features that don't exist across all Octave versions. Also, having stale settings from older uninstalled Octave versions lingering on when using newer Octave doesn't sound good to me either.

I thought about environment settings but I figured that how to invoke or ignore them could be a challenge. In corporate settings/environments (sorry for potential confusing terminology :-) ) environment settings could be made inaccessible (immutable) for normal users.

A command line argument could be a first start for what I'd like to have.

Long time ago when Octave was started through a batch file I had version-dependent settings files (named differently then IIRC) being copied into place. Worked like a dream.
(a.o., indicating this isn't a recent wish :-) )

Anyway let's take adequate time to carefully think this over.

I noticed the same when switching between versions built with Qt5 or Qt6.

I like the idea of separating the GUI settings per major version of Octave. That might also reduce potential issues of botched GUI settings files. They'd be recreated from a clean slate at least when a new major version is installed. And they'd be clean of settings that are no longer used.

Ideally, there would also be a distinction between Qt5 and Qt6 of the same major Octave version. At least personally, I find myself switching pretty often between those two when testing.