Rack: Use proper local and global directories on each OS

[AndrewBelt]

• [x] Windows local: My Documents/Rack/
• [x] Windows global: ./
• [x] Linux local: ~/.Rack/
• [x] Linux global: ./
• [x] Mac local: ~/Documents/Rack/
• [x] Mac global: $BUNDLE/Resources

If Rack is compiled from source (without RELEASE=1), it will use ./ for everything on all OS's.

Objections/suggestions?

[antoniotuzzi]

and
/usr/share/Rack/
/usr/share/Rack/plugins/
for plugins shared to all the accounts?

[AndrewBelt]

There's a local and global directory in Rack's asset.hpp. That would be a good global directory.

[Strum]

please allow an option for people to not use the default directories

personally i would prefer that anything related to rack be kept in the rack folder or just let the user choose locations for files, anything but have it put things in the windows documents tree by default.

[Strum]

Personally I prefer software that does not involve itself in the operating system any more than it absolutely has to.

A program should be able to be zipped up into a file copied to another computer and run as is without an installation process.

[Strum]

one of the reasons i don't use linux is because files from programs end up all over the place and it's impossible to keep track of it all or change anything without being a linux expert.

[Strum]

I like large statically linked binaries that store all their settings and anything related in the one tree not spread out all over the system.

My 2 cents worth anyway.

[AndrewBelt]

The "dev" build will always do this, but the distributable from the website will need to install itself and use proper locations. I get way too many supports emails from people that have messed up their Rack installation because they try to merge things that shouldn't be merged, so this has to change.

Example: #268

[antoniotuzzi]

my proposal
MAC:
the $BUNDLE/Resources for MAC should never be touched, and probably on many system will be unaccessible because not admin
$BUNDLE/Resources should contains only the plugins shipped with the application (in this case, only Fundamental)

the correct place for the global dir is /Library/Rack
(and maybe for the plugins, locals should be ~/LIbrary/Rack/plugins leaving Documents/Rack only for the "Documents"... (vcv files) )

[AndrewBelt]

@antoniotuzzi Yes, the "global" location is read-only. The "local" location is read/write. So it should be $BUNDLE/Resources.

The only issue I have with ~/Library/Application Support/Rack is that it's hard to access and I'll get 100 emails about "WHERE IS THE FOLDER TO INSTALL PLUGINS".

[sbcook0]

On windows, if the global data is visible to the user should it go in C:UsersPublicDocuments otherwise it should go in C:ProgramData

It think it might be a good idea to use VCVRackRack instead of just Rack as the final folder because Rack is a little too generic and refers to the product not the manufacturer. So the full paths would be C:UsersPublicDocuments VCVRackRack and C:ProgramDataVCVRackRack.

[AndrewBelt]

Good suggestion on the Program Folders path. Although I think Program Files/VCV/Rack would be better. That will be the global location by the way, where Fundamentals and ComponentLibrary SVG files live.

[sbcook0]

I misunderstood what data was going in the global folder. If these are binaries that make up the program then "Program Files" is the appropriate folder.

[AndrewBelt]

Not really binaries, but read only graphics and Fundamental plugin as mentioned above. Basically just anything that shouldn't need to be overwritten except when installing.

[AndrewBelt]

5/6 of these bullet points are fixed with fb6e073

Still unsure about the Linux global dir. I'd have to distribute .deb, .rpm, and maintain an AUR package if I require that the global directory is /usr/share/VCV/Rack or something. So I'll leave it as ./ for now.

[AndrewBelt]

@w3stgaard in another thread wishes for a way to set the local directory to ./ on Windows. However, I cannot think of a good way of doing this besides providing a second Windows release build, which is too much hassle to be worth it. The development build (i.e. compiling without VERSION defined) uses ./, but he's requesting that a condition be added to the release build to switch to ./

[AndrewBelt]

After #444, there is no longer a reason for Rack's local directory to be visible, so I will hide them by putting them in Mac and Windows' "application folders".

[s-ol]

As far as I am aware, on Linux the usual standard for directories would be the XDG Base Directory Specification. Cluttering the home directory with dotfiles seems to be 'old fashioned' to me, i remember projects like i3wm making the switch.
That would be $XDG_DATA_HOME/Rack or $XDG_CONFIG_HOME/Rack (with a fallback to ~/.config/Rack according to the specification).

This isn't critical at all since many packages don't implement it (i guess mostly for historical reasons) but would be nice to have for the next major milestone IMO.

[AndrewBelt]

@s-ol Rack's local directory stores more than just a config file. I have 225 dot folders in my home directory, so using ~/.Rack is normal practice.

[AndrewBelt]

Decided that the way we have it is the way it should be. Finally closing!