I just got a bit annoyed by pinentry appearing in the background sometimes. I found ot this depended on current environment; and by checking environment variables one after the other I found DESKTOP_STARTUP_ID as the culprit. When DESKTOP_STARTUP_ID is set, then pinentry-gtk-2 from app-crypt/pinentry-0.7.2-r4 will start in the background, and anything you type will still go to the currently selected application unless you switch window focus to pinentry. The exact value of the variable seems unimportant, as long as it matches the regular expression _TIME[0-9]. It might be that my terminal, x11-terms/rxvt-unicode-8.2, should remove this variable from the environment before passing it to the shell. I must say I don't fully understand what's going on here, but I believe that this is at least one bug. Candidates are pinentry, rxvt-unicode and KDE. Steps to reproduce: 1. Start KDE session 2. Start urxvt 3. pinentry << $'GETPIN\nBYE' Expected result: Pinentry dialog started in the foreground, grabbing the keyboard. Actual result: Pinentry started in the background, blinking, without grabbing keyboard.
Another possible solution might be to unset that environment variable in shell startup scripts like /etc/bash/bashrc.
I found a reference and set it as the URL for this bug here: http://standards.freedesktop.org/startup-notification-spec/startup-notification-latest.txt There it reads "It is suggested to unset this environment variable in the launchee as soon as it's read, to avoid possible reuse by some process started later by launchee."
Had a chat with the urxvt dev. He claims the startup notification specification is flawed, and will not implement it until it gets corrected. As a result, I created an upstream bug for the specification: https://bugs.freedesktop.org/show_bug.cgi?id=11375 While I assume a clean solution upstream will take considerable time, I'd like to see Gentoo implement some more pragmatic solution that works in most cases. I guess I'm in favour of my own comment #1, even though this would not benefit non-terminal applications that start other applications interactively. I can only hope that most of those do use some library that already takes care of unsetting DESKTOP_STARTUP_ID.
There is also a related KDE bug at http://bugs.kde.org/show_bug.cgi?id=108618 which has been resolved WONTFIX on the kde level. They suggest to - not use such terminal apps (not a viable option imho) - ask their developers to fix it (would mean a patch to urxvt) - unset the env.var. in some startup script (like comment #1)
So, it seems to me this is a bug in KDE, not in pinentry?
(In reply to comment #5) > So, it seems to me this is a bug in KDE, not in pinentry? Yes, KDE or rxvt-unicode, or it might even be the GTK-libs used by pinentry, but not a bug in pinentry itself. I hadn't understood the issue enough at the time I posted the bug report. Changing the summary to reflect my current knowledge.
(In reply to comment #0) > Steps to reproduce: > 1. Start KDE session > 2. Start urxvt > 3. pinentry << $'GETPIN\nBYE' > > Actual result: > Pinentry started in the background, blinking, without grabbing keyboard. Can't reproduce this any longer with KDE 4. Guess someone fixed something. $DESKTOP_STARTUP_ID is still set. Will close this as OBSOLETE. By the way, step 3 above should use <<< not <<.
