Virtual keyboard on Nitpicker

Johannes Kliemann Johannes.Kliemann at ...250...
Tue May 23 17:28:54 CEST 2017

Hi Norman,

thanks for your answer!

> I guess that you are already using the input filter to feed the virtual
> keyboard's events back to nitpicker?

We have not yet implemented the input service as we're yet thinking
about the overall architecture but that would have been our approach.

> Nitpicker's focus policy can be configured depending on the client's
> label. Usually, the "click" policy is in effect, which means that a
> click event implicitly changes the focus to the clicked-on client.
> However, this policy is not always desired, like in your case or when
> implementing a global menu. In the latter case, one wants to let the
> menu handle a click yet retain the original focus. To accommodate such
> scenarios, nitpicker supports the so-called "transient" focus policy
> (documentation at [1]). If such a client is clicked-on, it receives the
> press event and all subsequent events until all buttons/keys are released.
> [1]
> I think that the transient focus policy is the right tool for your use
> case if your virtual keyboards delivers its artificial events after the
> release event (otherwise, nitpicker would send the artificial event to
> the virtual keyboard which still has the transient focus).
> For a practical example for configuring the transient focus feature,
> please have a look at the gems/run/ script.
> I'd be very interested in how this approach works for you. We previously
> discussed on the list [2] that nitpicker's focus handling is still
> somewhat limited. So your experience may give me valuable input for
> possibly refining it.
> [2]

Thanks for these sources. The transient policy sounds right for what we
want to do. Sending input events after release might be necessary
anyways if we want to handle longer presses.
I will give feedback when we are in progress with the implementation.


More information about the users mailing list