[Task]: Introduce Independent TagStudio Data Folder Option

[CyanVoxel]

Checklist

• I am using an up-to-date version.
• I have read the documentation.
• I have searched existing issues.

Description

This issue aims to coordinate efforts to introduce a new TagStudio data folder structure in addition to the current .TagStudio data folder method with the following additional benefits:

• Independent data location from library contents
• Multi-root folder support (technically can be brought to existing libraries, but it would be weird)
• Custom library name (likely brought to existing library type as well)

Solution

When creating a new TagStudio library, the user could be presented with two options:

Current/Simple/"Vault-Style"/Embedded

"Your TagStudio library data lives inside an existing folder with your content. Only content in this folder is included in your TagStudio library, and moving the content folder keeps your TagStudio data with it.

You can choose to convert to an "Independent" library style at any time."

• The .TagStudio folder is treated as the library folder.
• Library contents are read from the outer folder.
• A folder and its contents are effectively "opened" as a complete TagStudio Library, similar to an Obsidian vault.

Content Folder/
├─ .TagStudio/
│ ├─ ts_library.sqlite (references outer folder only)
│ ├─ .ts_ignore
│ ├─ backups/
│ ├─ macros/
│ ├─ thumbs/

New/Advanced/Independent

"Your TagStudio library data is stored independently from your content folder(s). This option lets you specify multiple content folders as sources for your library, but moving or renaming these content folders will require you to re-link them inside the app. Moving the data folder itself will not require a re-link."

• A custom location is specified for the library folder.
• Folders for library contents need to be manually specified.
• An independent save folder is used to store all TagStudio save data that references a particular set of content folder(s). Can be thought as similar to a Minecraft save folder, if you want.

Content Folder 1/
Content Folder 2/
TagStudio Data Folder/
├─ ts_library.sqlite (references specified content folders)
├─ .ts_ignore
├─ backups/
├─ macros/
├─ thumbs/

As you can see, a lot of the terminology I have in mind is up in the air. There should be a clear distinction between a "TagStudio library data" folder and "library contents" folders going forward, while also not stirring up confusion for the existing structure. Specific terms can be decided upon in time.

Alternatives

• If the .TagStudio folder was retained for root libraries outside of the immediate outer folder, it would lose portability with the illusion of keeping it and only raise confusion as to what content is explicitly added and what is implicitly added.

• If all libraries are forced to use the independent folder system, then the benefits of keeping a .TagStudio folder inside the contents folder is universally lost for nothing but the sake of consistency.

[Computerdores]

Why not just add multi-root support to the existing system? The idea would be:

• the sqlite db already has a table for all roots
• the .TagStudio directory in the first one can just be the save location by default[^1]
• one TS close we make a backup of the DB to each root directory (except the one with the original DB)
  • promise of "move root and keep tag data" is maintained for all libs
  • storage impact is minimal (1.4M for my largest lib)
  • if user wants to save storage we can make it configurable with warning
• any one who wants can just move the .TagStudio directory somewhere else, optionally rename it, and open it normally
• completely transparent for the user

Doesn't this have all the above advantages, while being more flexible and having better reliability?

[CyanVoxel]

Why not just add multi-root support to the existing system?

I'm against the idea of having a single data folder paradigm that combines an implicitly declared content folder (i.e. the outer folder of a .TagStudio directory) with explicitly declared external content folders.

The current "Obsidian vault-style" method of having a hidden .TagStudio data folder inside of a single content folder works well for having a single content folder, but that paradigm raises confusion when the behavior is mixed with also being able to asymmetrically connect external root folders:

• Why would moving a .TagStudio data folder cause some content folder sources to break, while one source has different behavior and changes to suck in new content adjacent to the new .TagStudio folder location?
• If wanting to have the data folder separate from your content, why is there now a "secret" behavior that any files adjacent to your .TagStudio folder being added as content in your library?
  • And if a user wants to have a libraries stored like this, wouldn't it make more sense to allow a system where a folder with an arbitrary name can contain the ts_library.sqlite and related files instead of having to have a confusing "My TagStudio Library/.TagStudio (hidden folder, remember)/actual data files" structure?

Both the implicit behavior of adding library contents using the .TagStudio folder placement and having multiple content roots declared separate from a TagStudio data folder are useful features, however I feel that combining those behaviors only raises confusion that can be avoided with having two distinct data folder structures.

the sqlite db already has a table for all roots

This table is leftover from an unfinished and unknown implementation that was closed, and should be ignored as a planned implementation. And regardless, the database file will not be different between the current and proposed data folder structures.

the .TagStudio directory in the first one can just be the save location by default

See my issues above with mixing implicit and explicit behavior

one TS close we make a backup of the DB to each root directory (except the one with the original DB)

Saving multiple copies of the database folder does not pass the smell check as a solution to me (I'm also not quite what problem it's trying to solve)