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

[zeljko]

If singnalDataChanged freezes in interaction with gtk3 platform theme open/save dialog then we have a real problem. As I already spotted: QMimeData freezes inside Qt (not freeze but locks itself for 10-20 seconds). You can try to create pure QApplication as fpc program and check it (so no LCL involved).
QMimeData_formats() after 10-15 seconds returns empty list. There's exactly nothing I can do inside Qt lcl. Patches (not workarounds) are welcome.

[zeljko]

One of many: https://bugs.kde.org/show_bug.cgi?id=446581

EDIT: Nice comment is here (the last one) https://bugreports.qt.io/browse/QTBUG-55442

[irfanbagus]

One of many: https://bugs.kde.org/show_bug.cgi?id=446581

EDIT: Nice comment is here (the last one) https://bugreports.qt.io/browse/QTBUG-55442

yes, i read the link yesterday and has same conclusion.

i use timer to block QClipboard_mimeData, but i think that classified as workarounds and i personally don't like it either. if anyone needed i put in attachment.

and thanks for looking the issue.

[zeljko]

singleShotTimer can be called directly from bindings:
QTimer_singleShot(10, @OurCallback);
OurCallback is procedure of object; cdecl;

In Qt6 there's also context param so eg:
QTimer_singleShot(10, Clipboard, @OurCallback);

Idea with timer is possible solution since there's no mechanism in Qt which can fix this problem, even if I change someting in bindings.

[dbannon]

.... Patches (not workarounds) are welcome.

zeljko, I respect your opinion here as much as I respect your work. And thats a lot!

I agree an ugly workaround, such as forcing some DEs to use non-native dialogs would be very undesirable. But we may get to a point where its an ugly workaround or ship, with Lazarus 3.0, unworkable code. Mind if we look at what that would mean to my very minor project ?  Its in Debian, Debian would have to use Lazarus 3.0 to build it and it would make an unusable app. I'd have to withdraw it. I could still make downloadable packages for Windows, Mac and even GTK2 Linux but I don't think I would bother.

Ugly as they are (eg) default dialogs work and would give us (or Qt) time to fix the underlying problem.

Please consider.

David

[zeljko]

Maybe such workaround can be more readable and appropriate. Please test if something is missng, since it's written from my head.

[irfanbagus]

Maybe such workaround can be more readable and appropriate. Please test if something is missng, since it's written from my head.

for reasons that i don't know, X11DelayTimeOut is called but FX11Delay is never set to false, leaving to locked state. and very rare and randomly, glib give error (not single error, always change). however modifying to

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

1. procedure TQtClipboard.X11DelayTimeOut; cdecl;
2. begin
3.   //FX11Delay := False;
4.   qtobjects.Clipboard.FX11Delay:= False;
5. end;  

and it did work. memory issue?

edit :
modify using TQtTimer, please test patch.

[dbannon]

Hmm, that makes no sense to me. Its the same object as near as I can tell but -

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

1. procedure TQtClipboard.X11DelayTimeOut; cdecl;
2. begin
3.   if FClipboard = nil then writeln('Nil before');
4.   writeln('FX11Delay (1) is at ', inttostr(PtrUint(@FX11Delay)));
5.   writeln('FX11Delay (2) is at ', inttostr(ptruint(@(qtobjects.Clipboard.FX11Delay))));
6.   writeln('FX11Delay (3) is at ', inttostr(ptruint(@(FClipboard.FX11Delay))));
7.   ....

 
gives me this -
 

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

1. FX11Delay (1) is at 89
2. FX11Delay (2) is at 140154257797912
3. FX11Delay (3) is at 140154257797912

But, yes, I can confirm  irfanbagus observation.

Davo

[irfanbagus]

@dbannon , i update prev post. please test the patch. work fine in my desktop.

[zeljko]

I did not test my patch, as I already mentioned.

[dbannon]

Yep, the -1 patch seems to work with superficial testing.

But a timer ? Sigh...

And I'd still like to know, in this case, whats the fifference between FX11Delay and FClipboard.FX11Delay.

I will test a lot more given how devious this bug is.

David

[zeljko]

Yep, the -1 patch seems to work with superficial testing.

But a timer ? Sigh...

And I'd still like to know, in this case, whats the fifference between FX11Delay and FClipboard.FX11Delay.

I will test a lot more given how devious this bug is.

David

I've found why my patch crashes. Please declare FX11Delay: boolean; as class var FX11Delay:boolean; inside TQtClipboard so it'll work w/o problems.

[irfanbagus]

Yep, the -1 patch seems to work with superficial testing.

But a timer ? Sigh...

And I'd still like to know, in this case, whats the fifference between FX11Delay and FClipboard.FX11Delay.

I will test a lot more given how devious this bug is.

David

I've found why my patch crashes. Please declare FX11Delay: boolean; as class var FX11Delay:boolean; inside TQtClipboard so it'll work w/o problems.

working correctly

[zeljko]

Commited in https://gitlab.com/freepascal.org/lazarus/lazarus/-/commit/a7451ae90357eb065d0cfd87969e7f142e748e3d, both Qt5 and Qt6, please test so I'll merge it to the fixes_3_0.

[dbannon]

working correctly

Agreed, works for me too.  I'll do a pull and run some more tests, just in case.

Davo