Partially Functioning Drag & Drop with local build - Suggestions where to look?

I’ve cloned Picard locally from my forked repo.
I build it this way: “ICBMx6:picard tdiaz$ pip3 install . --user” and then launch with “picard”

Drag and Drop works at first. I can select any one item. (Track or Folder) and drop it right back where it was. No issues. If I drag it across panes, placing it in the other pane it works.

Then no more drag & drop / proper selecting fully works again until restarting the application.

Two things stop working working fully, and I suspect the latter is part of the former.

Typical behavior when a file is dragged from one pane to the other:
Click to select.
Holding the button, it highlights.

**When you start dragging the file, **
the highlighted rectangle stays with the cursor, turning to a semi-transparent mode, it as you start moving across the window.

When you reach a specific targeted folder, the folder will highlight.
Let go and it goes into that folder. Done.
If you don’t go for a specific target folder, just the window pane in general, it does whatever depending on which side it’s dropped on.

What I’m getting after an initial successful action is I can still select single, or multiple items as usual. (Dragging over the whole list, clicking a single, using the shift and/or Open-Apple key to is at the start of dragging. The intended selection(s) highlight in the expected order based on which keys are used. e.g.: I can select a whole range, hold down the Apple key, click to deselect single ones, add others outside of the range, etc. All good there.

With multiple selections highlighted, I go to grab the selected items, it deselects them all, leaving just the one I clicked on highlighted. But it does not move with the cursor. The same goes if i clock on just a single, continue holding down the button and start to drag. It just stays selected like nothing happened.

Additionally, once it’s in that state, dragging anything from the desktop or File Browser onto Picard is practically ignored. A couple tracks may pop into the Unclustered Files. They won’t scan, lookup, anything. Any attempts to add files/folders to Picard is like you’re dropping the stuff in the wrong place. It’s just not going to have anything to do with it.

Terminal output:

QDragManager::drag in possibly invalid state
QDragManager::drag in possibly invalid state
QDragManager::drag in possibly invalid state
Empty filename passed to function
Empty filename passed to function

I’m doing this stuff with the intention of eventually either adding a selection in Options, or via Plug-in.

The changes I have made are minor, at least to me, given the scope of the whole thing. I changed the colons in the time format to “%dh%02dm%02ds” from “%d:%02d:%02d”, and the two place just has the ‘m’, with the ‘s’ added to the end. “%dm%02ds”

This also affects the display in Picard as well, FWIW. (Of course it does, an unintended side effect.) But it does the intended action when saved to disk. I suppose a way around that would be to get a variable for hours, minutes, seconds individually and place the desired h,m,s next to it. But I don’t see that easily happening script wise right now. I may have missed something? I added a few more files to ignore when considering the folder empty for deletion. I added additional sample data in example_1 and example_2 I changed the center section def _rename to break down the os.path, append the (x) to the next higher folder name, and continue as normal.

I also added the library for discid. I get no errors from the build.

Terminal Output:

ICBMx6:picard tdiaz$ pip3 install . --user
Processing /Users/tdiaz/Merlin/picard
Requirement already satisfied: PyQt5 in /usr/local/lib/python3.7/site-packages (from picard==2.2.1) (5.13.1)
Requirement already satisfied: mutagen in /usr/local/lib/python3.7/site-packages (from picard==2.2.1) (1.42.0)
Requirement already satisfied: PyQt5_sip<13,>=4.19.19 in /usr/local/lib/python3.7/site-packages (from PyQt5->picard==2.2.1) (4.19.19)
Building wheels for collected packages: picard
  Building wheel for picard ( ... done
  Stored in directory: /private/var/folders/rc/wr8mtd6n33b4t58sb172c2y40000gn/T/pip-ephem-wheel-cache-m26n0rbv/wheels/b0/63/39/a228f2935157f99654339c887b8925a4ba4bd92c217d74b11e
Successfully built picard
Installing collected packages: picard
  Found existing installation: picard 2.2.1
    Uninstalling picard-2.2.1:
      Successfully uninstalled picard-2.2.1
Successfully installed picard-2.2.1
ICBMx6:picard tdiaz$ 

Otherwise any other terminal output looks like the usual:

E: 16:57:57,264 /Users/tdiaz/Library/Python/3.7/lib/python/site-packages/picard/webservice/__init__._handle_reply:387: Network request error for Error transferring - server replied: Not Found (QT code 203, HTTP code 404)
E: 16:57:57,264 /Users/tdiaz/Library/Python/3.7/lib/python/site-packages/picard/album.error_append:259: CAA JSON error: Error transferring - server replied: Not Found
E: 16:57:57,573 /Users/tdiaz/Library/Python/3.7/lib/python/site-packages/picard/webservice/__init__._handle_reply:387: Network request error for Error transferring - server replied: Not Found (QT code 203, HTTP code 404)

I have not yet gone back and replaced the modules each individually or in total and built again to see if the same behavior continues. I wouldn’t be surprised, but the changes I’ve done just seen so far unreleated to dragging / dropping. I just don’t get it.

I got the terminal output in the process of posting that and then thought of the os.path stuff. Though it is in the saving file process and, I presume, not looked at during drag and drop, otherwise am I possibly leaving something hanging with the os.path manipulation?

This is strange, I can’t really reproduce this here. And you are right, your changes do not really explain such behavior. I wonder if it is actually a Qt bug.

Can you please:

  • Post the output of picard --long-version so we can compare the exact versions of installed dependencies, also please tell us the macOS version you are using
  • Please try if you can reproduce the issue without your changes
  • If you cannot reproduce this without your changes, we know it must be something in those changes causing this. In this case please provide us with the exact changes. Best probably would be to just push your changes to a branch on Github and give the link to your repository
  • One thing to test would be to use different PyQt versions. Try pip install PyQt5==5.12, maybe also 5.11 and 5.10 (5.10.1 was what we used for the official Picard 2.1 builds, the latest use 5.13.0).

Somewhat this reminds me of the issue reported at, even though it is describing different symptoms (problems with the toolbar). But the common thing is that event handling is somewhat messed up. Any chance that this is in your case also with the trackpad and it behaves differently with a mouse?

Otherwise I am currently a bit out of ideas. There is a chance that this is somewhat depending on the macOS version, I personally can only test on macOS 10.14.

1 Like

Another thing: In case you have PyQt 5.13.0, please try with PyQt 5.13.1. There have been some trackpad fixes in this release, I have some hope these could fix the issue. And if you are already using PyQt 5.13.1 and this does not fix the issues please let me know that this theory is bonkers :wink:

1 Like

--long version from 2.2.1 Download / Release dmg dc41cc2eab8f8c3419a82c1f04a0dafc (Matches)

Picard 2.2.1, Python 3.7.4, PyQt 5.13.0, Qt 5.13.0, Mutagen 1.42.0, Discid discid 1.1.1, libdiscid 0.6.2, astrcmp Python, SSL Secure Transport, macOS Mojave (10.14)

--long version from 2.2.1 built from source with all changes backed out.

Picard 2.2.1, Python 3.7.4, PyQt 5.13.1, Qt 5.13.1, Mutagen 1.42.0, Discid discid 1.2.0, libdiscid 0.6.2, astrcmp C, SSL Secure Transport, macOS Mojave (10.14)

Slight version number changes and the Distribution Package shows an extra ‘Python’, while the one I built shows ‘C’.

With all changes backed out, it still exhibits the same behavior.

QDragManager::drag in possibly invalid state
QDragManager::drag in possibly invalid state

My PyQt and DiscID are newer versions, otherwise outside of those other differences above.

pip3 install PyQt5==5.12
pip3 install . --user
picard --long version confirms PyQt 5.12


Same result after one successful drag & drop:

QDragManager::drag in possibly invalid state

PyQt 5.11 is not available, used 5.11.3.
Did -NOT- rebuild the code base, just executed it. Interestingly, the Main Window popped up much smaller than I had it, where as all the previous runs from build and bouncing back to the installed 2.1 would restore the larger size window that I had left when I closed it.

Same deal, same error.

QDragManager::drag in possibly invalid state

Launch 2.1 and it works properly.

Launch 2.2.1 from the dmg and it has the same error with 5.11.3

QDragManager::drag in possibly invalid state

5.10, same thing**

A little further narrowing down. It seems I can drag left <–> right all I want, albums (from the right) from a non-exposed view and individual tracks, all I want. I can drag back individual tracks all I want, one at a time.

If I select Cluster with files on the left side, I can no longer drag a track file as the very next move.

Quit, launch again.

Drag an album back to the left.

Select more than one item. Drag does not work. Throws the error in terminal.

Quit and Launch once more.

I can drag all the albums I want to the left, I can drag all the single tracks I want to the right again.
I can select multiple tracks, deselect them, it still drags.
But … if I select multiple tracks from the unclustered list, the moment I go to move them, it will not react at all, not even deselecting them. But the next time I click to move, they become unselected and the error comes in terminal.

If I drop tracks that have no MBID on them, so they stay on the left, and I use the search, for any album… I entered Boingo, and picked the first one.

I can drop all the tracks, obviously wrong, that I want onto that album and they will go into the unmatched items.

I can drag those back to the left, and then drag to the right, again, one at a time. No problem. Of course, if I just drag them to the main window on the right, they will just slingshot back to the left as expected behavior, since I did not drop it on an album or track.

S’all good so far.

Then I select several, unselect them one at a time, by clicking with the Apple key held down, until I have just one remaining selected, I can drag that back to the right again.

Select two or more, click on them to drag, nothing happens, no error in terminal, the items in the window do -NOT- become unselected.

Release and click again, everything but the one I actually clicked on will go un-selected. Actually, they all do, but the one I clicked on immediately goes back to selected, because I clicked on it. Try to move it and the error shows in terminal.

Quit, Launch again, drop tracks with no MBID, ones that do not respond to clustering on the left, click cluster, nothing moves. But drag does not work immediately from that point. Without having completed a succesful one. As in envoking the cluster option once it’s available, with or without any tracks that will cluster and that’s it. Game over. No more dragging. (and no more dropping folders from Finder into Picard. They’re just ignored.

So the gist of it all is… it appears that whatever version of PyQt, and the build from the source tree, it does not work. I am using the latest Xcode, but on 10.14.1.

I restored PyQt to 5.13.1 and restored my changes, built it again, no behavior changes. It’s all the same errors with the same steps.

I need to setup a key to send into github, as I have not done that still, on this machine. I’m still pretty green with git, still stuck on using my own hosted svn, but converting to github is in progress. Time to stop clinging onto that ‘old’ stuff, at least where I don’t. I have some MPW IIgs projects that I can’t use git for.

Do you want to build the source tree I have? I’ll just send the zipped directory somewhere, and a screen shot showing the 4 files with changes in them.

I’ve had enough of building, dragging, quitting, wash, rinse, repeat … for now. :wink:

SO if I understand correctly the official 2.2.1 build available from the download pages show the same buggy behavior, right? I will try to reproduce this on my mac a bit more. It is indeed very strange.

That’s another packaging bug unfortunately. Nothing affecting the functionality, but definitely not good for performance. Need to look into it.

1 Like

The 2.2.1 release package didn’t always do it, but it did on a few of those go arounds. It was a lot -less- predictable. (!?!?!) Freakin’ software. It’s amazing things work as well as they do considering the enormous varieties in user installations, and that’s just on the Mac side. Windows? OMG. 150 different motherboards, 11 million different options for Windows.

Even Linux is way more predictable than that, it’s it’s a roll your own OS. :wink:

1 Like

Reading Ticket 1612 again, I wonder if this may be related to that. I’m using a Kensington USB trackball. It just occurred to me that with it’s programmable buttons, it may be similar to how the Trackpad works.

Though that doesn’t necessarily explain the part about it working until the first time Cluster is used, or a Multiple Selection is dragged.

So I tried this again, but I am unable to reproduce this. But I can only test on macOS 10.14 and only with a normal mouse.

But could you test the following build:

Here we have the fix for PICARD-1612 included, so if it is related maybe this build also works for you.

This one works. So PICARD-1612 isn’t really Trackpad specific, but I figure something with the multiple button input flexibility overall.

But it works.

Now I have to move my changes over for a new build. :wink:
I’ve got to figure out how to make them into configurable Options … before I even think of submitting them for consideration, and document things fully, too, so one knows whats being considered.

1 Like