Changing themes requires Marta restart if conf.json is symlinked

[IgorKrupenja]

1. Move conf.json from the default config folder to some other folder.
2. Symlink conf.json back to default config folder.
3. Open Marta: it will launch just fine with settings correctly picked up from the symlinked conf.json.
4. Now edit conf.json and change theme.

Marta theme stays the same until you restart it. If conf.json is not symlinked, theme change is instant with no restart needed.

[yanex]

Since 0.6.1, the recommended way to configure Marta is to use the embedded configuration editor. It supports symbolic links and preferences re-loading, so I think this issue can be postponed. If you can't use the embedded editor for some reason, please create a separate issue.

[haakonstorm]

Regarding symlinked settings:

Today the two configuration files conf.marco and favorites.marco are both in ~/../org.yanex.marta/

This means that you have to choose between:

1. two symlinks: a symlink links directly to a file, OR
2. one symlink: symlinking the enclosing folder, creating a redirect for both files at the same tim

Only symlink folders, not directly to config files

You could try a Marta test build with a split to different folders, example:

• ~/../org.yanex.marta/user/favorites.marco and

• ~/../org.yanex.marta/local/conf.marco.

Instead of symlinking to the file itself, symlink instead to the folder containing the config file.

• For various reasons, setting everything up like this will probably evade all the issues people have with symlinked configuration files, as well as:
• enable domain-based configuration (see below).

Domains: Factory > Local > Cloud > User

Consider the following alternative configuration hierarchy:

• Factory Marco.app/conf/Library/config.marco Marco.app/conf/Library/favorites.marco

• Local /Library/Application Support/org.y.m/config.marco /Library/Application Support/org.y.m/favorites.marco

• Cloud ☁/Library/Application Support/org.y.m/config.marco ☁/Library/Application Support/org.y.m/favorites.marco

• User ~/Library/Application Support/org.y.m/config.marco ~/Library/Application Support/org.y.m/favorites.marco

Added bonus

• By splitting up the configuration based on domain you get a configuration hierarchy effectively mimicing the macOS domains.
• This means you e.g. can have a default setting for dateFormat in the System-domain, and so:
  • If dateFormat is set in the Local domain it is applied to all users of device
  • If dateFormat is found in the Cloud domain, it is applied.
  • If dateFormat i also found in the User domain, this takes top precendence.
  • If dateFormat is not found anywhere or is invalid; the Factory domain default setting is set.

macOS Priority	macOS Domain	Folder	Marta config	Marta priority	Marta Domain
1.	System	/System/Library/	Marta factory configuration	4.	Factory
2.	Local	/Library/	Marta config for all users on local mac	3.	Local
N/A	N/A	N/A	Current logged-in user config - for all accounts	2.	Cloud / iCloud
3.	User	~/Library/	Current logged-in user config - on this local account	1.	User

Favorites.marco

• This file will contain shortcuts to folders made on a specific mac, and some of them will not resolve on another mac with a different folder structure.
• Therefore being forced to choose between symlinking both configuration files at the same time, makes it more difficult to have different Favorites for different macs.
• I assume most people would prefer having as many favorites as possible be the same across their different macs (and iPads - Marta needs an iPadOS counterpart).
• Having multiple domains solves this, as the settings in the Local, Cloud and User domains will easily be merged with implicit sync conflict resolution based on the domain hierarchy.