Hi, Allow me to bring back up something that I've maybe never tried to discuss as an individual topic: dialogs that are created using a WId instance that is owned by a different application. Example: the warnings and password dialogs posted by kwalletd, which are supposed to open in a window (or the child of a window) owned by the application that requests a password from a kwallet.
This approach doesn't work on OS X (the existing code in fw 5.17.0 crashes; haven't checked 5.18.0 yet). Ignoring the WId means the dialog is posted in the window layer where the actual application (kwalletd in this case) lives, i.e. it will most likely remain hidden behind any number of windows from any number of other applications. Are there other platforms where WIds cannot be used for this kind of use case (MS Windows for instance)? Regardless, the kwalletd example is a very relevant one because I get the exact same thing on my KDE4 Linux desktop regularly: kmail will require a password to send an email, the dialog remains hidden (and I somehow don't notice the notification), and my email doesn't get sent. A workaround would be to 1) let the background process (kwalletd) force itself to the foreground 2) when the dialog returns, ask the application owning the WId to come to the foreground again 1) is currently possible with the OSX backend I have proposed for KWindowSystem, but I don't suppose that all applications that use WIds in this way (= like kwalletd) depend on KWindowSystem and thus on QWidgets? As to 2) I'm not even sure it is possible reliably. Both activation functions could of course be implemented in Qt, either in QDesktopServices or in the relevant Q*Extras component(s). The alternative would be to implement something that's based on DBus, but I have only a very general idea of what the DBus does. How feasible would it be to implement a feature where a background application like kwalletd tells its client (say kmail) to post a dialog (e.g. a password request) and then retrieves the result over DBus? Or else to implement at least 2) above (sending passwords over the DBus sounds like something that's "not done" nowadays...) Regards, René _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
