23.09.29 Open-File-Dialog practically unusable

Bug
1

What is your operating system?
Debian GNU/Linux 11 (bullseye)
5.10.0-25-amd64 #1 SMP Debian 5.10.191-1 (2023-08-16) x86_64 GNU/Linux

What is your Shotcut version (see Help > About Shotcut)?
23.09.29 / shotcut-linux-x86_64-230929.AppImage

Can you repeat the problem? If so, what are the steps?
100% reproducible. Just click “Open File”, file listings are super slow, any navigation is so slow that it becomes nearly unresponsive. Same for “Save As”.
23.09.12/shotcut-linux-x86_64-230912.AppImage did not suffer from this.

1 Like
2

same result on Xubuntu Ubuntu 22.04.3 LTS
6.2.0-33-generic #33~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Sep 7 10:33:52 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

1 Like
3

This is a known bug with AppImage outside of the Shotcut code, even previous versions. I do not know why.

2 Likes
4

AppImage user here, I can confirm the change - previous versions are fine. Edit: The portable tar version is not affected. Edit2: After a few days I can say that the portable tar version (with Debian 12) works very well for me.

5

i’ve been trying to do some research on the subject, but also get side-tracked to more important things…
some of the reports say that dbus is involved and should not be; however, disabling all of my dbus services did not resolve. some report mention various QT environment variables, but i have not found any successful (via shell export). Some reports say network shortcut and/or symlinks are a cause, but i don’t seem to have any inside the file-open dialog. I do in Thunar and need them. Some reports are code-based and therefore i cannot test. They speak of file-dialog options for QT to disable certain things like icon/thumbnail generation, maybe others. --appimage-extract does not fix either.
As of now, no solution found other than using non-Appimage, but to be honest i prefer AppImage. I’ve installed the flatpak until solved. :frowning:

6

two differing dialogs in old vs new versions

image
image2558×704 201 KB

edit: wondering if commit ad059f7 Dan Dennedy 2023-09-15 always use Qt's color dialog on Linux is the regression

why DontUseNativeDialog ??

src/qmltypes/colordialog.cpp:32:    flags = flags | QColorDialog::DontUseNativeDialog;
src/qmltypes/qmlmarkermenu.cpp:82:        colorDialog.setOptions(QColorDialog::DontUseNativeDialog);
src/util.cpp:468:    return QFileDialog::DontUseNativeDialog;
src/widgets/textproducerwidget.cpp:76:    flags = flags | QColorDialog::DontUseNativeDialog;
src/widgets/glaxnimateproducerwidget.cpp:94:    flags = flags | QColorDialog::DontUseNativeDialog;
src/widgets/editmarkerwidget.cpp:130:    dialog.setOptions(QColorDialog::DontUseNativeDialog);
src/widgets/colorproducerwidget.cpp:77:    flags = flags | QColorDialog::DontUseNativeDialog;
7

The color dialog is unrelated to the file dialog.

8

I am not having this problem with AppImage on Linux Mint 21.2 XFCE. The Open dialog takes a second at most to appear, and that’s probably because I have several network drives mounted.

I’m sure this information is not helpful, but figured I would toss it out there anyway. :slight_smile:

1 Like
9

v23.11.29 AppImage works again.
There was no mention of changes is this regard, but happy that proper/expected functionality returns.
Thank you!

10

Weird. We did not make a change, and it is still slow for me. Now, I just noticed it is related to the number of items in the directory it opens to. For example, mine had opened to an image sequence folder I had last done some testing on. The folder has 900 images. If I go to the parent folder with 25 items, open something, and then choose File > Open, it opens much faster.

1 Like