It's all in the title - every time I need to enter a password to unlock a kwallet, I have to go grab the dialog from somewhere behind the window requesting the encrypted information. This is annoying but becomes problematic when the unlock request does not stem from an immediate user action, but from a process running in the background. Reproducible: Always Steps to Reproduce: 1. Do anything that requires access to a wallet that's currently locked (which might just be having akonadi services run) 2. Wait until the wallet system posts a password dialog Actual Results: The password dialog opens somewhere behind the current window, on the middle of the screen (so typically completely hidden by other open windows). KDE's notification system does post a message, but it only allows to ignore the request or switch back to the calling application ... which still has the input focus. Expected Results: The password dialog opens in front, having obtained input focus See https://forum.kde.org/viewtopic.php?f=60&t=121478&sid=050a9636469e60976277154d8fc2095f&p=312556#p312536 for a discussion and proposed solutions, including one (a QtKeyChain based backend) that would provide integration with the OS X password management system (Keychain). Additionally, on OS X there are always 2 wallet icons visible in the Dock and the app switcher (1 for kwalletd, one for the manager). This doesn't make it easier to switch to the instance that has the dialog open!
The KWallet daemon is a separate process. I am not sure if/how OS X allows windows from alien processes steal the focus of the currently running application.
It certainly doesn't make it impossible to do that. In fact, it allows it with too much ease to my taste (there used to be a time when you could launch an app, switch to another and keep working therein while the other app prepped itself in its own "layer"; no longer so). Hooking into QtKeyChain will of course make the question a moot point, because it'd be the OS handling the focus control.
Created attachment 87514 [details] example ObjC file that shows how to launch an application in the foreground Kwallet isn't the only application opening elsewhere but in the foreground; in fact, it is the OS default when an application is started through system() or execve() or even NSTask. I thus had a look around and found a solution on StackExchange for launching an(y) application with arguments and have it appear in the foreground. Contrary to the standard [NSWorkSpace launchApplication: arguments:] function, this one accepts all kinds of arguments, not only documents to be opened.
The problem isn't with launching new applications, because the kwallet daemon is already launched. But when it needs to open a window, it will have to open it in a way to force stealing the focus of the currently running application.
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
It is, cannot be otherwise given how the password dialog is brought to the foreground under X11. That cannot work on Mac (nor under Wayland IIUC). The only solution I found is make kwalletd force itself to the foreground (together with changes that make it do this without becoming a full GUI application with a menubar and presence in the Dock and app-switcher. I could put this changeset up for review, but only if the overall consensus is that kwalletd has a right of existence on Mac. The alternative would be to use a Mac-native mechanism to unlock KDE wallets, but I don't see how that would work.
*** This bug has been marked as a duplicate of bug 141267 ***