manyfold
                                
                                 manyfold copied to clipboard
                                
                                    manyfold copied to clipboard
                            
                            
                            
                        Define a standard for file/folder structure
So that one day we can auto-organise the files on disk, we first need a standard, or a few options for standards.
We need to decide:
- [ ] How to name model folders
- [ ] How to name part files
- [ ] How to structure folders within a model
- [ ] How to structure folders within a library, that contain models
I would love to get some examples from the community on how they structure their folders.
Probably the right thing to do is have a template string for defining the paths. So you would have a string for "model folder name" which could be something like {collections}/{name} - {creator}, and a string for part names, like {name}.{type}.
That way you can do things like {creator}/{name} to organise by who made the thing, or {creator}/{tags}/{name}, and so on.
Fields could be:
- {model_title}: The title of the model
- {part_title}: The title of the part
- {supported}: Supported or not?
- {collections}: A folder structure reflecting nested collection names
- {creator}: The creator name
- {format}: The file format (3mf, stl, obj)
Global options:
- separator: the character used as a separator between words
- case: whether path components should be lowercased, titlecased, left alone, etc.
Here's how Sonarr does it:

It also uses the parameters to handle capitalisation and separators:

So, we'd have fields for:
- Model folder format
- Part file format
Some wierd examples, perhaps?
- Model folder: {Collection_Tree}/{model-name} by {CREATOR NAME}
- Part file: {is_supported}/{File Format}/{PART NAME}
definitely use a configurable format.
So, part of this is done. Currently files can be organised to match a fixed format, which is something like {tag/tag/tag}/{model-name}#{model-id}. Next step would be to make this configurable per-library, as that's not always going to be what you want.
One thing to consider as you are working on this part is the interaction with the scanner.   Say you have a structure like:
{creator}/{collection}/{model_name}
Then if you add a new model in a new directory under that collection, the scanner should be able to automatically assign the creator and collection.
@ksuquix mm, good point!
Will the readme be updated with folder structure information? Dropping my whole stl file library into the /library makes a big mess right now and very hard to navigate.
At the moment it shouldn't be moving anything around unless you hit "organise files", and there's only one format based on tags. Once it's customisable properly it'll definitely get added to the docs, yes.
i tend to organinze my library by folders, i use them as catageories, and any sub folder within the parent is for depper classification, ie need to adjust, need to print, different versions etc,
To add another example - this is MediaMonkey (a Windows app for managing audio files). It's got a fairly powerful tag-from-filename functionality. https://www.mediamonkey.com/wiki/Auto-Tag_from_Filename

This is Sonarr's approach to file naming:
 
                                    
                                    
                                    
                                
I think maybe having a set of tokens, plus some options for "separator" and "safe filenames" might be good. Though perhaps those latter ones should only be added when actually necessary.
First off I love the software, you're doing a great job and I appreciate your work. I would say the current structuring is probably the biggest limiter to myself (and probably a lot of others) to really starting to use this software. I have a bunch of Patreons I support and a lot of them follow a similar folder structure, but very rarely is there a consistent naming format.
I would love to simply be able to view my models in a folder structure in van dam, basically the same as if you are using windows explorer w/ preview for images, but you have all of the models for that folder viewable. I think this would give folks a lot of freedom to structure things how they want without needed any super complex filename parsing logic. Bonus points if there was a way to interpret the pre-rendered img files and use them to "preview" whats in a given folder. Here is a horrible inspect-element mock-up of what it might look like:
 Basically a new tab in which it will show you all of the content under your "libraries" folder. Folders are shown as a default folder image and open-able just like a normal file explorer. Like mentioned above, you could build in logic to interpret X image name in a directory to represent the parent directory like shown in Creator C (e.g. a logo for a creator folder, or a pre-rendered image for a release/object folder), then the explorer will only show folders and stl files. Stl files would be shown similarly to today, where you can open them, download, etc.
Basically a new tab in which it will show you all of the content under your "libraries" folder. Folders are shown as a default folder image and open-able just like a normal file explorer. Like mentioned above, you could build in logic to interpret X image name in a directory to represent the parent directory like shown in Creator C (e.g. a logo for a creator folder, or a pre-rendered image for a release/object folder), then the explorer will only show folders and stl files. Stl files would be shown similarly to today, where you can open them, download, etc.
@DougTheDruid thanks for the idea! I'm only just really learning how people want to use the software, so all this really helps! Could I get you to add your comment as a new issue instead? That will help me organise it more easily and not let it get lost inside another issue, I think it's important enough to have its own 👍🏻
Ooh actually github has a new button, I'll see if I can do it myself...
Customisable file/folder structure is now released in v0.42.0! 🎉