Wrong crate highlighted after after drag and drop

[naught101]

To reproduce: Say you have a song in crate 1, and you want to move it to crate 2 (e.g., copy, then delete from crate 1)

1. Drag track from crate 1 to crate 2
2. Library still shows contents of crate 1, but sidebar has crate 2 selected
3. Right-click on track in library (apparently showing crate 1), and click "remove".
4. Track is removed from crate 2. Library view switches to crate 2, which now no longer contains the copied track (e.g, you're back at step 0).

if at step 3. you try to remove a track that is *not* in crate 2, nothing will be removed from anywhere, and the library view will switch to crate 2.

Proper behaviour should be:
2. Library shows crate 1, and side-bar has crate 1 selected. I assume that this will make the remove remove a track.

Ideal additional behaviour: Implement a "move" function, perhaps with shift-drag.

[orens (richterskala)]

Just discovered this problem as well.

I think the whole problem would be solved, if Mixxx wouldn't select the crate after you move a file in it. This can be annoying, if you're working with the filesystem browser to build up your crates and after every action you have to move the view back to where you were.

Is there a reason the selection jumps to the crate you drop a file in?

[Daniel Schürmann (daschuer)]

This should be already fixed in 1.12 beta. Right?

[orens (richterskala)]

Bug still persists in built from current beta branch.

Skimming through the PR from the corresponding bug report suggest that it was only fixed in BasePlaylistFeature, while CreateFeature inherits only from LibraryFeature.

In fact I can not recreate the bug if I use Playlists instead of crates.

[Daniel Schürmann (daschuer)]

Related Bug: https://bugs.launchpad.net/bugs/1454722

I cannot confirm this in the master branch using Ubuntu. Crates and Playlists works as desired.
Will check 1.12 soon.

[Daniel Schürmann (daschuer)]

I cannot confirm this using current recent 1.12 r5561 on Ubuntu as well.

* go to library view
* open crates tree
* drop track to crate
* library view remains unchanged
* however, the treview highlight is moved to the crate drop target
* focus remains on the library view and I can drop an other track

The same happen if I drop a track from browse view and from other crates.

What happens during your test case? What Os, version of Mixxx do you use?

[orens (richterskala)]

Isn't the moved highlight exactly the wrong behaviour?

Here is what I do to confirm wrong behaviour:

* go to library view
* open crates tree
* create empty crate A
* create empty crate B
* drop two tracks into crate A
* select crate A
* select track in crate A and copy it to crate B (either drag & drop or right click menu)
* crate A will have two tracks, crate B will have one. Library view remains on crate A while highlight moves to crate B
* right click selected track and remove
* the track will be removed from crate B!

In this end crate A will still have 2 tracks, while crate B will have 0 - although you'd expect to remove the track from crate A because that's the crate that was listed to you in the library view.

Furthermore: If you do the same steps with playlists instead of crates, mixxx will do the (in my eyes) expected behavior and deletes the track from playlist A

I run Arch Linux and Mixxx r5564

[orens (richterskala)]

Sorry, Mixxx 1.12 r5564 that is.

[Daniel Schürmann (daschuer)]

I see, due to the the wrong highlighting you cannot distinguish the two crates since they have the same content.

[Daniel Schürmann (daschuer)]

Do you have fun to fix this issue yourself?
Hints:
http://www.mixxx.org/wiki/doku.php/bugfix_workflow

[orens (richterskala)]

Alright, I'm on it

[Daniel Schürmann (daschuer)]

Great!:-)

[orens (richterskala)]

https://github.com/mixxxdj/mixxx/pull/737

[-MK- (mk42)]

Was merged, so should be fix comitted?

[Owen Williams (ywwg)]

right, thanks

[Swiftb0y (swiftb0y)]

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