Nested crates #1304

gramanas · 2017-07-05T17:20:27Z

Hello,

This is a work in progress for the crate enchantments for GSoC 2017.
It's build on top of #1117
Full story here .

In order to test this do the following:

If you have crates already and want to test creating hierarchy on them
- duplicate your mixxx database naming one mixxxdb.sqlite.bak so you won't lose your stuff
- start mixxx using the new duplicate database (it will update to version 29 adding the new tables)
- All your crates will be converted to level 1 crates
If you want to start a new, just rename your database so mixxx will create a new one.

And then

You can right-click > Create new Crate to create a level 1 crate.
You can right-click > Create Subcrate for subcrates.
right-click > Rename to rename the crate (rules apply)
right-click > Duplicate to create a duplicate of this crate and it's tracks at lvl 1 (currently it is not recursive, we'll see)
right-click > move subtree to will present you with a list of places whare you can move the crate and all it's children to. (You can't move a crate while leaving it's children there, it doesn't make sense since the contents of a child crate are also the contents of the parent one)
You can also delete crates, with right-click > Remove. If the crate has children they will get deleted as well. (after a warning)

The first entry in the tree is the recursion switch marked as Show tracks is subcrates. It defaults to on.
Clicking the tree item toggles it.

Crates are displayed using CrateTableModel. A view is generated (one for recursion and one for simple view) for each crate when you click at it depending on the above toggle switch. Everything is in that SQL statement so the view updates live with new tracks even new child crates with new tracks (in the case of recursion)

Add New Library branch to upstream?
Figure out what to do with CrateStorage
Display crate contents using the crate: filter
Make rename available
Enhance the filter to enable recursive view of the crates (that's what the item marked "recursion" is for)
Recursive deletion
Move crates throughout the tree (recursively)
Bring the branch up to date

2.2 update

fix Critical [Main]: Invalid database identifier value: QVariant(int, 0)
Use recursivness everywhere
- Crate Summary
- Add crate to AutoDJ track source
- more?
Right click on track > add to crate (Find a way to distingusish crates -possibly namePath)

…r/mixxx into NestedCrates

Only child creation and leaf deletion avaliable so far

gramanas · 2017-07-05T18:14:02Z

This is looking way too ugly, due to the previous commits from the redesign.
Could we create a branch on the upstream with the redesign so that the work that
needs to be done, gets merged there.

The new library is pretty functional as it is, so it seems only logical (since it's such a big PR) to have it's own branch in upstream

daschuer · 2017-07-06T15:32:35Z

Voilà: https://github.com/mixxxdj/mixxx/tree/jmigual-library-redesign

…r/mixxx into NestedCrates

Be-ing · 2017-07-08T17:41:16Z

src/library/features/crates/cratefeature.cpp

+    // this means that the user just started mixxx with nested crates for the
+    // first time, so we have to fill the closure table with (self,self,0)
+    if (!m_crateHierarchy.closureIsValid()) {
+        QMessageBox::warning(


There's no need for this dialog box to be shown. Please remove it.

Be-ing

Just did a quick test and I confirm it works as you describe. I haven't looked at the code in detail yet.

Ignore the first entry on the hierarchy marked "recursion" it's for a later use.

What will that be used for?

Be-ing · 2017-07-08T18:09:48Z

I see a lot of assertions in my log but I don't know how to reproduce this:

Critical [Main]: DEBUG ASSERT: "crateId.isValid()" in function virtual void CrateFeature::activateChild(const QModelIndex&) at src/library/features/crates/cratefeature.cpp:325
Critical [Main]: DEBUG ASSERT: "crateId.isValid()" in function virtual void CrateFeature::activateChild(const QModelIndex&) at src/library/features/crates/cratefeature.cpp:325
Critical [Main]: DEBUG ASSERT: "crateId.isValid()" in function virtual void CrateFeature::activateChild(const QModelIndex&) at src/library/features/crates/cratefeature.cpp:325
Critical [Main]: DEBUG ASSERT: "crateId.isValid()" in function virtual void CrateFeature::activateChild(const QModelIndex&) at src/library/features/crates/cratefeature.cpp:325
Critical [Main]: DEBUG ASSERT: "crateId.isValid()" in function virtual void CrateFeature::activateChild(const QModelIndex&) at src/library/features/crates/cratefeature.cpp:325
Critical [Main]: Invalid database identifier value: QVariant(int, 0) 
Critical [Main]: Invalid database identifier value: QVariant(int, 0) 
Critical [Main]: Invalid database identifier value: QVariant(int, 0) 
Critical [Main]: Invalid database identifier value: QVariant(int, 0) 
Critical [Main]: Invalid database identifier value: QVariant(int, 0) 
Warning [Main]: GLSLWaveformRendererSignal::createFrameBuffer - frame buffer not valid 
Warning [Main]: GLSLWaveformRendererSignal::createFrameBuffer - frame buffer not valid 
Critical [Main]: Invalid database identifier value: QVariant(int, 0) 
Critical [Main]: Invalid database identifier value: QVariant(int, 0) 
Critical [Main]: Invalid database identifier value: QVariant(int, 0) 
Critical [Main]: Invalid database identifier value: QVariant(int, 0) 
Critical [Main]: DEBUG ASSERT: "index.isValid()" in function void CrateFeature::updateChildModel(const QSet<CrateId>&) at src/library/features/crates/cratefeature.cpp:601
Critical [Main]: Invalid database identifier value: QVariant(int, 0) 
Critical [Main]: DEBUG ASSERT: "t->parent() != nullptr" in function parented_ptr<T>::parented_ptr(T*) [with T = SavedQueriesTableModel] at src/util/parented_ptr.h:18
Critical [Main]: DEBUG ASSERT: "u->parent() != nullptr" in function parented_ptr<T>::parented_ptr(parented_ptr<U>&&, typename std::enable_if<std::is_convertible<_Up*, _Tp*>::value>::type*) [with U = SavedQueriesTableModel; T = SavedQueriesTableModel; typename std::enable_if<std::is_convertible<_Up*, _Tp*>::value>::type = void] at src/util/parented_ptr.h:27
Critical [Main]: DEBUG ASSERT: "u->parent() != nullptr" in function parented_ptr<T>::parented_ptr(parented_ptr<U>&&, typename std::enable_if<std::is_convertible<_Up*, _Tp*>::value>::type*) [with U = SavedQueriesTableModel; T = SavedQueriesTableModel; typename std::enable_if<std::is_convertible<_Up*, _Tp*>::value>::type = void] at src/util/parented_ptr.h:27

Be-ing · 2017-07-08T18:19:03Z

There is an issue with the crate filter. When I use any other filter in the main Tracks feature, then switch to another feature and switch back, the filter last used on the Tracks feature is restored. If the last filter was a crate filter, the tracks shown when switching back to the Tracks feature are the tracks that would be shown with that filter, but the text of the filter is not restored to the search bar.

Be-ing · 2017-07-15T04:53:12Z

src/library/features/crates/cratetreemodel.h

+  protected:
+
+  private:
+    bool findParentChildFromPath(Crate& parent,


This function could have a better name. At first glance it seems like it is finding a "ParentChild" from the given path and the bool return type doesn't make sense with that idea. How about "findParentAndChildFromPath"? It's a long name, but it is clear what the function does. There should be a comment here in the header file explaining what the returned bool indicates.

Wait, why is this a member of CrateTreeModel? Wouldn't it make more sense as a member of CrateStorage or CrateHierarchy?

Be-ing

This looks like it's off to a pretty good start. I haven't looked closely at the SQL or the modifications to the database structure yet, so I have no comment on that (yet). I think we should come up with a better organization for the relationships between the classes. Currently lots of implementation details about handling the database are leaked into the GUI code. I don't think CrateFeature should be aware of CrateHierarchy's existence. I think CrateStorage should take care of all that behind the scenes. Combining CrateStorage and CrateHierarchy would create a pretty large and unwieldy class. How about instantiating CrateHierarchy as a private member of CrateStorage and modifying CrateStorage to make calls to CrateHierarchy where appropriate? That way CrateFeature does not need to make calls to CrateStorage then to CrateHierarchy. I think this refactoring should be taken care of before continuing to expand the current functionality. If this is not taken care of now, it will be more work later to disentangle the GUI from the DB logic.

Be-ing · 2017-07-15T04:54:33Z

src/library/features/crates/cratetreemodel.cpp

+CrateTreeModel::CrateTreeModel(LibraryFeature* pFeature,
+                               TrackCollection* pTrackCollection,
+                               CrateHierarchy* pCrateHierarchy)
+    :m_pFeature(pFeature),


nitpick: space between : and m_pFeature

Be-ing · 2017-07-15T04:59:48Z

src/library/features/crates/cratetreemodel.h

+                   CrateHierarchy* pCrateHierarchy);
+    //virtual ~CrateTreeModel();
+
+    // QVariant data(const QModelIndex& index, int role) const override;


If the data and setData functions from the TreeItemModel base class work for your purposes, you do not need to reimplement them. If at some point you realize you need to modify those functions specifically for CrateTreeModel in a way that wouldn't be applicable to other TreeItemModels, then reimplement them for CrateTreeModel.

Be-ing · 2017-07-15T05:00:42Z

src/library/features/crates/cratetreemodel.h

+  public slots:
+    void reloadTree() override;
+
+  protected:


There won't be any child classes of CrateTreeModel, will there? If there won't be, then you can get rid of this line.

Be-ing · 2017-07-15T05:01:49Z

src/library/features/crates/cratetreemodel.h

+    TrackCollection* m_pTrackCollection;
+    CrateHierarchy* m_pCrateHierarchy;
+
+    parented_ptr<TreeItem> m_pRecursion;


How about renaming this m_pRecursionButton or m_pRecursionItem?

Be-ing · 2017-07-15T05:06:21Z

src/library/features/crates/cratetreemodel.cpp

+        if (!findParentChildFromPath(parent, child, idPath)) {
+            parent.setId(rootId);
+        }
+        if (child.getName() == "") {


Use QString::isEmpty

Actually, this shouldn't require a string operation. Would child.getId().isValid() work?

Be-ing · 2017-07-15T05:15:20Z

src/library/features/crates/cratehierarchy.cpp

+    namePath = namePath + "/" + crate.getName();
+    idPath = idPath + "/" + crate.getId().toString();
+
+    if(!writeCratePaths(crate.getId(), namePath, idPath)) {


This can be simplified to return writeCratePaths(crate.getId(), namePath, idPath);

Be-ing · 2017-07-15T05:18:34Z

src/library/features/crates/cratefeature.cpp

+        m_crateHierarchy.resetClosure();
+        m_crateHierarchy.initClosure();
+        m_crateHierarchy.resetPath();
+        m_crateHierarchy.generateAllPaths();


Do you anticipate needing these 4 functions in any other context? If not, it may make sense to make them private members of CrateHierarchy and create a public wrapper function (maybe called CrateHierarchy::initializeHierarchy or something like that) around them to call here. I think this exposes too much of the implementation of the database storage to the GUI class.

yeah, you are right, I'll do that

Be-ing · 2017-07-15T05:21:58Z

src/library/features/crates/cratehierarchy.h

+          m_pTrackCollection(pTrackCollection){
+    }
+
+    uint countCratesOnClosure() const;


Would "countCratesInClosure" work a bit better for the name?

Be-ing · 2017-07-15T05:30:28Z

src/library/features/crates/cratefeature.cpp

        if (m_pTrackCollection->deleteCrate(crate.getId())) {
+            m_crateHierarchy.deleteCrate(crate.getId());


The GUI code shouldn't have to be concerned with this. Calling TrackCollection::deleteCrate should take care of it automatically.

Be-ing · 2017-07-15T05:58:33Z

src/library/features/crates/cratefeature.cpp

@@ -65,6 +87,10 @@ void CrateFeature::initActions() {
    connect(m_pCreateCrateAction.get(), SIGNAL(triggered()),
            this, SLOT(slotCreateCrate()));

+    m_pCreateChildCrateAction = std::make_unique<QAction>(tr("Create Child Crate Here"),this);


No need for the word "Here" at the end. "Create Child Crate" is clear.

I'll rename it to "Create Subcrate", I think it's nice.

Be-ing · 2017-07-15T06:01:30Z

src/library/features/crates/cratefeature.cpp

+        CrateId newCrate = CrateFeatureHelper(
+            m_pTrackCollection, m_pConfig).createEmptyCrate();
+        if (newCrate.isValid()) {
+            m_crateHierarchy.initClosureForCrate(newCrate);


A single function call to CrateStorage should take care of all this DB logic.

…/mixxx into NestedCrates

Be-ing · 2017-07-15T16:53:48Z

Merge the master branch to bring in #1309

Eliminate GUIs interaction with the backend stuff

Be-ing · 2017-07-16T16:22:11Z

src/library/features/crates/cratestoragehelpers.h

+                    kCrateSummaryViewSelect,
+                    kLibraryTracksJoin,
+                    CRATE_TABLE,
+                    CRATETABLE_ID);


I think it would be easier to maintain if these SQL string constants were put back into cratestorage.cpp (inside the anonymous namespace). Keep the helper classes in the new files.

But I see them as helper strings, that's why I put them there

I also don't like that these constants are exposed to the whole world in a header file.

Be-ing · 2017-07-16T16:47:18Z

src/library/features/crates/cratefeaturehelper.cpp

+    return newCrateId;
+}
+
+CrateId CrateFeatureHelper::createEmptySubrate(const Crate& parent) {


typo: createEmptySubcrate

Be-ing · 2017-07-16T16:58:10Z

src/library/features/crates/cratefeaturehelper.cpp

+        m_pTrackCollection->crates().initClosureForCrate(newCrateId);
+        m_pTrackCollection->crates().generateCratePaths(newCrate);
+        qDebug() << "Created new crate" << newCrate;
+    } else {


CrateFeatureHelper::createEmptyCrate only makes top-level crates, right? If so, it should be renamed to clarify that.

Be-ing · 2017-07-16T18:44:54Z

src/library/features/crates/cratefeaturehelper.cpp

@@ -74,6 +74,68 @@ CrateId CrateFeatureHelper::createEmptyCrate() {
    if (m_pTrackCollection->insertCrate(newCrate, &newCrateId)) {
        DEBUG_ASSERT(newCrateId.isValid());
        newCrate.setId(newCrateId);
+        m_pTrackCollection->crates().initClosureForCrate(newCrateId);
+        m_pTrackCollection->crates().generateCratePaths(newCrate);


Calling TrackCollection::insertCrate above should take care of this. TrackCollection shouldn't have to be concerned with these details either. How about moving this logic to CrateStorage?

CrateFeature does not make use of the returned CrateId from CrateFeatureHelper, so you can change the return type to void.

Be-ing · 2017-07-16T18:50:35Z

src/library/features/crates/cratefeaturehelper.cpp

+        DEBUG_ASSERT(newCrateId.isValid());
+        newCrate.setId(newCrateId);
+        m_pTrackCollection->crates().initClosureForCrate(newCrateId);
+        if (m_pTrackCollection->crates().insertIntoClosure(parent.getId(), newCrateId)) {


Likewise, this logic should be moved into CrateStorage. You could add another parameter to TrackCollection::insertCrate to pass it the parent Crate.

Be-ing · 2017-07-16T18:58:33Z

src/library/features/crates/cratefeature.cpp

+        pTrackCollection->crates().resetClosure();
+        pTrackCollection->crates().initClosure();
+        pTrackCollection->crates().resetPath();
+        pTrackCollection->crates().generateAllPaths();


A single call to TrackCollection should take care of this, including checking closureIsValid. How about calling it TrackCollection::checkCrateHierarchy? I don't think there should be any mention of "closure" in CrateFeature; that's an implementation detail.

uklotzde · 2017-07-16T19:42:14Z

I think we need an additional level of control between TrackCollection and CrateStorage/CrateHierarchy that handles all interactions and workflows with crates. CrateStorage already has too many responsibilities, namely managing both crates and a crate tracks.

Task: Create a new crate

Insert new empty crate
Add the newly created crate as a new child to the given parent crate

Task: Delete existing crate

Remove the crate from the hierarchy by adding all its children as new children to its parent -> crate becomes a top-level crate without any children
Remove all tracks from this crate
Delete the crate itself

naught101 · 2018-05-10T05:37:57Z

Yeah, I have. I guess I'm asking how likely it is to destroy the DB so that I know whether to avoid doing much meaningful work on my data while using it, if that makes sense. If the risk is low, I don't mind running it a lot more.

I guess a better question is, what will happen if I try to re-organise crates, and then try to go back to the jmigual-library-redesign banch?

gramanas · 2018-05-10T07:53:41Z

@naught101 The way I implemented the nesting functionality in the db leaves the old crates table untouched. So if you add nested crates using this branch and then use another build without them, all your crates will be there without the nesting.

I haven't had an issue when switching back and forth from versions.

All the existing crates are converted to lvl 1 crates when you first launch mixxx with nested crates for the first time. So changing crates and then going back doesn't affect anything, you just lose the nested functionality.

On the other hand, if you create some nested crates and then you go and delete them in jmigual-lib-redesign, the functions that take care of the hierarchy stuff wont get called for deletion and then next time you try to add a nested crate in the same DB you might have a problem.

poelzi · 2018-05-10T11:44:57Z

I don't like this at all. deleting a crate is something people rarely do outside of testing purposes. makes no sense for me to bind this to any key even with a warning dialog it seems wrong to me. kind regards poelzi

…

On 10 May 2018 05:48:55 CEST, naught101 ***@***.***> wrote: > - It would be nice if pressing the delete key when a crate is highlighted in the tree deleted the crate. Sounds dangerous. It's easy to bump the delete key. If you do this, please add a confirmation dialogue. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #1304 (comment)

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

naught101 · 2018-05-10T12:18:32Z

Awesome, thanks gramanas, that's a very useful summary. I'll start testing more intensely :)

naught101 · 2018-05-11T04:28:46Z

I think these things are probably post-merge feature requests, but I'll put them here in case it makes sense to do it beforehand:

It would be good if the context menu for crates was hierarchical. I have a LOT of crates. This would help cut down the visuals a lot.
Dragging and dropping crates into other crates would be nice - especially for when people are upgrading this next version. I guess less so after that. Similarly, selecting and dragging/moving multiple crates at once would massively help with the upgrade.
The crate: filter always includes sub-crates. It might be nice if there were filters both with and without subcrates (although perhaps not that useful, since most times sub-crate names are fairly unique anyway, I guess).
Playlist folders would also be nice, just for keeping playlists organised.

naught101 · 2018-05-11T04:46:09Z

Crates don't seem to sort properly in the menu:

Events should appear before the crates "Events/..." - I guess this might be related to the underscore thing?

naught101 · 2018-05-11T04:49:24Z

Ahh.. I think the sorting is going off the crate name, instead of the entire crate path.

naught101 · 2018-05-11T05:01:34Z

Don't close parent crates when a crate is modified, leave things as they are.
The letters on the scroll bar don't really work any more, I think. For example, if you have only a few crates, and then one parent crate with a lot of sub-crates open (e.g. Genre), there's basically nothing on the scroll bar. Perhaps in situations like that the scroll bar should be populated with the characters from subcrates as well?

naught101 · 2018-05-11T05:13:25Z

In the library views, track context menu -> add to crate displays a flat crate list, only showing the crate names, not the parent names, and is sorted by the crate names. Should be like the crate context - move to subtree list.

gramanas · 2018-05-11T09:14:06Z

I believe there is a crate:= filter that doesn't match with recursion but I don't remember if I did that or not. Gonna have to check.

The way crates are displayed in the right click menu is realy suboptimal, but I didn't think of anythink that worked better. Maybe this #1656 crate widget could be a solution.

As for the whole wrefolding of the tree structure on crate change, I can't really do anything unless we fix the underlying tree representation to support saving and restoring states.

You are right about the scroll bar. I didn't touch it at all last summer, this is one of the nitpicks that have to be fixed throught the new library.

Be-ing · 2018-06-12T02:29:22Z

A merge conflict has developed.

… nested-crates

Be-ing · 2018-06-23T20:43:15Z

Merge conflict and database upgrade issue fixed in gramanas#3

Nested crates updates

Be-ing · 2018-06-24T12:55:20Z

@daschuer, @uklotzde: ready for merge? (note this will merge into the jmigual-library-redesign branch, not master)

daschuer · 2018-07-19T20:45:16Z

do you have an idea why
SearchQueryParserTest.CrateFilter
fails?

daschuer · 2018-07-19T20:47:17Z

res/schema.xml

+      Add tables to support nested crates.
+    </description>
+    <sql>
+      CREATE TABLE IF NOT EXISTS crateClosure (


@uklotzde: Why is that an issue?

daschuer · 2018-07-19T20:47:57Z

res/schema.xml

+        namePath TEXT
+      );
+
+      ALTER TABLE crates RENAME TO old_crates;


daschuer · 2018-07-19T21:03:27Z

res/schema.xml

+
+      CREATE TABLE IF NOT EXISTS cratePath (
+        crateId INTEGER,
+        idPath TEXT,


please add a comment like
"This contains a / separated string of crate Ids"

daschuer · 2018-07-19T21:04:10Z

res/schema.xml

+      CREATE TABLE IF NOT EXISTS cratePath (
+        crateId INTEGER,
+        idPath TEXT,
+        namePath TEXT


"This contains a / separated string of crate names"

By the way: how do you treat names which includes a "/"?

is it smart to store the namePath in the Database? This is a redundant information which can be wrong.
How is guaranteed that this is always correct?

Storing redundant information for optimizing queries is not an issue as long as you are able to guarantee consistency, either immediately or at least eventually. The method of choice for immediate consistency is encapsulation with hooks that are triggered when needed and everything enclosed in a transaction scope.

I remember that the my last review revealed that consistency cannot be guaranteed by the current implementation, because the transaction scoping was missing. Considering the fact that the whole hierarchy is abandoned and flattened when any inconsistencies are detected, this is a no-go for production and needs to be fixed.

katsar0v · 2020-07-04T14:48:12Z

This PR is still open, but the feature is good. I personally would like to have a "House" crate with all sub-genres as sub crates.

I could not build the PR with cmake, because the code is old and it was build using a legacy way (which I don't know). If there is not much left to do, it would be great to have this feature in 2.3 stable or 2.3.x

Be-ing · 2020-07-04T15:49:47Z

Unfortunately this branch was built on top of the jmigual-library-redesign branch which still has major performance problems and no one is working on that branch anymore. This was a mistake of project management on our part to build this feature on top of another that still had a lot of work to get to a mergeable state. Instead of this feature, we have decided to take the more flexible approach of user defined faceted tags in #2656.

katsar0v · 2020-07-04T15:53:53Z

Mhmm, am not sure if #2656 is better for my use case than #1304, but I understand your answer

gramanas added 5 commits June 8, 2017 01:20

Add cratetreemodel.h

f3ad479

Merge branch 'jmigual-library-redesign' of https://github.com/daschue…

1fba5bc

…r/mixxx into NestedCrates

Nested Crate Insertion with bad code

3c09995

Merge branch 'jmigual-library-redesign' of https://github.com/daschue…

1635ac3

…r/mixxx into NestedCrates

Add nested crates

2720d6c

Only child creation and leaf deletion avaliable so far

Disguise sql columns as variables

f3e474f

Merge branch 'jmigual-library-redesign' of https://github.com/daschue…

bc97923

…r/mixxx into NestedCrates

gramanas changed the base branch from master to jmigual-library-redesign July 6, 2017 22:58

Add 'Add new crate' that adds a crate to the top level

8242c67

Be-ing reviewed Jul 8, 2017

View reviewed changes

Be-ing suggested changes Jul 8, 2017

View reviewed changes

Be-ing mentioned this pull request Jul 13, 2017

library redesign code cleanup #1312

Merged

Be-ing reviewed Jul 15, 2017

View reviewed changes

Be-ing suggested changes Jul 15, 2017

View reviewed changes

Be-ing reviewed Jul 15, 2017

View reviewed changes

Merge branch 'jmigual-library-redesign' of https://github.com/mixxxdj…

596df84

…/mixxx into NestedCrates

gramanas added 3 commits July 16, 2017 11:43

Move hierarchy functions into CrateHierarchy

8d187b5

Split CrateStorage file

7cf56f3

Moved crateHierarchy to crateStorage

f9946ec

Eliminate GUIs interaction with the backend stuff

Be-ing reviewed Jul 16, 2017

View reviewed changes

Be-ing suggested changes Jul 16, 2017

View reviewed changes

Be-ing added 3 commits June 23, 2018 09:56

Merge remote-tracking branch 'upstream/jmigual-library-redesign' into…

e2cf708

… nested-crates

fix database schema upgrade for nested crates

e4da311

show context menu to add crate when right clicking empty area

cdb08fc

Be-ing changed the title ~~[WIP] Nested crates~~ Nested crates Jun 23, 2018

Merge pull request #3 from Be-ing/nested-crates

a5c5adc

Nested crates updates

Be-ing modified the milestones: 2.2.0, 2.3.0 Jun 27, 2018

jmigual mentioned this pull request Jul 7, 2018

Library-layout fix GUI lag #1740

Closed

daschuer reviewed Jul 19, 2018

View reviewed changes

Be-ing modified the milestones: 2.3.0, stalled Feb 7, 2019

Be-ing closed this Jul 4, 2020

mixxxbot mentioned this pull request Aug 22, 2022

add multi level crate support #5634

Open

		if (m_pTrackCollection->deleteCrate(crate.getId())) {
		m_crateHierarchy.deleteCrate(crate.getId());

Nested crates #1304

Nested crates #1304

Conversation

gramanas commented Jul 5, 2017 • edited Loading

gramanas commented Jul 5, 2017

daschuer commented Jul 6, 2017

Choose a reason for hiding this comment

Be-ing left a comment

Choose a reason for hiding this comment

Be-ing commented Jul 8, 2017 • edited Loading

Be-ing commented Jul 8, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Be-ing left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Be-ing commented Jul 15, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

uklotzde commented Jul 16, 2017

naught101 commented May 10, 2018

gramanas commented May 10, 2018

poelzi commented May 10, 2018 via email

naught101 commented May 10, 2018

naught101 commented May 11, 2018 • edited Loading

naught101 commented May 11, 2018

naught101 commented May 11, 2018

naught101 commented May 11, 2018

naught101 commented May 11, 2018

gramanas commented May 11, 2018 • edited Loading

Be-ing commented Jun 12, 2018

Be-ing commented Jun 23, 2018

Be-ing commented Jun 24, 2018

daschuer commented Jul 19, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

katsar0v commented Jul 4, 2020

Be-ing commented Jul 4, 2020

katsar0v commented Jul 4, 2020 • edited Loading

gramanas commented Jul 5, 2017 •

edited

Loading

Be-ing commented Jul 8, 2017 •

edited

Loading

Be-ing left a comment •

edited

Loading

naught101 commented May 11, 2018 •

edited

Loading

gramanas commented May 11, 2018 •

edited

Loading

katsar0v commented Jul 4, 2020 •

edited

Loading