There was a discussion on Hacker News regarding programs that store their settings in the user directory. The argument is that the top level of the home directory is for user files, not program files. Where programs need to store user-specific settings, they should use platform standard locations to store them, such as ~/.local/config/ on Linux.
LibrePCB uses a visible workspace that the user may place anywhere, but the default is directly in the home directory. I wonder if LibrePCB really needs to (1) have a non-hidden workspace at all, and (2) use a user-defined location instead of a platform standard location for settings, somewhere hidden. These settings are anyway intended to be set via the GUI, not by editing the text file. Why can it not just use the platform standard locations for settings, cache, etc., and let the user host projects and libraries wherever they like? Given that LibrePCB makes a big deal out of making saved files compatible with version control systems like git, then it seems like the workspace is a bit useless anyway - and needn’t be visible to the user.
So, what was the reasoning behind having a visible workspace to store everything?
Many if not most designers wind up working on multiple projects at the same time. You need to give each project its own workspace to isolate each project from all the others.
If you are maintaining a library then you need to have one workspace with R/W access to a repo and others with a Read only access copy to test code using the existing code.
From the documentation it sounds like it’s actually supposed to be a global place to store all of your projects under, a bit like Arduino’s workspace. It says “The Workspace is just a directory where settings, libraries and (optionally) projects will be stored”. That implies that the intended way to use it is to have multiple projects in the same directory unless they conflict. Or not?
I wonder if it would be better to have something akin to how e.g. Visual Studio Code does it (but also many other programs), with a global user settings file in the home directory (in the relevant platform standard location), and a hidden project settings file in each project directory that allows the user to override individual settings in the global one. This project-specific settings file could also reference any libraries required for a particular project, which should be in separate project directories (and separately versioned by e.g. git).
Even better: have all of the standard parts libraries explicitly defined in the global settings file (or in a file referenced by that settings file, e.g. parts.conf.dist), allowing users to build their own global settings file that removes or replaces the bundled LibrePCB parts. This could allow companies to force projects to only use their own self-made libraries.
LibrePCB’s typical use case will be a single designer who has sole control over a number of different projects but we must make sure that it can also support group design.
With a design group you have a number of designers who have all cloned the same project repo into a workspace and everyone is working on a different piece. As designs are completed they are checked back into the repo so that everyone can check their code against the latest work.
In this environment you will always have two copies of your own code. One matches the official repo that you use to stay in sync with all the system level stuff and the second is your work-in-progress where you design and test your code before checking it into the repo.
You update every day and verify that nobody made any changes that broke your design before rechecking that your work-in-progress still works with the official repo. Then you quickly check in all of your changes before something else changes that would require you to merge your changes in with someone else’s changes.
It can be a real zoo and you need complete isolation between all the different environments that you are working with. Always pulling common files from a cached store doesn’t work when you need to update those files.
LibrePCB also does this, user-related settings (like window positions or the path to the recently opened workspace) are stored in the platform’s standard config location.
The workspace itself is not considered as “user settings”, thus is isn’t located in the config directory.
Basically the idea is to have a complete “environment” for working on LibrePCB projects contained in one directory. But it doesn’t contain any workstation-specific settings (like saved window positions), these are located in the user’s config directory, i.e. outside the workspace.
The advantages of that concept are:
A workspace is 100% portable between different systems:
When set up a new workstation, you only need to copy the workspace from the old workstation to the new one, and you are ready to continue working on the new machine.
On a dual-boot system, the workspace can be shared between both operating systems. No need to synchronize libraries, projects and workspace settings manually.
Same for virtual machines. Just set up the workspace as a shared folder with the VM and you have all libraries etc. shared between both systems.
When using the same computer at home and at work, you can create one workspace for private projects, and one for commercial projects. So, at work you have all the company libraries (e.g. the API URL set to a company-internal server) and all company projects. And by simply switching to the other workspace, you have all the community libraries from api.librepcb.org and all your private projects. As settings like measurement unit (metric/imperial) are stored in the workspace, you can for example even use metric system at work, and imperial system at home.
Of course there are also other use-cases for separate workspaces possible. Instead of separating private/commercial development, maybe someone wants to have separated workspaces for some other reason, although I think most of the time one workspace should be sufficient…
If someone isn’t happy with the visibility of the workspace, he could of course just store the workspace at ~/.config/LibrePCB/workspace But I don’t like to set this as default location, because IMHO projects and libraries aren’t user settings.
LibrePCB actually doesn’t bundle any libraries, thus I don’t get your point here
Thanks both for the clarification, I think given what you said that LibrePCB’s approach is fine
One thing I’d suggest though is that the documentation is updated. The sentence “The Workspace is just a directory where settings, libraries and (optionally) projects will be stored” is confusing given that some (user) settings are stored elsewhere, and that the user can create many workspaces. Here’s my attempt (but probably needs tweaked): “The workspace is just a directory to contain the files and libraries for one or many projects. You can share your project by sharing its workspace, and you may create multiple workspaces to keep multiple projects nicely separated.”
@ubruhin: I can’t work out how to send a private message, but are you anywhere near Hannover? We’re looking for a replacement for EAGLE long term at my research institute but have some very specific requirements for the software. We’ve modified EAGLE pretty heavily to make it work the way we need, and this is best shown in person…
But I don’t like to set this as default location, because IMHO projects and libraries aren’t user settings.