Shotcut freezes when using system open/save dialog with using Clipboard (Linux Mint)

[catscarlet]

This tracker is for defects only! For feature requests, see our discussion forum.

OS and Version (please complete the following information):

• Operating System: Linux Mint 22.1 Cinnamon, based on Ubuntu 24.04. Cinnamon version 6.4.8,
• Shotcut Version: 25.07.26, shotcut-linux-x86_64-250726.AppImage

Describe the bug When try to open/save with system dialog, after trying cut/copy/paste filename, shotcut and dialog freeze.

Steps To Reproduce

1. Start Shotcut
2. Open file / Save file
3. Type something on filename
4. Select some chars of the filename and try cut/copy (both mouse and keyboard work), and shotcut freezes

Expected behavior Nothing wrong should happened

Screenshots There is no screenshot. Instead, I recorded a video to show how it looks. Here is the video link: https://youtu.be/IArElxb9zcU

More info

• Sometime the freeze will end after a long time waiting.
• I think this issue exists very long time ago, even when Shotcut was using a old version of QT.
• Other applications like xed and pulsar don't have this issue so I don't think my system is broken.

[ddennedy]

This appears to be a bug in Qt's native file dialog integration because Shotcut does not make that dialog or have code that interacts with it. We simply tell Qt to make a QFileDialog to get a filename. I did not reproduce it on a GNOME-based desktop because we have code to tell Qt not to use the native file dialog under Windows in certain circumstances:

QFileDialog::Options Util::getFileDialogOptions()
{
#if defined(Q_OS_UNIX) && !defined(Q_OS_MAC)
   if (qEnvironmentVariableIsSet("SNAP") || qEnvironmentVariableIsSet("GNOME_SHELL_SESSION_MODE")) {
       return QFileDialog::DontUseNativeDialog;
   }
#endif

That arose out of having various difficulties with Qt's native file dialog integration. People prefer the native dialog not only for familiarity but because it will have favorite locations across apps. I will do some more testing of combinations of things and probably use the non-native dialog on anything except KDE desktop. It looks like this

[catscarlet]

People prefer the native dialog not only for familiarity but because it will have favorite locations across apps.

Yeah the system native dialog is the easiest for basic user. All I know is the QT's file dialog doesn't support a lot like 'recent file' and 'system mount point', some of them are the linux only feature. I'm using KeePassXC with is also Qt and the file dialog is terrible. Also GIMP (I only know the old 2.10.36 one) also has a different file dialog. I don't know how they made it. I'm not much a fan of native app developing.

[ddennedy]

Good news. I found that the Flatpak, which uses the very recent Qt 6.9 version did not reproduce the problem on Linux Mint 22. AppImage must use an older version 6.4 of Qt for binary compatibility on a wider range of Linux systems (somehow Flatpak is better at doing that). So, this problem should go away when I next update Qt in the AppImage and portable builds. Since the Ubuntu 20.04 standard support ended on May 31, I plan to upgrade the builder image to 22.04 and Qt 6.9 for the next release.

[catscarlet]

So I tried the Beta version shotcut-linux-x86_64-25.10.10.AppImage which seems is using qt6.8.3.

Are we going to give up the system native open/save dialog ?

open/save dialog in shotcut-linux-x86_64-250816.AppImage and former

open/save dialog in beta shotcut-linux-x86_64-25.10.10.AppImage

As I know, OBS is also using Qt6 as dependencies but it has no issue on clipboard. I still don't understand why is Qt6 broken the clipboard. I also searched and found many of them which have QFileDialog freezes issues.

[ddennedy]

Qt 6.9 or 6.10 cannot be used due to a bigger, blocking bug #1721 that Qt has not yet fixed. 6.9.1 cannot be used because I had to add QWebSockets, which is not longer available for 6.9 in the Qt SDK installer. Shotcut uses Qt's binaries for most builds and platforms rather than build it ourselves. I did not change anything else for this bug report in the beta, and I do not plan to . The dialogs are going to stay the way they are.

[ddennedy]

Hi Cat, I changed my mind because I was growing impatient with the very slow performance of the Qt file dialog. Also, I reviewed the history of disallowing the native GNOME dialog and found it to be a corner case well commented so I could test it. You can see 9e6e4823 for reference, but basically, we now have a higher minimum version of glibc for our builds that disqualified Ubuntu 18.04. Also, I tested the scenario from the commit's comment on Pop_OS! 22.04 with Qt 6.8.3 and did not reproduce it. However, I still reproduce this bug, which is less prevalent now with the GNOME file-open dialog since it does not have a text field unless you press Ctrl+L. In all my tests, it eventually recovered after a good wait--as you noted in the report, except it was 100% the case for me. Still, I can understand that some people will not be patient and assume it dead-locked. In fact, the very slow Qt dialog can create the same illusion with multiple not-responding warnings, and that is much more prominent.

In short, v25.10 will have GNOME native dialog except under Snap.

[catscarlet]

which is less prevalent now with the GNOME file-open dialog since it does not have a text field unless you press Ctrl+L

Well actually the most case I encounter this issue is saving so the text field is the case.

Still I don't understand why this issue exist. I'm not familiar about Qt and native program development.

[catscarlet]

Just tried version 25.11.2. also I don't know what's the different between 25.10.31(which is not exist in linux) and 25.11.2

I think I will stay at 250816 for a while

[ddennedy]

Here is the 25.11.2 AppImage file dialog on Pop!_OS 22.04

I guess the Qt 6.8 SDK, which is what we use, not distro packages, lacks integration on Cinnamon.

The only difference between 25.10.31 and 25.11.2 is the build to bundle additional libs for portable/AppImage/Snap.