[SOLVED] Qt file dialogues unusable since update

PepeCyB · 2022-09-05 09:33:11

A few days ago I noticed a strange behaviour with some applications. The first ones were Telegram Desktop and Focuswriter.
When I tried to open a file dialogue, it sometimes took minutes until it appeared. Canceling or selecting files was also "tough". I usually "shot down" the applications because it really took several minutes until they were usable again.

I then checked and found that they were both built with qt6. So I installed qt6ct as a test and set the environment variable QT_QPA_PLATFORMTHEME to "qt6ct". In the Qt6 settings I forced the use of Gtk3 dialogues.
This improved the behaviour, although file dialogues still felt "tough".

Now, however, I had to realise that the behaviour also occurs with Kate (KDE), for example. Sometimes there were even crashes right at the start. Above all, the file dialogues (and only the file dialogues - the problem does not occur with other dialogues) behave as described above. Kate, for example, is no longer usable for this reason.

I have now tried it out and the error occurs with all qt-used programs, regardless of whether qt5 or qt6... thus also with all KDE applications. But also with those without KDE dependencies. Opening or saving by bypassing the file dialogue always works smoothly.

Even resetting the qt5ct and qt6ct settings and deleting the qt6 system variables did not bring any improvement.

Any ideas? As a Plasma/KDE user, the system is no longer usable for me. Out of desperation I switched to Gnome or Gtk applications for the bare essentials (which I then also use under Cinnamon)... but that can't be the solution.

qt5-base 5.15.5+kde+r180-1
plasma-desktop 5.25.4-1
kde 22.08.0-1
linux 5.19.6.arch1-1
x11 1.8.1-3

Advanced Micro Devices, Inc [AMD/ATI] Cedar [Radeon HD 5000/6000/7350/8350 Series] (prog-if 00 [VGA controller])
AMD Athlon(tm) X4 860K Quad Core
16 GB RAM

Last edited by PepeCyB (2022-09-05 21:37:51)

seth · 2022-09-05 11:01:55

Do you use any remote filesystems?

ceterum censeo:

pacman -Qs 'flatpak|portal' # flatschpak has a track record of causing this

PepeCyB · 2022-09-05 12:23:39

local/flatpak 1:1.14.0-1
    Linux application sandboxing and distribution framework (formerly xdg-app)
local/flatpak-builder 1.2.2-3
    Tool to build flatpaks from source
local/flatpak-xdg-utils 1.0.5-1
    Utilities for containerized apps to launch programs outside the container
local/flatseal 1.8.0-2
    A permissions manager for Flatpak.
local/libportal 0.6-1
    GIO-style async APIs for most Flatpak portals
local/libportal-gtk4 0.6-1
    GIO-style async APIs for most Flatpak portals - GTK 4 backend
local/xdg-desktop-portal 1.15.0-1
    Desktop integration portals for sandboxed apps
local/xdg-desktop-portal-kde 5.25.4-1 (plasma)
    A backend implementation for xdg-desktop-portal using Qt/KF5

I do not use remote filesystems...

seth · 2022-09-05 13:10:47

Does it have any impact if you remove all the flatpak and libportal and xdg-portal-* packages (and re-login)?

PepeCyB · 2022-09-05 13:43:48

Since I only have a few flatpaks installed that I can do without, I will clean them off and uninstall the packages.

Then I'll test it again...

PepeCyB · 2022-09-05 14:38:32

I have completely uninstalled the above packages, then rebooted.

No improvement.

kate:

launch: < 1 sec
open file dlg: 6 sec
open small (! very small) text file: 6 MIN 40 sec

gedit:

launch: < 1 sec
open file dlg: < 1 sec
open small (! very small) text file: < 1 sec

All applications that do not use qt (5 or 6) work quickly and without problems with the file dialogue. Even applications that are still linked with qt4 work perfectly (just tried with masterpdfeditor v. 3).

All applications linked with qt5 or qt6 have this problem. But only and exclusively in the file dialogue.

I have the feeling that the error occurred after an update within the last week. Before that I used e.g. kate excessively. I pre-write a lot of texts in plain text format and use kate for that (of course I always saved and opened these texts... without problems).

seth · 2022-09-05 14:44:09

open file dlg: 6 sec
open small (! very small) text file: 6 MIN 40 sec

Yeah, no - that also doesn't fit the flatpak problem pattern (it somehow/probably just tries to dbus-activate a bunch of external processes before it finally "resorts" to the built in dialog)

Are there more/many/big files in the folder where you open the file?
Does that matter?

PepeCyB · 2022-09-05 15:58:43

No, I moved all the files once as a test and only left the one small text file (in my home directory). There are 36 subdirectories next to it... so not much either.

The times are still identical.

seth · 2022-09-05 16:12:54

"strace kate" - it'll likely go overboard while waiting for the dialog or worse, opening the file? - and might reveal what the dialog is doing there.

For clearification, is this the Qt or the KDE dialog?
What about

QT_QPA_PLATFORMTHEME=gtk2 kate
QT_QPA_PLATFORMTHEME=gnarf kate

(you can also use "qarma --file-selection", https://aur.archlinux.org/packages/qarma-git

PepeCyB · 2022-09-05 16:58:35

Here is a (shortened) strace file. I have cancelled the loading process. Somehow it hangs in a miserably long mremap loop: https://drive.exraucher.org/wl/?id=txck … gxlXStuaJR (self hosted filerunner instance)

After starting before kate and opening a file, the processor load for all four cores rises to 100 % and the physical memory usage from 2.4 to up to 5.7 GB. Swap memory is not used (there is also 16 GB of physical memory). Swap is done with 4 GB of ZRAM (only because there are applications that require swap, even if they don't need it).

Even gtk2 dialogues or gnarf dialogues do not bring any change.

PepeCyB · 2022-09-05 19:10:42

I now suspect that it could be a problem with the kernel.

I have just downloaded and started Focuswriter as an AppImage as a test. As far as I understand the concept of AppImages, these applications use their own package of libraries. If this is indeed the case, it should be impossible that it is due to qt.

Now I have to see where I can find information about downgrading the Linux system (kernel, etc.)... I've never had to do that before and I'd hate to break my system.

seth · 2022-09-05 19:37:23

https://archlinux.org/packages/?sort=&q=linux-lts - pay attention to nvidia-lts if you're using the nvidia driver.

So focuswriter causes the same?
What about "ls" (or "ls -l")?
Do you have the same problem when trying to open a dialog in /tmp (or any tmpfs)?

PepeCyB · 2022-09-05 20:39:17

"ls" and "ls -l" work quite normally. The file manager dolphin also displays the directories quickly and normally and allows a quick change.

Opening the text file from the file manager (also Dolphin or Nemo) with kate takes place without delay. The problem definitely only occurs in the file dialogue.

Starting kate in a tmpfs directory does not lead to any change there either. The file dialogue appears considerably delayed and opening a file takes several minutes.

Yes, FocusWriter is a qt application. The errors with the file dialogue occur with the version installed as a package, but also when FocusWriter is started as an AppImage.

Any application that uses gtk(2 or 3) dialogs works normally.
I had installed lazarus in the qt version. The file dialogue did not work (so extremely slow as described). After uninstalling lazarus and installing lazarus in the gtk version, the file dialogs worked again as usual and opening files also without delay.

Opening files directly with qt applications (e.g. "kate test.txt") also works without any delay.

seth · 2022-09-05 20:48:58

From your strace things seem to start around /home/daniel/.config/QtProject.conf
It gets opened, then there's a statx on the unlinked /home/daniel/.config/QtProject.conf.lock and then we go for a mmap/remap slide.

=> What if you move away /home/daniel/.config/QtProject.conf ?

PepeCyB · 2022-09-05 21:37:08

Thank you! The problem is solved! I deleted the QtProject.* files from .config (I don't know how they got there, they shouldn't have been there) and all problems are solved. Also the file dialogue for qt6 applications works again as usual.

It's really great that you helped me so well to localise the problem.

The Arch community is really great. I was already afraid that I wouldn't find a solution. I always try very hard to solve problems myself by researching, studying manuals and thinking. I only ask questions when I have absolutely no idea anymore. It was good that I asked here.

Greetings from Southern Hungary
Daniel "PepeCyB

Arch Linux

#1 2022-09-05 09:33:11

[SOLVED] Qt file dialogues unusable since update

#2 2022-09-05 11:01:55

Re: [SOLVED] Qt file dialogues unusable since update

#3 2022-09-05 12:23:39

Re: [SOLVED] Qt file dialogues unusable since update

#4 2022-09-05 13:10:47

Re: [SOLVED] Qt file dialogues unusable since update

#5 2022-09-05 13:43:48

Re: [SOLVED] Qt file dialogues unusable since update

#6 2022-09-05 14:38:32

Re: [SOLVED] Qt file dialogues unusable since update

#7 2022-09-05 14:44:09

Re: [SOLVED] Qt file dialogues unusable since update

#8 2022-09-05 15:58:43

Re: [SOLVED] Qt file dialogues unusable since update

#9 2022-09-05 16:12:54

Re: [SOLVED] Qt file dialogues unusable since update

#10 2022-09-05 16:58:35

Re: [SOLVED] Qt file dialogues unusable since update

#11 2022-09-05 19:10:42

Re: [SOLVED] Qt file dialogues unusable since update

#12 2022-09-05 19:37:23

Re: [SOLVED] Qt file dialogues unusable since update

#13 2022-09-05 20:39:17

Re: [SOLVED] Qt file dialogues unusable since update

#14 2022-09-05 20:48:58

Re: [SOLVED] Qt file dialogues unusable since update

#15 2022-09-05 21:37:08

Re: [SOLVED] Qt file dialogues unusable since update

Board footer