Checking run time characteristics for QFileDialog::getOpenFileName()
-
I am trying to adjust a specific graphical software application for a while on a recent Linux system. It contains also a call of the function “QFileDialog::getOpenFileName”. I have observed that it can take minutes before I can select the desired file by this standard dialogue from the class library “Qt 5.11.2”. The display was questionable in the meantime.
How are the chances to improve this software situation? -
Hi,
What distribution are you using ?
Does it also happen with the distribution provided Qt ? -
@elfring said in Checking run time characteristics for QFileDialog::getOpenFileName():
I am testing the responsiveness of file management dialogues for a while from this software package source.
Hence my question: do you have the same delay if you use Tumbleweed's provided Qt ? And what version is it ?
-
-
What desktop environment are you using ?
How many and what type of storage system do you have connected to your computer ?
-
@SGaist said in Checking run time characteristics for QFileDialog::getOpenFileName():
What desktop environment are you using ?
I am using XFCE 4.12.1 primarily at the moment while I have got access also to programs from other environments.
How many and what type of storage system do you have connected to your computer ?
I refer to directories from a local hard disk for this clarification request.
-
The fact that you are opening the dialog on your local hard drive, doesn't mean that there's no access to the other devices that you may have.
By the way, do you have the same problem if your disable the native dialog ?
-
The fact that you are opening the dialog on your local hard drive, doesn't mean that there's no access to the other devices that you may have.
- I would be also curious then which of other possible device connections will influence the primary file selection in undesirable ways.
- Which data processing actions can disturb the dialogue display considerably?
By the way, do you have the same problem if your disable the native dialog ?
Can be determined if a native file dialogue is used by the function “QFileDialog::getOpenFileName” at all (if the passing of the configuration option “QFileDialog::DontUseNativeDialog” was omitted so far)?
(Do I need to add debug output to any source code place?) -
-
Don't know what you're saying, but @SGaist is suggesting you try passing the
DontUseNativeDialogflag and see whether Qt's own inbuilt dialog behaves better for you in this situation. -
While you're at it. The most likely cause for any big time delay would be the dialog doing any work examining network or detachable-media drives. Note that Qt has a
QFileDialog::DontUseCustomDirectoryIconsflag, which you should also try using:
Some platforms allow the user to set a different icon. Custom icon lookup cause a big performance impact over network or removable drives.
-
And on that note what do you pass as the "initial/root directory" to your
getOpenFileName()? Try not to pass the very "root" directory of the file system, where network/removable drives stem from, if you don't need to. Pass a directory lower down on a fixed, local drive if you can. -
Finally, if you still have big delays and don't know why, use Linux
straceto discover what the code is actually doing behind the scenes to cause this!
-
-
Finally, if you still have big delays and don't know why,
I am wondering about occasional hiccups in the responsiveness of file management dialogues.
use Linux strace to discover what the code is actually doing behind the scenes to cause this!
I have got the impression that it can matter also which program tries to open a fresh dialogue for another file (or directory) selection. If there is an unpleasant software initialisation process involved, I imagine that it can become very challenging to find the concrete error reason in a reasonable time frame.
Will any other debugging aproaches or system performance analysis help better? -
Yes, like I said, use strace!
I have accidentally noticed the unpleasant software behaviour once more.
The program trace displays so many information so that it seems to be hard to connect another unexpected big delay in the file directory display with a specific function call within the affected software implementation.
-
@elfring
Well I can't see your output so I don't know. But I would have expected that provided you are looking at thestraceoutput in real time what you would see is the last line of output would "hang" just as you went into a "delay", and that would be your indication as to why.... -
you are looking at the strace output in real time
Not really. - I would start such program tracing only after a personal delay to notice that data processing for the function “QFileDialog::getOpenFileName” might take longer than what I would usually expect.
(I might be more patient under other circumstances.)what you would see is the last line of output would "hang"
This did not happen. The dialogue software might be still busy with other stuff.
Additional activities might distract then from temporary technical difficulties.just as you went into a "delay", and that would be your indication as to why....
I found questionable software behaviour also for other components in the suggested way so that corresponding clarification requests and bug reports were published.
