DragAndDrop - **Wine** on MXLinux v23, KDE

Yes, I KNOW this is not supported, Florian :slight_smile: But figured I'd ask my question.

Q: I assume that mp3tag is using different OS mechanisms (libraries?) for its File > Add Directory and drag-and-drop file open methods; what are they?

Long Story

I have MXLinux v23, KDE Plasma 5.27. mp3tag versions 3.22b (64-bit) and 3.20 (32-bit), both mp3tag versions are the portable installs self-contained in their folders (as the current installer no longer successfully completes under wine).

This combination works nearly flawlessly! I've been using it for several years through changes from Kubuntu to MXLinux KDE and mp3tag v2.x to the current versions. It really is remarkable just how well it works.

I think the basic issue is the difference between Windows and Unix file naming conventions. mp3tag is a Windows application so expects that files conform to Windows naming conventions and that they do not use Windows prohibited characters. Understood and accommodated.

I've discovered that UTF16 characters work for both filename and tags. I've been using them to substitute apostrophes, double-quotes, etc. which mp3tag successfully writes to filenames (I use mp3tag extensively to rename files so they align with tags). For example, Charles-Marie Widor's 10th Organ Symphony is titled "Romane." So, the filenames include "Romane" in them. mp3tag will not open them via drag-and-drop. If I modify those double-quotes to “ and ”, mp3tag will open them. But only in one way, thus this post.

If I File > Add Directory, mp3tag will open these files without issue, and it displays both filename and tags that use them. I can add them, remove them, use Tag->Filename with them, and mp3tag works without complaint.

Drag-and-Drop works without issue most of the time. I've loaded in one operation 1000s of files this way in 100s of directories. So, drag-and-drop functions. Yet if I drag-and-drop from my KDE Dolphin file manager files that contain these characters, or files in a folder named with these characters, mp3tag will crash. v3.22 will simply die and the UI will vanish. v3.20 will freeze and become unresponsive requiring a hard kill.

The inconsistency is that mp3tag opens these files if I use File > Add Directory, but not if I drag-and-drop them. And that seems, well, odd.

Back again to the Q: I assume that mp3tag is using different OS mechanisms (libraries?) for these two different "file open" methods; what are they?

Within wine's environment I can manipulate Windows dlls, etc. in an attempt to modify this behavior, but I need to know which ones.

Why is this important? My music library is primary Classical, Choral, Jazz, and Opera. Often opera recordings may have extensive track information that is in Italian, French, etc. that use Windows reserved characters (eg., a ? when the aria contains a question). I wrote a script to parse filenames to substitute UTF16 characters for the Window reserved characters. This works most of the time so that mp3tag does not fail on loading them.

But it is a fair bit of hand-editing at the file level to identify filenames and manually modify them so I can drag-and-drop them onto mp3tag when mp3tag does fail on loading them

Yes, I can use File > Open Directory when this occurs, but that requires navigating through File Open dialogs which is awful compared to drag-and-drop. And thus my Q to see if I can find a way to prevent mp3tag from failing on drag-and-drop of these files. Like I wrote, I know my use case is not supported, but figured it doesn't hurt to ask anyway. Boldly ventured is half won, as the saying goes.

I do not think that this is odd.
As long as you stay in the Wine environment everything is fine.
If you open files with Fie>Open Folder, then the MP3tag issues the file system calls to the OS, here: Wine, and Wine translates them to a Windows compatible format.
If you D&D files from outside Wine, then the filenames do not get translated, apparently (although I would have assumed that Wine would do that).
So you would need to open the Wine file manager and try to drag&drop from there.

1 Like

ohrenkino - thanks for your reply and I think you are spot on. I had previously attempted to open Wine's Explorer and drag-and-drop from there. Nothing doing ... and as I typed that, I remembered that Wine offers an option to allow the Linux window manager to both decorate and manage <<< the windows. I have just disabled both of those and presto-chango, I can from the Wine Explorer drag-and-drop folders/files that use those extended characters!! I would never have thought to do that without your post (the Wine default is to enable those options, which allows Wine apps/windows to work with virtual desktops, task bar, etc. which is usually just how one uses Wine - disabled, all of those are unavailable to the Wine processes).

Much thanks for the comment that lead to a solution of sorts. Means I need to decide which is more annoying, apps that don't "work with" the Linux window manager, or dealing with the drag-and-drop issue for only those files/folders with extended characters in their name.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.