search

digitaltrails / vdu_controls

VDU controls - a control panel for monitor brightness/contrast/...
GNU General Public License v3.0
114 stars 3 forks source link

QFileDialog getOpenFileName selector is too slow #61

Closed digitaltrails closed 1 year ago

digitaltrails commented 1 year ago

It takes the standard QFileDialog getOpenFileName 30 seconds to initialise (at least on my desktop). See if that can be improved.

This greatly affects selecting icons and devices.

digitaltrails commented 1 year ago

Seems to be a login specific problem - possibly confined to KDE and possibly to my login (which has a lot of files in the home folder).

Goes away if I reimplement the static method QFileDialog.FileDialog.getOpenFileName() by constructing a QFileDialog() and configure its options to match getOpenFileName(). But then it issues weird messages to stdout and stderr that the original doesn't. Very weird.

digitaltrails commented 1 year ago

This issue is only a problem for some users. Perhaps it's due to the number of files or combination of devices visible for the user's login.

Implementing a custom getOpenFileName() file-chooser dialog using the existing QFileDialog reduces the initialisation time from 30 seconds to 5 seconds. Why this should be remains a mystery. The only clue is that the custom version emits junk messages to stderr/stdout, which means it is behaving differently than the existing static method QFileDialog.FileDialog.getOpenFileName(). Five seconds is good enough, so I'll call it fixed.