Only grab keyboard when line edits have focus in pinentry (qt)
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Thu Jun 30 17:30:57 CEST 2016
On Thu 2016-06-30 03:13:21 -0400, Bernhard Reiter wrote:
> [ Unknown signature status ]
> Am Donnerstag, 30. Juni 2016 07:30:55 schrieb Daniel Kahn Gillmor:
>> fwiw, i've seen both things happen. it's also possible that the focus
>> is in the pinentry, but slips out (e.g. due to mouse wiggle on
>> focus-follows-mouse systems, or accidental "heel-click" of tap-to-click
>> trackpads).
>
> What is the situation happening to you that you refered to as
> | For myself, i often have enough
> | things running concurrently (and can become sufficiently distracted)
> | that global kbd grab probably saves me from making that particular
> | mistake about once or twice a month.
>
> (I've just asked to understand more about how this undesired behaviour
> "happens" to you.)
just what i've said above:
* mouse wiggle on focus-follows-mouse systems -- when you cross a
window boundary, the focus moves to the other window, even though the
keyboard is grabbed and signals can't be sent to the other window
that now has the focus. I recognize that focus-follows-mouse isn't a
popular UI paradigm these days, and that most systems use
click-to-raise-and-focus.
* "heel-click" on tap-to-click trackpads -- this doesn't happen as
often to me because i disable any trackpad i'm capable of disabling
:) but it's a risk for folks who use click-to-raise-and-focus with a
trackpad. by "heel-click" i mean that the heel (lower palm) of your
hand brushes against the trackpad and registers as an accidental
click.
maybe neither of these things ever happen to anyone else?
--dkg
More information about the Gnupg-devel
mailing list