30sec Freeze per click in GTK3 file dialog under QT5 widgetset

[zeljko]

Your patch doesn't fix anything. It just call default Qt dialog (not system or theme one). I don't have enough hw to test all combinations and window managers, to me problem is x11 selection which comes from gtk3 dialog (since gtk3 selects filename or directory and fills X11 selection buffer) and runs in loop somewhere inside qtobjects.TQtClipboard eventFilter or signal. If we can catch the reason why it loops it can be fixed. I've already spotted same problem with gtk2 theme and qt4 few years ago.

[dbannon]

Given what we found back in May (rca), that the problem appears when the desktop is using X11 rather than Wayland and (sadly IMHO) Wayland is being used more and more, should we consider testing for X11 or Wayland at run time and allowing it to use the default QT dialog in those cases where the theme one will not work ?

Yes, its a ugly fix but better than the application seeming to freeze for 20 or 30 seconds. And it would only be for those DE that do x11. Gnome and KDE between them probably account for 75% of linux users (not me, I don't like either so don't beat me up about it).

Davo

[zeljko]

It is possible, something like should help at the place of provided patch.
{$IFDEF HASX11}
if not IsWayland and (WindowManager <> 'kwin') then Use_NonNative_Dialog
.....
{$ELSE}
...others are fine.
{$ENDIF}

[dbannon]

I am not sure HASX11 is not set when using XWayland. I found it a bit unpredictable between different desktops. Having X11 and preferring to use it might be a different thing. Sigh ...

Alternative approach might be to look for $WAYLAND_DISPLAY and, if set assume its all good. If not set, then need to look at what DE we are using.

• GetEnvironmentVariable('WAYLAND_DISPLAY')
• if pos('KDE', upcase(GetEnvironmentVariable('XDG_CURRENT_DESKTOP')))

Makes for high maintenance code I am afraid because this changes over time. And will need a fair bit of testing.  Some desktops lie !

I might have a play tomorrow if I get some time.

Davo

[irfanbagus]

how about calling Clipboard.BeginX11SelectionLock before show save dialog? something like this

Code: Pascal  [Select][+][-]

1. diff --git a/lcl/interfaces/qt5/qtobjects.pas b/lcl/interfaces/qt5/qtobjects.pas
2. index c3aafa9049..8b85ebc196 100644
3. --- a/lcl/interfaces/qt5/qtobjects.pas
4. +++ b/lcl/interfaces/qt5/qtobjects.pas
5. @@ -3852,6 +3852,10 @@ begin
6.    {$IFDEF VERBOSE_QT_CLIPBOARD}
7.    writeln('signalDataChanged()');
8.    {$ENDIF}
9. +  {$IFDEF HASX11}
10. +  if InX11SelectionLock then
11. +    Exit;
12. +  {$ENDIF}
13.    FClipChanged := IsClipboardChanged;
14.  end;
15.  
16. diff --git a/lcl/interfaces/qt5/qtwsdialogs.pp b/lcl/interfaces/qt5/qtwsdialogs.pp
17. index c42406142b..55d409e030 100644
18. --- a/lcl/interfaces/qt5/qtwsdialogs.pp
19. +++ b/lcl/interfaces/qt5/qtwsdialogs.pp
20. @@ -501,7 +501,16 @@ begin
21.        QFileDialogDontConfirmOverwrite,
22.        not (ofOverwritePrompt in TSaveDialog(FileDialog).Options));
23.  
24. -    FileDialog.UserChoice := QtDialogCodeToModalResultMap[QDialogDialogCode(QtFileDialog.exec)];
25. +    {$IFDEF HASX11}
26. +    Clipboard.BeginX11SelectionLock;
27. +    try
28. +    {$ENDIF}
29. +      FileDialog.UserChoice := QtDialogCodeToModalResultMap[QDialogDialogCode(QtFileDialog.exec)];
30. +    {$IFDEF HASX11}
31. +    finally
32. +      Clipboard.EndX11SelectionLock;
33. +    end;
34. +    {$ENDIF}
35.      ReturnList := QStringList_create;
36.      try
37.        QtFileDialog.selectedFiles(ReturnList);
38.  
39.  

edit:

maybe not the best way, but for me it's better than waiting 10s+ freeze. tested on xfce with gtk3 save file dialog working.

[dbannon]

OK, so I have tested a number of distros and, importantly, desktops. I observe -

• Using HasX11 (defined in QT defines) is not a useful indicator of the problem, every DE I tested had HasX11 set.
• Of the DEs I tested, we have a problem only with XFCe, Mate and Budgie.
• Gnome, Plasma, enlightenment, Cinnamon, LXDE, LXQT all work OK.

My data -

Code: [Select]

226  Fixes  Hack    Distro/DE
OK   Bad    OK      Ubuntu 20.04 Mate X
OK   Bad    OK      Ubuntu 23.04 XFCe X
OK   OK             Ubuntu 23.04 Gnome X, WD
OK   OK             Debian Bookworm Plasma X, WD
OK   OK             Debian Bookworm Cinnamon X
OK   OK             Debian Bookworm OpenBox X
OK   OK             Debian Bookworm LXDE X
OK   OK             Debian Bookworm LXQt X
OK   Bad    OK      Debian Bullseye Mate X
OK   Bad    OK      Fedora 37 Mate X
OK   OK             Fedora 38 Gnome X, WD
OK   OK             Debian Bookworm enlightenment X (dialog same)
OK   Bad    OK      Debian Bookworm Budgie X
I made test binaries with Lazarus 2.2.6 (no changes) and a hacked Fixes_3_0 that allowed me to enable or disable the hack with an env variable. 'Bad' means the 20 second delay before showing the dialog. 'X' means that the QT5 code sees HasX11 set and 'WD' means the session has WAYLAND_DISPLAY var set to something.

In all cases, with the hack the result is usable but sometimes unnecessary. When its unnecessary but still applied we get the less than perfect default QT dialog.

So, using HasX11 as a trigger for the hack is inappropriate. Using WAYLAND_DISPLAY is a lot better but will still force some less popular DEs to use the default dialogs. Personally, I do not like the idea of coding tests for individual DEs but I suspect that is the only way to get a perfect result. It will leave us with code needing tweaking from time to time I expect (ie when a new desktop comes along).

On the other hand, just using WAYLAND_DISPLAY leaves everyone reasonably happy ....

I cannot attach the compiled binaries but if someone wants to try a test of their own, please let me know and I'll put them up on google drive or whatever ....

David

[zeljko]

HasX11 is define which tells us that we are on linux.There's IsWayland function which clearly separates wayland, or IsX11 function which does the same thing (checks if xcb platform plugin is loaded, so it is x11).
Also, there's property TQtWidgetSet.windowManagerName so it's easy to combine all stuff you mentioned.
eg:
if IsX11 and (WindowManagerName = 'mutter') or (WindowManagerName = 'icewm') ..... and (QtWidgetSet.StyleName = 'gtk') or (StyleName = 'gtk2') or (StyleName = 'gtk3') then EnableX11LockForDialogs ...

I just want to know if your X11SelectionLock patch fixes problem, if it's so, then it's easy to fix it with code example I written above.

[irfanbagus]

I just want to know if your X11SelectionLock patch fixes problem, if it's so, then it's easy to fix it with code example I written above.

it's work in my desktop (XFCE) with GTK3 file dialog. no delays. but signalDataChanged also need patched or copying file name in file dialog make application freeze.

and when one application freeze, other application from different executeable using libQt5pas (even lazarus) also freezing.

[zeljko]

Thanks, in that case we can completely disable selection from gtk dialogs via X11SelectionLock.
Can you write here what's result of QtWidgetSet.StyleName and QtWidgetSet.WindowManagerName for problematic WM's with gtk dialogs delay ?

[dbannon]

and when one application freeze, other application from different executeable using libQt5pas (even lazarus) also freezing.

Yes, while compiling my list of tests, I noted that while the test app was doing its 20 second thing, my own app, tomboy-ng, was also freezing. Both are, of course, using libqt5pas.

> Can you write here what's result of QtWidgetSet.StyleName and QtWidgetSet.WindowManagerName for problematic WM's with gtk dialogs delay ?
Yeah, I have VMs every where at the moment !



Davo

[dbannon]

QtWidgetSet.StyleName   QtWidgetSet.WindowManagerName for the problem VMs I have tested.

Mate Boxes
qt5ct-style metacity (marco)
fusion metacity (marco)

XFCe
gtk2 xfwm4

Budgie
fusion and metacity

EDIT : the Mate box set to qt5ct style has its qt5ct style set to 'windows'  and dialogs to 'default' by the way. Thats 'out of the box' settings.

Davo

[irfanbagus]

In my case

QtWidgetSet.StyleName : kvantum
QtWidgetSet.WindowManagerName : xfwm4

AFAIR file dialog controlled by platformthemes

Code: [Select]

$ ls /usr/lib/qt/plugins/platformthemes/
libqgtk2.so  libqgtk3.so  libqxdgdesktopportal.so
btw, instead of detecting the desktop/window manager being used, why not activate X11SelectionLock using the environment variable.  such as

Code: [Select]

LIBQTPAS_X11_SELECTION_LOCK=1 myApp

[dbannon]

I don't understand how SELECTION_LOCK fits in here. But setting that env var has no effect on my test app.

Looks, more to me, that testing for WM = [ metacity, xfmw4 ] seems reliable in the subset I have been looking at. I tried installing compiz on a Mate box and it showed the problem too but Mate clearly did not like we forcing compiz on it warning it may not have actually been in use (in which case it was still using metacity).

Davo

EDIT : no, sadly, just the window manager is not a perfect indicator of where the problem is. Of all my test VM, only the Cinnamon breaks the rule. It uses metacity but works perfectly with native dialogs.
Working WMs are - wayland, kwin, openbox, enlightenment

[zeljko]

In my case

QtWidgetSet.StyleName : kvantum
QtWidgetSet.WindowManagerName : xfwm4

AFAIR file dialog controlled by platformthemes

Code: [Select]

$ ls /usr/lib/qt/plugins/platformthemes/
libqgtk2.so  libqgtk3.so  libqxdgdesktopportal.so
btw, instead of detecting the desktop/window manager being used, why not activate X11SelectionLock using the environment variable.  such as

Code: [Select]

LIBQTPAS_X11_SELECTION_LOCK=1 myApp

I'll check if we can know platformTheme via c bindings, in that case it will br easy to fix, because gtk2 and gtk3 platformthemes are problematic under x11.

[dbannon]

...
I'll check if we can know platformTheme via c bindings, in that case it will br easy to fix, because gtk2 and gtk3 platformthemes are problematic under x11.

zeljko, I see the problem on systems running fusion and qt5ct's themes, not just gtk2 and gtk3

Davo