Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add virtual key handling to InputContext and WaylandIMInputContextV1 #454

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

daipom
Copy link
Contributor

@daipom daipom commented Feb 28, 2022

For a virtual keyboard, we need an interface to convey virtual key inputs to InputContext.

When we were beginning to implement the virtual keyboard, we tried to manage virtual key inputs
using keyEvent and forwardKey and commitString and so on...
It was tough to handle them properly on the virtual keyboard side.

It would be nice if we could pass virtual keys to the same logic as physical keys.

In WaylandIMInputContextV1, key inputs are processed in the keyCallback method,
but there is no way to pass virtual key inputs to it.

This fix adds new methods virtualKeyEvent and virtualKeyEventImpl to InputContext.

By default, it works the same as the existing keyEvent method,
but virtualKeyEventImpl can be overridden to handle virtual key events.

In this fix, core key logic can be shared between physical and virtual key events.

The current InputContext has the `keyEvent` method, but what it can do
is limited.
In WaylandIMInputContextV1, key inputs are processed in the `keyCallback`
method, but there is no way to pass virtual key inputs to it.

This fix adds new methods `virtualKeyEvent` and `virtualKeyEventImpl`
to InputContext.
By default, it works the same as the existing `keyEvent` method.
But `virtualKeyEventImpl` can be overridden by each implementation
to define the same behavior as physical keys.
@wengxt
Copy link
Member

wengxt commented Mar 9, 2022

Hi, sorry for not replying this for a while. The key point for me is that, before we move forward we need to have a better design on how it should looks like.

For example, "KeyEvent" is solely designed for hardware keyboard. The property on it is not really suitable for virtual key.

While the change looks ok on its own, I don't think it fit the big picture, especially virtual key may do things that hardware key can't.

I'd suggest we find some time and meet together (maybe also with people that's currently working on fcitx5-android). What do you think?

Feel free to leave a message on irc or telegram in fcitx channel

Telegram: https://fcitx-im.org/telegram/captcha.html
IRC: #fcitx [at] libera.chat

@daipom
Copy link
Contributor Author

daipom commented Mar 11, 2022

Thank you for the response!

I would appreciate it if there is a proper input method for the virtual keys,
but I too think it doesn't have to be this implementation.

We need to figure out in which direction Fcitx5 plans to support virtual key operations in the big picture.

I'd suggest we find some time and meet together (maybe also with people that's currently working on fcitx5-android). What do you think?
Feel free to leave a message on irc or telegram in fcitx channel

Thank you!
I don't have much time at the moment so action may be slow,
but I hope to contribute to the virtual keyboard feature of Fcitx5.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants