Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clean up track right click context menu #1427

Merged
merged 14 commits into from
Dec 23, 2017

Conversation

Be-ing
Copy link
Contributor

@Be-ing Be-ing commented Dec 20, 2017

Before:
image

After:
image

This builds on @poelzi's work in #1341.

poelzi and others added 9 commits November 11, 2017 02:01
Switch from normal QAction menu to a composition of QCheckBox and QActionWidget.
The checkbox shows in which crates the selection is in.
Changing the crates selection does not collapse the menu, which allows
much easier categorization of tracks without going through the menu from scratch.

Use tristate when multiple tracks are selected.

When mulitple tracks are selected which do not share a crate, use
the tristate partially selected to indicate this.

Fix styling of pointers.

Use QVariant to transport CrateId in checkbox

Use optimized SQL query to select crates and count tracks.

Unfortunatelly QSqlQuery has no way of binding QLists
in WHERE x IN statements.

Use make_partented as suggested by daschuer

rename "Add to Crates" -> "Crates" to reflect function better
Optimize formatting of string lists for SQL queries
If the song changes while the current history view is open, the selection of
songs is lost. Therefor all crate changes are lost.

The history view saves and restores the selection through a new usefull api for selecting tracks in the wtracklistview.
@daschuer
Copy link
Member

Thank you for jumping in here.
I think we should distinguish between organizing functions and dj-ing functions. I like to have all DJing functions instantly visible.
Especially the top an bottom Auto DJ entries should be on the first level.
I have never used the other load to features, but I can imagine that if one has used it he will miss it on the first level as well. Maybe it is used in cases where drag and drop dies not work.
We can also consider to move all non-mass actions to the properties dialog.

@Be-ing
Copy link
Contributor Author

Be-ing commented Dec 20, 2017

Especially the top an bottom Auto DJ entries should be on the first level.

Yes, now that I see the reorganized menu, I think we have space for two more menu items.

I have never used the other load to features, but I can imagine that if one has used it he will miss it on the first level as well. Maybe it is used in cases where drag and drop dies not work.

Neither have I, and I don't want to take up a lot of space in the top level of the menu for them. The only use case I can think of for them is when the mouse is unusable for whatever reason (hardware issue, physical disability).

We can also consider to move all non-mass actions to the properties dialog.

I'm hesitant to hide useful features in a dialog.

for (CuePointer pCue : m_cuePoints) {
if (pCue->getType() == Cue::LOAD) {
disconnect(pCue.get(), 0, this, 0);
m_cuePoints.removeOne(pCue);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@uklotzde any ideas why this is not working?

for (CuePointer pCue : m_cuePoints) {
if (pCue->getType() == Cue::LOOP) {
disconnect(pCue.get(), 0, this, 0);
m_cuePoints.removeOne(pCue);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@uklotzde any ideas why this is not working too?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't remember right now how this works with c++, but in Java you cannot remove an element of a list that you're iterating with a for loop. You need to get an iterator, and make a loop with the iterator.
Since the iterator only has references to next and previous, it doesn't get affected by removing elements from the list.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then why does clearing hotcues work?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is definitely wrong: "... any non-const function call performed on the QList will render all existing iterators undefined."

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use this one:
http://doc.qt.io/archives/qt-4.8/qmutablelistiterator.html

I remember it, because I just removed it from AnalyzerQueue ;)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried changing this to for (const CuePointer& pCue : m_cuePoints) { but it did not solve the issue.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm guessing there's something else being triggered elsewhere in the code that actually clears the hotcues...

@@ -746,6 +746,42 @@ void Track::removeCue(const CuePointer& pCue) {
emit(cuesUpdated());
}

void Track::removeMainCue() {
QMutexLocker lock(&m_qMutex);
for (const CuePointer& pCue : m_cuePoints) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use QMutableListIterator and remove() through the iterator

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried that and it is not the issue. I think Track::removeHotCues is working because of some non-obvious side effect it has.

m_cuePoints.removeOne(pCue);
}
}
markDirtyAndUnlock(&lock);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only mark as dirty and emit signals if at least one item has been removd

@@ -246,6 +246,9 @@ class Track : public QObject {
// Calls for managing the track's cue points
CuePointer createAndAddCue();
void removeCue(const CuePointer& pCue);
void removeMainCue();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Combine into a single function with the cue type as a parameter

@uklotzde
Copy link
Contributor

Clearing the musical key is missing. We should include all analyzed results in the "Clear" menu.

@uklotzde
Copy link
Contributor

uklotzde commented Dec 21, 2017

I need to access the "Change BPM" options very often when tagging new tracks. The deep nesting is very inconvenient if you just want to half/double and subsequently lock the analyzed bpm.

I suggest moving the BPM options into a top-level item named "Adjust BPM >". This might also include an entry to clear the the current value and beatgrid in addition to the dedicated "Clear >" section.

@uklotzde
Copy link
Contributor

uklotzde commented Dec 21, 2017

"Clear" should not be nested in "Metadata", because it also includes track markers and analysis results that are stored separately. I suggest to move it to the top level.

@ronso0
Copy link
Member

ronso0 commented Dec 21, 2017

I need to access the "Change BPM" options very often when tagging new tracks. The deep nesting is very inconvenient if you just want to half/double and subsequently lock the analyzed bpm.

Yes, BPM is also my n°1 action, followed by Properties & Show file in folder

@Be-ing
Copy link
Contributor Author

Be-ing commented Dec 22, 2017

image

@Be-ing
Copy link
Contributor Author

Be-ing commented Dec 22, 2017

Unless anyone has a clear idea why clearing cues only works for hotcues and fixing that can be done quickly, I think we should merge this without implementing clearing the main cue and loop.

@daschuer
Copy link
Member

I need to access the "Change BPM" options very often when tagging new tracks. The deep nesting is very inconvenient if you just want to half/double and subsequently lock the analyzed bpm.

Yes, BPM is also my n°1 action, followed by Properties & Show file in folder

Yes, right. Reading this I can also remember to some emergency tweaks, after loading a track, and recognise an bpm issue. On the other hand this should somehow to a decks menu we do not have.
In any case this is a DJing use case wich should be instantly accessable.
How about moving bpm back to root for 2.1?

@Be-ing
Copy link
Contributor Author

Be-ing commented Dec 22, 2017

I'm reluctant to add any more to the top level of the menu now that the 3 AutoDJ items are back at the top level and Clear is at the top level. Is clearing the beatgrid really so urgent that it can't be behind one submenu?

@daschuer
Copy link
Member

I can live with the current state, because it is actually wrong in the library at all, but we have two additional voice for it.
Why is clear on the top level?

@poelzi
Copy link
Contributor

poelzi commented Dec 22, 2017

👍
Tho I have to say, I barely need hide from library and most of the time i press it by accident. Resulting in me searching the tracks in the hidden list just to unhide them again. It would be nice if it at least asks every time not only when it's in playlists. (There is no undo)

@Be-ing Be-ing mentioned this pull request Dec 22, 2017
8 tasks
@daschuer
Copy link
Member

@Be-ing, what is the state here? We are ad our beta deadline, and this one cannot be merge after beta.
Postpone this?

@Be-ing
Copy link
Contributor Author

Be-ing commented Dec 23, 2017

I'm okay with merging this as-is.

@daschuer
Copy link
Member

OK! Thank you.

@daschuer daschuer merged commit ea4b987 into mixxxdj:master Dec 23, 2017
@ronso0
Copy link
Member

ronso0 commented Dec 29, 2017

Thanks for cleaning up the menu. But now that I'm reviewing, sorting and clearing out my tracks of 2o17, I really miss

  • BPM
    please put tis back to top level, it's important: Mixxx doesn't recognise the beats of most of my footwork and jungle/dnb tracks, in most of the cases I have multiply it by 2 or 3/2
  • Hide from Library
    is this control still available at all? hiding recordings, long mixes and temporary files from track library is important

@nopeppermint
Copy link
Contributor

in my opinion it would be nice to just show the actual displayed sampler deck and not all 64 in the context menu..

@Be-ing
Copy link
Contributor Author

Be-ing commented Dec 29, 2017

in my opinion it would be nice to just show the actual displayed sampler deck and not all 64 in the context menu..

That is a good idea. We'd have to unify the ControlObject names used by skins first.

@naught101
Copy link
Contributor

naught101 commented Jan 4, 2018

OMFG, the new context menus are SOOO GOOD. So much clearer, and it's so great how you can add to multiple crates/playlists without the context menu closing! Thank you! 🎉

When I'm in DnB mode, I agree with ronso0 re: the BPM stuff, but I'm in trip-hop mode now, and it's fine. Maybe it would be better to instead work on the analysis engine's response to DnB?

"analyse" would be a super useful addition to the menu - would save always having to scroll to the bottom of the library side bar. But that might be fixed with the library redesign anyway?

@Be-ing Be-ing deleted the track_context_menu branch January 4, 2018 07:15
@Be-ing
Copy link
Contributor Author

Be-ing commented Jan 4, 2018

"analyse" would be a super useful addition to the menu - would save always having to scroll to the bottom of the library side bar. But that might be fixed with the library redesign anyway?

I agree. The tricky part is where to put the analysis progress information. In 2.1 only the Analyze library feature has a place for that information. I think we should keep this in mind when we come back to the library redesign. We may find other uses for a general purpose area for library context information, for example showing the cumulative duration of selected tracks. I opened a Launchpad bug for this a while ago that I have targeted for 2.2, but no one has yet volunteered to implement it.

@Be-ing
Copy link
Contributor Author

Be-ing commented Jan 4, 2018

If there is a consensus for moving the BPM editing submenu back to the first level, I'd be okay with that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants