[Feature Request] Libraries
Opened this issue · 5 comments
Libraries would be a great way to organise tagged files via a special kind of tag
If we were to view it as a file structure, libraries would be at the root. For example:
├── Camera Roll
│ ├── queries
│ └── tags
├── Cute Animals
│ ├── queries
│ └── tags
├── Memes
│ ├── queries
│ └── tags
└── Movies
├── queries
└── tags
Viewing all files with the tag dog in Camera Roll won't show any files with the same tag in Cute Animals, and movies tagged star wars won't show up when searching for star wars in Memes
In addition to this, some libraries should be hidden like .files
For backwards compatibility, perhaps an "All" library should be added, which just contains everything across libraries (unless it's a hidden library?)
EDIT: Others have pointed out that this might be good as an extension of the query function
Yeah, this unlikely to happen. It's just not very intuitive. Better, as you suggested, would be to have a way to get a tags view from beneath a query, e.g. with reserved words such as mnt/queries/red or blue/tags.
Yep, this sounds like a generic "saved queries" with an assigned label to such query. IMHO a useful functionality.
Yeah, this unlikely to happen. It's just not very intuitive. Better, as you suggested, would be to have a way to get a tags view from beneath a query, e.g. with reserved words such as
mnt/queries/red or blue/tags.
I don't think it's at all unintuitive. But if you think that's a better implementation, then that's fine with me
if I understand this correctly, your idea is like having one tmsu database for each 'library' (except things like tag and value names are shared). Also you are particularly focused on using VFS mount points.
If this is an accurate summation, then I sort of agree with Paul on 'intuitiveness'. For example, the 'only in one list' constraint you state. that seems to me to be importing file system weirdness that TMSU wants to get away from, such as 'I want this one image to be in 'cute animals' and 'meme', even if I don't want other images that technically qualify to be in both'.
I believe I solved a similar problem. don't have the time to go into detail, but, making 'libraries' into 'filelists' (not associated with the database specifically, for complexity reasons) and having tmsu provide a function - say 'tmsu filter', which accepts a filelist on stdin and standard 'tmsu files' query as arguments. This function would simply run the query and return those files which match the query and are also in the filelist, in the order the filelist specifies.
( this is not trivial to script, mainly because tmsu returns relative paths when it can, rather than absolute paths always)
That could , afaics, be exposed in the vfs, but I don't have the time to expand on that. hth.
if I understand this correctly, your idea is like having one tmsu database for each 'library' (except things like tag and value names are shared). Also you are particularly focused on using VFS mount points.
Or just separate tables. Or a "special" tag. I'm not sure how It'd be done in the back-end.