bugGNU Octave - Bugs: bug #65499, Use separate GUI settings for...

 
 

bug #65499: Use separate GUI settings for Octave releases

Submitter:  Philip Nienhuis <philipnienhuis>
Submitted:  Thu 21 Mar 2024 09:02:18 AM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Feature Request
Status:  Ready For Test Assigned to:  None
Originator Name:  Philip Nienhuis Open/Closed:  * Open
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  10.1.0 (current default)
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 11 Apr 2024 07:06:12 PM UTC, comment #14: 

I understood your commit message in this way, but maybe was not able to summarize it correctly in my comment. With "settings object" I was not referring to the one global Qt settings, but to the local gui_settiings objects.

Torsten Lilge <ttl>
Group Member
Thu 11 Apr 2024 06:38:45 PM UTC, comment #13: 

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

John W. Eaton <jwe>
Group administrator
Thu 11 Apr 2024 06:15:26 PM UTC, comment #12: 

I am open to any other name of the variable. I came up to the one I have chosen having in mind what we intentionally would like to change.

From what I have read, Qt is using the application internally, e.g., for naming temporary files. It shouldn't affect something user visible.

Torsten Lilge <ttl>
Group Member
Thu 11 Apr 2024 05:37:06 PM UTC, comment #11: 

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?

Markus Mützel <mmuetzel>
Group administrator
Thu 11 Apr 2024 05:06:10 PM UTC, comment #10: 

I pushed cset http://hg.savannah.gnu.org/hgweb/octave/rev/f2314b4a9b1a

Now the environment variable OCTAVE_GUI_SETTINGS sets the application name in Qt and therefore the basename of the ini file in the platform depending location.

Torsten Lilge <ttl>
Group Member
Wed 10 Apr 2024 09:08:01 PM UTC, comment #9: 

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?

Philip Nienhuis <philipnienhuis>
Group Member
Wed 10 Apr 2024 08:36:37 PM UTC, comment #8: 

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.

Depending on an environment variable, one could change the application name, leading to a different file name of the settings file at the same location as the default file. But a completely different path can not be set.

Torsten Lilge <ttl>
Group Member
Mon 25 Mar 2024 10:32:43 AM UTC, comment #7: 

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

Philip Nienhuis <philipnienhuis>
Group Member
Mon 25 Mar 2024 08:15:28 AM UTC, comment #6: 

This might be a rather unusual use case: But I'm mostly running into this issue when switching repeatedly between Qt5 and Qt6 with the same source tree for testing.
Afaict, the changes proposed in comment #4 won't help for that use-case.

Having an environment variable that optionally overrides the path to the GUI settings file might help. If that we had such an environment variable, we could, e.g., set it in the `run-octave` script to point to a location in the build tree if Octave is run before it is installed. That would probably help with most of the issues I'm seeing personally.
I don't know if that would break the expected behavior for other developers though.

Markus Mützel <mmuetzel>
Group administrator
Sun 24 Mar 2024 04:49:29 PM UTC, comment #5: 

(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?

Philip Nienhuis <philipnienhuis>
Group Member
Sat 23 Mar 2024 06:39:19 PM UTC, comment #4: 

Then I suggest the following:

  1. Octave checks at startup for setting file octave-gui-XX.ini, where XX is the current major version
  2. If this settings file does not exist,
    1. Octave checks for other files of the form octave-gui*.ini and
    2. lets the user select one of the files for importing it as new settings file or continue Octave with the default settings creating a new settings file


Torsten Lilge <ttl>
Group Member
Thu 21 Mar 2024 10:43:49 PM UTC, comment #3: 

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

Philip Nienhuis <philipnienhuis>
Group Member
Thu 21 Mar 2024 06:54:09 PM UTC, comment #2: 

A downside would be that carefully selected settings, like, e.g., the editor styles are not available in other octave versions.

I would like to handle user defined settings files (per environment variable or per command line argument) differently from version aware settings files. In the latter case, what about still having one file but adding the version number to the names of potentially critical preferences, i.e. those that are internally processed by Qt like window or table view states (generally of type QByteArray)? In the derived settings class, the methods for reading settings could check for the version-matching preference name and take older or no versions as fallback.

Torsten Lilge <ttl>
Group Member
Thu 21 Mar 2024 03:03:05 PM UTC, comment #1: 

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.

Markus Mützel <mmuetzel>
Group administrator
Thu 21 Mar 2024 09:02:18 AM UTC, original submission:  

AFAICS all recent Octave releases use the same octave-gui.ini, at least on my Windows box (didn't check $HOME on Linux yet).

Now with Octave 9 and 10 on the same box, apparently using Qt5 and Qt6 resp. (?), the GUI opens with different window sizes and different window positions. OK, not quite a showstopper but I find it annoying.

Another motive is that with the dev version I use different GUI setups that I'd like to keep apart from regular releases.

So I'd advocate to be able to use different GUI settings files for each Octave release; perhaps at least for major releases. Or offer a setting (environment?) on where to store that settings file.

Or did I overlook that such an option is already present?
AFAICS it's not in the manual.

Philip Nienhuis <philipnienhuis>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by philipnienhuis (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-04-11 mmuetzel StatusNone Ready For Test
        Planned ReleaseNone 10.1.0 (current default)

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code