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?


  • Lifetime Qt Champion

    Hi,

    What distribution are you using ?
    Does it also happen with the distribution provided Qt ?



  • What distribution are you using ?

    openSUSE Tumbleweed

    Does it also happen with the distribution provided Qt ?

    I am testing the responsiveness of file management dialogues for a while from this software package source.


  • Lifetime Qt Champion

    @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 ?



  • @SGaist said in Checking run time characteristics for QFileDialog::getOpenFileName():

    And what version is it ?

    I am using the Qt versions which were provided together with openSUSE Tumbleweed for years. It is currently 5.11.2-1.1.


  • Lifetime Qt Champion

    What desktop environment are you using ?

    How many and what type of storage system do you have connected to your computer ?


  • Qt Champions 2018

    @elfring just to add to @SGaist, especially check network drives. I especially have a delay in Windows because of that (but only some seconds).



  • @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.


  • Lifetime Qt Champion

    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?)



  • @elfring

    • Don't know what you're saying, but @SGaist is suggesting you try passing the DontUseNativeDialog flag 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::DontUseCustomDirectoryIcons flag, 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 strace to 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?



  • @elfring

    Will any other debugging aproaches or system performance analysis help better?

    Yes, like I said, use strace!



  • 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 the strace output 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.



Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.