"etc" was meant to refer to any other Octave settings I may have missed -what is it- 6 years ago. GUI settings come to mind (I think these are stored on %APPDATA% now).

Markus, thanks for taking care of this after I dropped the ball.

This one is indeed more of an umbrella issue, since it encompasses reading and saving configuration (now complete I think), but also history, and maybe package installs with -local. IMHO this bug should be closed in favor of more specific bug reports about a new default history file, a new default -local package prefix, and so on.

@Mike:
Sure I'll help. On which of the various bug reports do we continue discussion? (and maybe we'd better close all the other ones then, it's hard to follow a "distributed" discussion.)

Do you want to test "file #46450:  xdg.patch" in bug #36477/ after fixing therefs to APPDATA / app_data? Markus Muetzel already reported there.

One more vote for config going in %APPDATA% here. Speaking as someone who's worked in university computer labs and large businesses, your users really want that app config to be roaming.

From what I've seen, Windows apps generally store config data in %APPDATA%, and app cached data in %LOCALAPPDATA%.

Mike wrote:

> If a user saves their startup path to octaverc (e.g. with 'savepath'), that might include local directories and drives that are only present on one system. That should only happen in a local configuration file, not a roaming file.

In an institution/IT environment that has roaming profiles, the onus is on a combination of the users and IT staff to not do this. The user profile is configured to set up drive mappings so there is a consistent drive letter environment for the user across machines. Users are trained to stick with those commonly-available drives, and when something breaks due to them using a local drive, a quick conversation with IT will clear it up (usually ending in "don't do that").

> If Octave supports reading octaverc from %APPDATA% only, how would you add a startup configuration that only applies to one machine?

Add this to your roaming octaverc:

my_local_octaverc = [ getenv('LOCALAPPDATA') '\Octave\octaverc_local' ];
if exist ( my_local_octaverc )
  run (my_local_octaverc)
endif

Same trick that bash users do to have machine-specific bashrcs when they have a synced ~/.bashrc.

@Mike: I can surely follow your logic but I'm wondering how important or serious the issue you bring up is.

In networks / domains with roaming profiles, one usually has no "individual" PCs where a specific location either exclusively exists or isn't available. I suppose most IT depts. go to great lengths to make work environments independent of location and/or specific clients.
I can think of laptops that can connect to a network where the scenario you bring up may lead to issues, but then again a user would (should) know what the cause is and act accordingly.
And AFAIK savepath can be given a filename to save the path to.

AFAIK the main difference between Appdata\Local and Appdata\Roaming is that the former has a .\Temp subdir for volatile files.

The comparison of QStandardPaths is convincing. But then I don't get why QSettings uses %APPDATA% or ~/.config but in QStandardPaths, ~/.config and %LOCALAPPDATA% have the same purpose. IMHO, this is not consistent.

Thanks for the info and the references. Based on that and on the Windows article, I still think that %LOCALAPPDATA% is a better first target for where to read octaverc from.

If a user saves their startup path to octaverc (e.g. with 'savepath'), that might include local directories and drives that are only present on one system. That should only happen in a local configuration file, not a roaming file.

I am also trying to reconcile this with best practices. One example is the Qt QStandardPaths class (https://doc.qt.io/qt-5/qstandardpaths.html), which maps various system conventions to a standard enumerated type. According to QStandardPaths

• AppDataLocation == %APPDATA%/AppName
• AppConfigLocation == %LOCALAPPDATA%/AppName

On a GNU system

• AppDataLocation == ~/.local/share/AppName
• AppConfigLocation == ~/.config/AppName

In this context, "app data" to me means things like icons, themes, fonts, compiled search databases, email folders, various kinds of internal storage or generated files. OTOH "app config" means configuration files that users should be able to edit and customize to configure the application for their local environment.

If Octave supports reading octaverc from %APPDATA% only, how would you add a startup configuration that only applies to one machine?

I am leaving open the possibility that Octave could read octaverc from both locations eventually, but for now I think %LOCALAPPDATA% is a good first target to aim for. Can you test my patch on bug #36477?

On most Windows 7+ systems software settings and init files are stored in %APPDATA% (which usually points to %USERPROFILE%\Appdata\Roaming) rather than %LOCALAPPDATA% (which points to %USERPROFILE%\Appdata\Local).

I think ...\Appdata\Roaming is a better choice because e.g., company networks usually make use of roaming profiles anyway so users can have their favorite Octave settings anywhere, and for isolated pc's (and home networks) there's no functional difference between Appdata\local and Appdata\Roaming. More info here:

https://docs.microsoft.com/en-us/windows/uwp/design/app-settings/store-and-retrieve-app-data

https://www.howtogeek.com/318177/what-is-the-appdata-folder-in-windows/

Just a cross-reference note: there's also bug #44548, which is discussing where `pkg` installs its per-user stuff, which is a similar concern. There are roles for both %APPDATA% and %LOCALAPPDATA% here.

I think this bug's discussion is probably right in that Octave config settings, and perhaps command history, should go in the user's roaming profile in %APPDATA%. Installed programs and data files should probably be computer-local and go in %LOCALAPPDATA%, and that database shouldn't be shared. Sharing command history files is problematic, though, since they change often and there's no merge logic for them; most systems I'm familiar with store those machine-locally. So .octave_history should probably go in %LOCALAPPDATA%.

One note: whatever you decide, you shouldn't locate these directories by looking at %USERPROFILE%. The AppData and AppDataLocal directories and other special Windows shell folders can be "relocated" independently of the root folder for the user profile. Use %APPDATA% to find the Roaming Application Data directory and %LOCALAPPDATA% to find the Local Application Data.

Agree with Philip's last comment, this should be solved the same way for both GUI and CLI. So this should probably depend on a new library routine that declares where configuration files and history files are stored. This routine should be callable for all operating systems and return the appropriate directory for Unixy systems (based on XDG_CONFIG_HOME) and for Windowsy systems (based on APPDATA).

Adding dependency on bug #36477.

Concerning the configuration file, the default behavior of qt is to put the file into the "standard location" on each platform as described here: http://qt-project.org/doc/qt-4.8/qsettings.html#platform-specific-notes
Switching to this default behavior should not be very difficult.

As regards the history file, this can easily be fixed in octaverc (main-rcfile), so I've prepared a changeset for that. (I've used a similar fix, with no error catching, for years at work)

Patching the Qt GUI setting files is beyond me :-(


(file #29527)