Drag and drop doesn't work for importing file with Greek characters

[Daniel-Mantzakos]

System Details:

• Operating System / Distro: Windows 10 Pro 64 bit Version 1709
• OpenShot Version: 2.4.1

Issue Description and steps to reproduce: As the title says, when you drag and drop a file containing Greek characters in its title, it doesn't get imported. There is no crash during the process. The import from the menu though works as expected.

[ferdnyc]

Just to clarify, when you say the file has "Greek characters in its title", are you talking about the filename of the file? Or a title field stored in the file properties? Video and audio files can contain a title that's separate from the filename, which players like VLC and Windows Media Player will use.

Also, does it matter what type of file it is: video, audio, or image? Or does it happen for any type? (This question probably only makes sense if you're talking about filenames.)

Can you provide an example title (if not example file) that causes the problem? I don't have any files titled with greek characters (that I know of), and I wouldn't know how to go about creating one in order to test the problem.

[Daniel-Mantzakos]

@ferdnyc I am talking about filename.

This issue happens for any type of file (audio, video and images).

In order to reproduce the issue, you can rename a song or picture or video you already have with the first letter of the Greek alphabet, for example, which is α. You can then drag and drop it into OpenShot and verify that it's not working.

[ferdnyc]

Gotcha, thanks.

Hmmm. I renamed a video file to α.mp4 and an audio file to ααα.mp3, and had no problems importing both by drag-and-drop from my Desktop to the OpenShot window.

...I'm guessing the reason it works for me is because I'm on Linux. So this looks like it may be a Windows-only issue. I'll try to find some time later on to spin up my Win7 VM, so I can test it there.

[Daniel-Mantzakos]

Ok, then it should be a Windows issue. I also found a more general problem. Even if the filename does not include Greek characters, the file won't be imported by drag and drop if the location path of the file contains Greek characters. I did a test by creating a Greek named folder on my desktop and pasting inside it an audio file with only English characters in its filename. The file still wouldn't be imported by drag and drop, because its parent folder was named in Greek.

[ferdnyc]

OK, good information, thanks. I'll be sure to test that, too.

[ferdnyc]

I can confirm, under Windows 7 x86_64, using OpenShot 2.4.1 installed via the official site's installer.

After creating two files, C:\Users\ferd\Desktop\α.mp4 and C:\Users\ferd\Desktop\ααα\test.mp3, attempting to drag either file onto the OpenShot window has no effect. There is nothing logged about the drag attempt, even in debug mode. It just silently fails to do anything, as if it never happened.

Dragging either file to the timeline causes the standard log message to be output:

timeline_webview:INFO Dropping item on timeline - item_id: None, item_type: os_drop

...indicating that the drag was received by OpenShot, but then nothing further.

Selecting "Import File" and selecting the same file(s) via the file dialog imports them without incident, and OpenShot then logs the successful import:

files_listview:INFO Adding file: C:/Users/ferd/Desktop/ααα/test.mp3

This is in contrast to Linux, where (in debug mode) the same drag operation results in the file being imported normally, just as if it was selected via "Import File":

files_treeview:INFO Adding file: /home/ferd/Public/OpenShot/ααα/test.mp3

This may have something to do with the different ways that pathnames are handled by Windows and Linux when non-ASCII characters are present. Linux always uses UTF-8 encoded filenames. Windows/NTFS stores pathnames encoded UTF-16 internally, but some libraries and functions will fall back to ANSI encoding (presumably ISO-8859-1) unless Unicode support (specifically, UTF-16 encoding) is enabled.

I'm surprised that PyQt doesn't automatically take care of all this behind the scenes, since as far as I know OpenShot uses Qt's file/path classes throughout. It's probably supposed to, but there may be something more that needs to be done when running on Windows to make Qt process drop events the right way.

Or it could be a bug present in Qt/PyQt. Either one that's still present in their current codebase(s) — though I'd be very surprised if nobody had discovered it until now — or one that's already been fixed, and is only found in the older version(s) of Qt/python/PyQt currently being bundled with the Windows installer. We should definitely look into whether this can be fixed by simply updating the dependencies.

[ferdnyc]

I'm hopeful this is fixed by the patch in PR #1539, which uses a more Qt-native method of translating the URIs encapsulated in the drag-and-drop event into local file paths. Unfortunately, I'm only able to test it on Linux, where the old method wasn't causing any problems. The new method continues to work the same on Linux, which is good, but the real question is whether it improves things on Windows. The answer to that question will have to wait until we can get the patch incorporated into a Windows build of OpenShot and test it out.

[DylanC]

@Daniel-Mantzakos - Can you try this in a daily build? @ferdnyc put in a fix for this issue recently.

[misterhatoola]

@DylanC, This issue occurred with Hebrew characters as well. Just tried it with the latest daily build, and it works fine - files with Hebrew characters in their filenames, or in the folder name, drag just fine into OpenShot's window. Thanks a lot!

[DylanC]

@misterhatoola - Excellent. Fantastic news to hear. :) Btw, @ferdnyc your PR is working perfectly for users. Well done!