Comment 49 for bug 671632

I use SmartGit, which has such a subdirectory view button for the file system folders and I agree that this can be a usability issue, especially if you assume the button is enabled but it isn't .

An other question is: Is the recursive view always desired? If a user just needs a virtual file system like folder structure, it might be not.

If we, disallow to add a track to a folder, we will face the issue that the user tries it anyway. What should happen?
Should we instantly create the root crate for him?

We will also face this issue that a user tries to add crate to a crate. What should happen. Should we move the target crate as root crate to a new folder and add the dropped crate as sibling?

All these automatics sound a bit scary. But we will need theme if we permit to add a track to a folder, since this is what the user knows form a file system and what he probably expect from such Mixxx crates tree.

Since we can have different appearences with the same database schema, it looks finally like an issue how to switch between flat and recursive view. Some Alternatives:
* Switch by a a tree view item: root crate item -> flat view / folder item -> recursive view
* Switch by a a tree view item: folder item with tracks -> flat view / special recursive item -> recursive view
* A context menu entry: to switch the view mode for each folder
* A global switch

We are able to introduce one of these options later, even if we follow the "crate contains tracks and crates" internally.

@Vladimír Dudr:
What are your preferences for a recursive solution?
Since you now prefer the "crate contains tracks and crates" model, how about implement just this and add the recursive feature later?

Any other thought?