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.