bugGNU Octave - Bugs: bug #55822, GUI settings files do not honor...

 
 

bug #55822: GUI settings files do not honor XDG_CONFIG_HOME environment variable

Submitted by:  Mike Miller <mtmiller>
Submitted on:  Sun 03 Mar 2019 10:08:48 PM UTC  
 
Category:  GUI Severity:  1 - Wish
Priority:  5 - Normal Item Group:  Feature Request
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  dev Operating System:  GNU/Linux

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Wed 06 Mar 2019 09:06:57 PM UTC, comment #13:

Sounds good, we can discuss on a new bug about making the GUI configuration conform to each platform's conventions, and whether we should keep the relative name "octave/qt-settings" or let Qt build the name (and whatever "application" and "organization" should be set to). That was also me on bug #40444.

I have tested the default branch and it works for me, XDG_CONFIG_HOME is used, even when it doesn't exist or is not writeable.

I think deciding on a new minimum version of Qt for Octave 6 should be brought on the maintainers mailing list. I'm fine with dropping Qt 4, and I'd honestly be happy with a minimum of Qt 5.6 or 5.9, but some Ubuntu users may want to see us keep supporting 5.5.

Mike Miller <mtmiller>
Project Administrator
Wed 06 Mar 2019 08:55:28 PM UTC, comment #12:

What would be the best solution then?

  • Let QSettings select the location and name of the settings file on each platform or
  • using QStandardPaths::GenericConfigLocation and using the current directory structure (octave/qt-settings) relative to this?

I propose to close this bug as XDG_CONFIG_HOME is honored now and open a new bug report about the gui looking for its configuration on typical locations on each platform. This would also follow Rik's suggestion to split bug #40444 into several parts (qt, pkg, startup etc.).

Finally, should we agree on requiring at least Qt 5.4 for the default branch?

Torsten Lilge <ttl>
Project Member
Wed 06 Mar 2019 07:03:59 PM UTC, comment #11:

I think using 'QStandardPaths::GenericConfigLocation' would also resolve bug #40444, because I think it is based on %LOCALAPPDATA% on Windows.

This all depends on a minimum of Qt 5.2 to work correctly (5.4 on macOS).

Mike Miller <mtmiller>
Project Administrator
Wed 06 Mar 2019 06:52:15 PM UTC, comment #10:

Torsten - I looked into Qt and it does support XDG_CONFIG_HOME in a couple places, if that makes things easier or more portable.

The QStandardPaths class honors it for ConfigLocation/GenericConfigLocation/AppConfigLocation. So for example 'QStandardPaths::writeableLocation (QStandardPaths::GenericConfigLocation)' returns XDG_CONFIG_HOME or ~/.config on GNU and Unixy systems, but it returns something else on macOS and Windows systems.

The QSettings class also honors it when building the implied paths when you use the alternative org/app constructor you mentioned earlier.

I think they both also support XDG_CONFIG_DIRS for reading settings from multiple system/user locations, as mentioned by Carnë, but that's a separate goal.

Mike Miller <mtmiller>
Project Administrator
Tue 05 Mar 2019 09:15:43 PM UTC, comment #9:

I have pushed cset http://hg.savannah.gnu.org/hgweb/octave/rev/05d492bb8ab8 (sorry, messed up the first line of the cset's comment), which changes the behavior described in comment #6 and comment #8.

Torsten Lilge <ttl>
Project Member
Tue 05 Mar 2019 06:23:23 PM UTC, comment #8:

I will update the use of XDG_CONFIG_HOME accordingly.

Torsten Lilge <ttl>
Project Member
Tue 05 Mar 2019 05:27:43 PM UTC, comment #7:

Thanks for reviewing Carnë, I agree, if XDG_CONFIG_HOME is set, Octave should use it unconditionally. I assume that QSettings will create the directory if it can when writing the settings, as it does today for the default path of ~/.config/octave. If XDG_CONFIG_HOME is set, there should be no fall back whatsoever to use ~/.config.

I agree about XDG_CONFIG_DIRS, but that seems like a separate project to allow reading settings in multiple locations, out of scope on this bug.

Mike Miller <mtmiller>
Project Administrator
Tue 05 Mar 2019 12:07:49 PM UTC, comment #6:

I took a look at the patch. If $XDG_CONFIG_HOME is defined, we should use '$XDG_CONFIG_HOME/octave' path even if it does not exist, and not fallback to '~/.config/octave'

Also related, there is XDG_CONFIG_DIRS to find system wide settings (which defaults to /etc/xdg/)

Carnë Draug <carandraug>
Project Member
Tue 05 Mar 2019 06:18:20 AM UTC, comment #5:

Changeset http://hg.savannah.gnu.org/hgweb/octave/rev/47bf66f0dc6b implements a check for XDG_CONFIG_HOME and sets the path of the preferences file accordingly. There are also other files used by the autocompletion feature of the editor stored in the same location. I am going to check the correct handling of these file next.

Torsten Lilge <ttl>
Project Member
Mon 04 Mar 2019 09:29:44 PM UTC, comment #4:

I do not know yet if XDG_CONFIG_HOME is respected by Qt. Qt offers to hard code a settings file location or chooses the location by itself depending on the platform and company/software name. To my knowledge this is already included for a long time.

You are right regarding the use of XDG_CONFIG_HOME, in this case, different setting sets are desired. This is not the case, when switching the default location of the settings file.

Torsten Lilge <ttl>
Project Member
Mon 04 Mar 2019 04:33:32 PM UTC, comment #3:

I'm not sure how Qt's standard way you are referencing addresses this, does it use the XDG_CONFIG_HOME variable internally? What versions of Qt is this available in? Does the file name or directory or on-disk file format change?

I think the correct behavior would be, if the user has XDG_CONFIG_HOME set, Octave should not look in the previous hardcoded location. One of the expected results of this is if I set XDG_CONFIG_HOME to an empty directory, Octave should start with a clean slate.

If you are introducing a new idea of also changing the relative path to the settings under ~/.config, maybe that should be discussed separately?

Mike Miller <mtmiller>
Project Administrator
Mon 04 Mar 2019 06:01:21 AM UTC, comment #2:

We could give Qt's standard way to determine the correct location of the settings file on the different platforms (https://doc.qt.io/qt-5/qsettings.html#QSettings-2).

The transient phase should then be handled like this

  • Check new location
    • If present we are done
  • Check old location
    • If not present create new file at new location
    • If present copy it to new location
Torsten Lilge <ttl>
Project Member
Sun 03 Mar 2019 10:35:08 PM UTC, comment #1:

See also related bug #36477 about using XDG mechanism to put Octave config files such as .octaverc in standard locations. There is als bug #40444 about putting config data under %APPDATA% on Windows platforms.

Rik <rik5>
Project Administrator
Sun 03 Mar 2019 10:08:48 PM UTC, original submission:

The GUI reads and writes its configuration files to files under ~/.config/octave, with no way to override that location.

According to the XDG spec, the environment variable XDG_CONFIG_HOME should be used by all applications as the base directory to write configuration files under, with ~/.config as a fallback default.

I'm marking this as GNU/Linux only, even though it also applies to macOS or any Unix system.

I think there are a whole different set of default user configuration directories and possibly environment variable overrides for those locations, so this is not applicable to Windows.

Mike Miller <mtmiller>
Project Administrator

 

(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 ttl (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-03-06 mtmiller StatusReady For Test => Fixed
        Open/ClosedOpen => Closed
    2019-03-06 ttl StatusConfirmed => Ready For Test
    2019-03-03 rik5 StatusNone => Confirmed
    2019-03-03 mtmiller Carbon-CopyRemoved 80942 => -

    Back to the top


    Powered by Savane 3.4