add multi level crate support

This can be realized as soon as we merge the Traktor library feature.

Hey Mika,

I am happy to see that you've implemented a branch for the wishlist report.

Could you just tell me your current status? Commit r2720 states that your branch is still buggy. If you have any issues, questions of if you need help let me now... I really want to have that feature in Mixxx 1.11.

On Sunday 17 April 2011 15:04:39 you wrote:
> Could you just tell me your current status? Commit r2720 states that
> your branch is still buggy. If you have any issues, questions of if you
> need help let me now... I really want to have that feature in Mixxx
> 1.11.

Hi,

Sorry for being idle on this. I've been terribly tired lately and haven't been
able to work this much after r2720. What's the deadline for 1.11? I'm sure we
can make it by then. I'll try to find some time for this.

I have added a column in the crate table for parent crate id. Creating a child
crate from context menu (right-click on the parent crate -> "New crate")
creates the db entry correctly.

There are some problems in constructChildModel() . If I remember correctly,
r2720 sorts crates in reverse order. Also contructing child model seems to
work (at least almost as it should) only when mixxx in (re)started. When a new
crate is created, the crate tree looks quite weird.

QModelIndex stuff is new to me, so any help and tips how to fix these issues are
welcome.

Hey guys, there's some stuff in my branch. You might want to have a look and test it. I spotted one minor bug: when a subcrate/playlist is deleted, its parent gets focus in the tree view, the the table view still shows contents of the deleted crate/playlist.

I'd like to hear some opinions how locking should behave with multilevel items (might need some fine-tuning here). The current implementation prevents deleting a crate/playlist if it or any of its (grand)parents or (grand)children are locked. Would it be better if parent items could override subitem locks? On the other hand, this could cause some unwanted deletions if users trust that locked crates cannot be removed.

Tested your branch and would not change the current behavior. Parent items should not override subitem locks. We have no undo function, so safety first.

To increase convenience I could imagine to have two more options in the mouse menue for parent items: "Expand all" and "Collapse all". This would save the time to manually expand all subitems in order to check where a locked sub-sub-item is hiding. Once all subitems are expanded, it is easy to localize locked ones as they have a special icon.

Thanks for your work!

Hi jus, thanks for testing.

> Tested your branch and would not change the current behavior. Parent
> items should not override subitem locks. We have no undo function, so
> safety first.

Makes sense. So be it.

> To increase convenience I could imagine to have two more options in the
> mouse menue for parent items: "Expand all" and "Collapse all". This
> would save the time to manually expand all subitems in order to check
> where a locked sub-sub-item is hiding. Once all subitems are expanded,
> it is easy to localize locked ones as they have a special icon.
>

Sounds good. I'll implement that too.

Hi
Showing support to this feature, any plans to release it with the incoming 1.11 version? How the works goes?. Keep good work guys.

Some news related into this?

I was looking into this idea recently too.
I think a better paradigm would be to make it possible for crates to be included in more than one parent crate.
Not only is that more convenient, but it would also obviate the problem with sub-item locks.

I'm working on some other crate-related issues right now; hopefully I can get to this soon.

Finally some news!. I have subscribe myself to this thread to know all news here. If you need a tester for this feature i'm here, keep good work!.

+1 for Stevens Idea

Unassigned Mika, to free this bug for a new assignee.

@Mika, It would be nice if you adopt it again, if you find time!

https://code.launchpad.net/~mhaulo/mixxx/multilevel_crates_playlists/+merge/62378/comments/361999

So no one is currently working on this?. Bad news..., it is a pity i do not nothing about programing...

Taking this off the 1.12.0 milestone until we have someone assigned.

ahhhh bad news :(

Could someone describe what this implements? Is this just grouping of crates or it also modifies a crate tracks depending on the ones on its parent?

I've downloaded the code and when I try to create a crate I get a dialog saying: "An unknown error occurred while creating crate: New Crate".

finally some movement here, still waiting for someone who can implement this feature!!

Hi infarmer, could you please describe me how do you exactly expect this feature to behave? I don't really understand what is it supposed to do, and it might (or might not) be related with a GSoC proposal for smart crates I'm working on.

Hi, my english is not good, anyway... what we are asking here is a more flexible way to organize big colections of music, in my job the list we are using now have about 7000+ songs, and growing. I will try to explain the feature here by a graph, if still you have doubts, i will try another way or something:
I will try to explain you with examples:
***********************************************
Rock
  |---Symphonic
  | |-------Song 1
  | |-------Song 2
  | |-------Song 3
  |---Hard
        |-------Song 1
        |-------Song 2
        |-------Song 3
**********************************************
2015---House
   | |-------Song 1
   | |-------Song 2
   |
   |---Latin
   | |-------Song 1
   | |-------Song 2
   | |-------Song 3
   | |-------Song 4
   |
   |---Mixes
         |-------Song 1
         |-------Song 2
         |-------Song 3
***********************************************
Party
   |---December31
   | |---House
   | | |-------Song 1
   | | |-------Song 2
   | |
   | |---Latin
   | |-------Song 1
   | |-------Song 2
   | |-------Song 3
   |
   |---Valentine
   | |---Latin
   | | |-------Song 1
   | | |-------Song 2
   | | |-------Song 3
   | | |-------Song 4
   | |
   | |---Mixes
   | |-------Song 1
   | |-------Song 2
   | |-------Song 3
   |
   |-------Song 1
   |-------Song 2
   |-------Song 3

***********************************************
You currently CAN go this way in Mixxx :
ParentFolder
       |-------List of songs

but you CAN'T DO:
Parent Crate
       |-------SubCrate
       | |---List of Songs
       |
       |-------SubCrate
                     |---subsubCrate
                     | |---lists of songs
                     |
                     |---subsubCrate
                             |---lists of songs

Note: Crate and one level of subcrate will be enough for almost every one and i almost can't imagine a case where more than 2 levels of subcrates will be necessary.
I have been expecting subcrates levels for more than 2 years in Mixxx, it is a pity i don't know nothing about programing :/

Damn, the graphic is not displayed good after i have post it, i will send you a copy to your mail called mixx crated in a few minutes if you don't mind.

Hi infarmer, thank you for your explanation, I could see the graphic properly.

Just to make sure I understood you, what you want is:
Crates can be organized into folders, and when you select a folder in the library tree, the track list shows all the tracks that are in the crates in the selected folder.
So in your example above, selecting Rock, would show the songs in Symphonic and the songs in Hard at the same time.

Would this fulfill your needs? Would a single-parent tree (a crate can only belong to a single folder, like in your diagram) fulfill all your needs?

I have to learn more english. :/
No, selecting as example rock stuff like you...

*************************
If you select Rock Crate (left column)
You will get 2 folders closed in rigth column: Symphonic & Hard No songs, folers are closed by default
Note: in column left the tree for rock must be expanded showing the two folders, no songs in rigth column.

Now, you select hard crate in left column (1clic )
You will get the list of songs for hard crate in rigth colum, but only for hard rock, symphonic is in other folder/crate

If you need a symphonic song, you have to select symphonic for display the syphonic songs in rigth colum, in this case, songs for hard rock will dissapear, it is like expand or contract foder, the crates must work, or at leasr what we are trying to ask for.

Think in an explorer like total or norton commander, they have 2 windows (Columns), you can use left to configure folders in a tree view and on the rigth the content of the folders, for us songs., or think in the libraries of windows, in the left you have documents, images, music, etc, in the rigth the contents for thoses folders, for us songs.

I hope you catch the point now :)

I was actually meaning that. But folders, in addition of being expanded/collapsed, could be selected (like a crate), and that could show the tracks of all the crates being in that folder.

So folders, in addition of being a way to organize your crates, would be like a meta-crate that shows all the tracks of all its children.

This is not nothing different to what you've described, it is more like an additional feature. So I assume this would cover your use case.

Great, i wish you good luck and job!.

Finally it will be done!!!!!, thank you very much for work in this Vladimir.

Hi guys.

I'd like to do some work on this.

I'll try to re-use Mika's work as far as it is going to be possible. Even though his code looks pretty old now.

I like that it works this way:

Every crate can contain other crates. There can be switch "show this crate songs only/all children songs". This would allow nice searching through crates if you need "some metal" or you can put undecided kind of metal to top level "metal" crate further sorting. Should drag and drop to children remove the track from its original crate?

I don't see good sense of playlist containing playlist. Here I propose to create special entity "folder" which could contain either playlists or other folder. When opening folder of playlist it will show no songs in right tab (maybe list of what it contains?).

The navigation through this will be possible only via the tree nodes in left tab. (maybe opening children of playlist folder from its right view?)

Letting users create a crate inside a crate but not a playlist inside a playlist will probably confuse/frustrate them. I think we should use the same approach for both.

Then, I personally think the better approach is the folder approach.

Ok. So I'll add folders for both of them.

I see two ways how to put this into database:

1) add column "is_folder" (or something similar) to crates/playlists table and forbid to add tracks to such a crate/playlist

2) add new table "crate_folders"

What do you think is better? I think first aproach can be sometimes faster as We can avoid some JOINs, but the table can be significantly bigger (I don't have idea how many crates people have...). And make the work with it easier. I don't like idea of having playlist which can't have songs added to...

In right-click menu on folder there will be option "Add folder".

Should folders display songs of their children or no tracks?

There is blueprint which duplicates this bug.

https://blueprints.launchpad.net/mixxx/+spec/multilevel-crate-and-playlist

I think it should be either reassinged to me or deleted.

For me playlists and crates cover entirely different use cases. So there is no need to treat make folders of them the same.

I think we need a roundup about our requirements.
I will give it a try:

* We will have folders, crates and playlists.
* We have AutoDJ crates
* We should keep in mind that we will also have smart crates in future. (Crates filled automatically by a rule)

Question: what is a folder?
* A collection of crates, playlists, smart crates and folders?

Usecase Playlist folders:
* Grouping Playlists: We may have different dinner playlists in a dinner folder.
IMHO it is fine if we treat it exactly like a file system folder containing m3u playlists.
A recursive view is not required. Every Play list has is exactly one time in the folder tree.

Usecase Crate folders:
* Organize the library hierarchically as desired.
A crate should be allowed to be a member of many folders.
I use crates in terms of Tags, a track can be tagged "floorfiller" and "femail vocals" by dropping it into the "floorfiller" and "female vocals" crates. It would be nice to group these tags into folders and see a recursive view of all tracks in the containing crates.
I like to decent to "floorfiller" -> Rock

What is the difference between a Crate folder and a Smart Crate?
A smart crate is a saved library Filter. The filter for a Crate Folder containing "floorfiller" and "femail vocals"
Is crate:floorfiller AND crate:femail vocals"

Is this probably redundant?

What about keeping the flat crate structure but add a smart crates tree instead?

I still need crates and subcrates, a better way to organize my colection since i mix normally on the fly, so i insist once again for that feature if possible. People with a large colection think like me, my dj friends al least have similar opinion. Finally..., almost all dj software that i have tested or used have that functionality, you can check tracktor, virtual, bmp studio (not exactly a mix software), etc. You can download free test versions for some of them and test libraries and see how it works. If several dj programs have ways to expand the tree into a more complex way for organize big libraries, it is probably because that function is needed and use for at least a sufficient amount of people using those programs. Of course i can use other programs and currently i'm doing it, but i have several reasons for use mixxx, but the library.... it is not bad but also not really good.
My needs can be differet from yours, i know, but other people have the same needs than me, i can assure you that.

Well, now you have my opinion, keep good work as usual over here, gong to work :P

@infarmer: I still need crates and subcrates

Yes, we now, that is the essence of the bug. There are just so many ways to implement it and I want to make sure we do it just right and in line with future smart crates.

Looking at the competitors is not a bad idea:
Traktor: Playlists, no Crates -> Folders of Playlists / Subfolder of Playlists
Serato: Crates and Samart Crates -> Crates can contain sub Crates along with tracks.
VirtualDJ: Playlists and Crates -> Folders of Playlists / Subfolder of Playlists / Crates can contain sub Crates along with tracks.

For me the playlist folders are pretty clear, but we have four options for the crates:

1) The same as playlists (Traktor)
      * a folder / subfolder can only contain crates / Playlists
2) Like file system folders (Virtual DJ / Serato)
      * a folder is a crate and can contain tracks and other crates
3) Like recursive file system folders
      * a folder is a meta crate, it cant contain own tracks, but displays the tracks of all sub crates.
4) Like a tag system / smart crates
      * A crate can be member of more than one parent crate

What is you preference?

I think that purpose of folders/subcrates is basically the same. It is not to have infinite list of crates/playlist in which is hard to navigate, hard to name it. Now i have crates named in style Rock - 80's - slow. Flat structure makes me to have many crates starting with Rock, some starting with Rock - 80's... Navigation through this is not nice.

In the end it doesn't matter what is container for crates (folder/parent crate). The point seems to be reducing number of displayed crates at the moment and help navigate through hierarchy.

I see the possibility of crate being in more folders simultaneously as source of confusion. Example:
Three crates: Rock, Floorfillers, fast. Fast being in folders Rock and Floorfiller at the same time. This means if i add new fast rock song to Rock/Fast it will automaticaly become Floorfiller even though it can be floorkiller. If I need a song to be in more places in hierarchy i can put explicitly in all places i need.

I would treat smartcrates as regular crates. At least from users view.

I really like the idea of recursive crate view.

I'd like to start with adding possibility of crates containing other crates as it looks the most simple and useful starting point. The second step would be folders for playlists. Next one would be adding neat features like recursive views smartcrates, etc.

Ah, Ok that sounds reasonable.

It looks like a crate can than contain:
* Tracks
* Stored Library filters, aka. SmartCrates.
* Crates

Each crate can only have one parent crate, but multiple child crates.

The recursive view somehow conflicts with the "crate containing a crate concept"
If you put a track along with a crate into a parent crate, how can you distinguish it from a track in the child crate.
Is it OK to disallow this or do we need a workaround?
Will it be possible to add a parent crate to AutoDJ?
Do you have already an Idea for a Database Schema?

My point of view:

1) We can just ignore by now that smart crates are filled automatically. I also think that in this discussion we can treat them like regular crates.

2) I agree, crates and playlists should only belong to one parent item. If you want the content of a crate to be showed to many other crates (like if you wanted to include all tracks "marked with a specific tag" in some crate) you can use smart crates.

3) If we let a crate contain tracks and other crates, how are we going to display all this? Obviously, on the browser tree only the subcrates would be visible. Shall we display the subcrates in the track list? How will we handle ordering for example?

If we use folders as the grouping entities, and we don't allow them to directly hold tracks we avoid this issues. We don't loose organizing power: you just have to put the "spare" tracks in a subfolder. Plus we can have the recursive view when the parent folder is selected. I think this is the best way to implement all these concepts..

That works for me.
It will feature the recursive view we have it already in the browse tree.
A unique selling feature. ;-)

Related: Bug #1473801 (iTunes folder)

Hi again, guys I finally managed to produce something. It is still not finished, but more-or-less working.

I would appreciate if you guys can have a look at the code and put in some ideas before I start to do something ugly massively. Especially I didn't have better idea then using a lambda to set hasChildren function in treeitemmodel, comments welcome.

At this moment it is possible to create Folder of Crates and some subcrates. Preserving of opened folder structure almost works.

Next steps:
* deleting folders recursively
* fix - closing folders isn't removing them from list of opened folders
* moving crates between folders
* filling folder screen somehow

Cool, where can we watch your code? You may just issue a GitHub Pull request and describe what we should review.

https://github.com/vlada-dudr/mixxx/tree/multilevelCrates

So I'm testing to what I've done so far. It works with my builds.

I downloaded windows VM to test other DJ softwares. So far I managed check out Serato intro which uses crates in different way which, I think, is much better and I'll probably change my implemetation to copy it. This means no folders, just crates containing crates a showing content of all subcrates. This allow also "tagging" usage we were discussing earlier easier.

Also I think we'll need to implement drag'n'drop to make tree structures comfortable with.

Glad for any feedback.

Other thing which needs implementation: recursive view in context menu.

> This means no folders, just crates containing crates a showing content of all subcrates.

We should be petty sure about this question, since this will effect how we have to implement smart crates later. I can see advantages for both models. How can we answer the question what suits best? Do we have mandatory use-cases?

We sharp our use cases first. Let me do a start:
* Genre tree:

A track can have a flavour of on ore more genres. A genre can have as well one or more parent genres.
So genres are more a map then a tree, see https://en.wikipedia.org/wiki/Genealogy_of_musical_genres
To do this with crates we may have something like that:
- Tracks by Genre
   - Blues
     - Soul
      - R&B
   - Pop
       - R&B
Where Pop->R&B can be a smart crate.
However, not all R&B tracks are Pop. The Pop view should contain all R&B tracks that are also Pop. The Pop->R&B view should contain all Tracks that are Pop and R&B.

Conclusion: for a good Genre Tree solution, we need something more intelligent like a Tree of smart crates, with original crates that hold genre flavours like a the tags used in Last.fm.

I personally like the folders, like it is now. I would however make the folders to show all the tracks their children contain together.

Let's talk in terms of use cases. Can you give an example, how your tree will look for what purpose and when a recursive view will be helpful? Hopefully this will help to get a clear view, which model suits best to Mixxx. I will purpose an idea for genre trees in a following post.

For a genre tree, like we found it in famous online shops, we need a crate per genre. Like rock an alternative. The user may add a track directly to rock or to alternative, alternative is part of rock. The rock crate should display all alternative tracks as well. For genres that have two or more parent genres, the user can establish the crate somewhere the genre tree, and link it by smart crates, to create the desired map.

The complicated part wil be how to mange tracks that are in such a folder crate. We may introduce a root crate for each folder, wer songs are stored if a user drops it to a folder. Or we may add a toggle button for recursive view on/off. It looks like a combination of the best of both worlds.
Will this be usable? Any thoughts?

I like folders in the sense that no tracks can be added directly to it. Then it's the users' responsibility to manually add such root crate and place tracks there.

If we let Mixxx add the folder automatically we could be in a situation where we are doing something a user didn't ask us to do. An empty crate for every folder would bloat the tree and would be annoing for users who simply don't want to add tracks there.

I particularly don't like the toggle idea much, but I see it could be a good compromise and might fulfill other people needs.

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?

Can there be a separate tree for automatic crates (perhaps called 'folders' or something else) and manually created crates? Such that Mixxx never modifies the manual crate tree unless explicitly instructed to.

Here is some work done: https://github.com/mixxxdj/mixxx/pull/726

slightly dependent feature request: https://bugs.launchpad.net/mixxx/+bug/1710040

Very usefull request i think, at least for me because i use a very long database, anyway does not expect to much, the original request is from 2010 with no luck till now :/ I still want this, but i have no knowledge on programing... :(

The nested crates feature is under development for summer of code 2017.
I've completed all the basic stuff, and now it kinda works. You can have crates with songs and other crates, you can toggle recursion on or off, you also have a crate filter for the library.

The PR is here: https://github.com/mixxxdj/mixxx/pull/1304

The nested crates are tied to the new library layout witch is under development since gsoc 2016 and has still quite a few issues to solve before it gets released. I don't know the pace of the people working on it so I can't comment on when it's gonna be ready.

The PR for the new library is here: https://github.com/mixxxdj/mixxx/pull/1117

ahh good news finally... nice!!!, i know this not help you too much but anyway, thanks for working on this gramanas!.

https://bugs.launchpad.net/mixxx/+bug/1741147 would benefit greatly from this.

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/5634