https://bugs.kde.org/show_bug.cgi?id=404833
--- Comment #9 from RJVB <rjvber...@gmail.com> --- I'm a bit confused. IIUYC, the client/application side sees a QFileDialog instance that is not the one that is actually being shown, while the dialog that does appear on the screen is the one created/inherited by KDEPlatformFileDialog? In fact, what would you want to do with the "actual window"? >From looking at the integration code it looks like you'd need that information when you create the KDEPlatformFileDialog instance, to use instead of the new QDialog. The application side could use findChildren() to dig up the KFileWidget instance and when one is found, use QObject::setProperty() to communicate the actual QFileDialog, but then what? What *can* you do if the QFileDialog instance seen by the application is not the window that's shown? OTOH, if the actual QDialog being shown is the one created by KDEPlatformFileDialog, can the application get at that instance? If so it could use a QFileDialog proxy that transfers all QFileDialog specific calls to the KDEPlatformFileDialog instance, and use that proxy instead of inheriting QFileDialog directly? This does suppose that KDEPlatformFileDialog provides a complete enough QFileDialog API... -- You are receiving this mail because: You are watching all bug changes.
