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