Models in subdirectories are created at root level instead of in their parent directory

[mattpage]

Here you can see that I have a bases directory containing a directory and a few subdirectories:

If I add the bases as a library and wait for the scan to complete, this is the result:

I would expect that both round and square not be visible at the top-level and instead be within the 25mm directory.

For much busier libraries this means that top-level library is crowded with tiles that don't make much logical sense.

I propose that we honor directory structure and nest items in their parent directory.

[Floppy]

The current library structure is flat, as you point out. There isn't any concept of nesting for the models, everything just appears in one list. I'm thinking of changing libraries to a more general "collection" concept, and then making those nestable, at which point they could be generated automatically from the directory structure.

[mattpage]

What do you think about making the organization structure optional? We could keep the "flat" structure by default, but add a "nested" option as an alternative. The latter fits my current file organization, but maybe others prefer the flat approach 🤷 .

[Floppy]

I think having nested collections is a pretty natural thing, and will help navigation, so I don't think we need to keep it flat by default - it could be a view option though, like in Plex where you can have it list the collections, or just list everything in them all in one list.

[Floppy]

I'm going to close this issue if it's OK, as I think it will be covered under #459?

[mattpage]

Hey @Floppy Sorry to raise this issue from the dead, but I may have a simple solution.

Since Library and Models have paths, what if we modified Library#Show to only display models where the model path was a direct child of the library path?

So for my example above where I have a library named "Bases", when you are looking at the bases library, it would only show the models "20x20.stl", "25mm" (a folder) and "30mm_base.stl". It would not show "round" or "square" because their path is not a direct descendent of the library.

We can still do collections, but this would ensure that hierarchy is presented correctly for nested folders as well as collections.

[Floppy]

Perhaps... where would you show the round and square models? As a model listed within the 25mm model? Actually, as well, currently your library wouldn't show the files in the root - they're ignored, as they're not part of a model.

I think this comes down to the fundamental idea of what VanDAM considers to be a Model, which is at the moment, a folder that contains 3d or image files (which are ModelFiles). The root files are ignored as they're not part of a Model within the library, they're just at the library root. As models aren't nested in the database, a model folder can include other models - currently those are flagged as submodels and presented as candidates for merging.

There could be a lot not right about this, it's just how it's built up over time, and it probably includes a lot of assumptions from my own personal way of organising my library.

It might be time for some strict definitions of these things, so that we can explain them clearly to users. I think even the "muliple libraries" concept is a bit confusing, as well.

[mattpage]

So to simplify things, you are thinking that we create "Collection" as a model? I assume it would represent folders and potentially an arbitrary assortment of models (a virtual folder). I could see modifying the library scanner to create Collections when it encounters subdirectories of a Library (the main collection, if you will). Does that about capture it?