Hi everybody,
Am 25.04.2016 um 17:00 schrieb Neil Jerram:
On 25/04/16 06:55, rhn wrote:
Hi,
On Mon, 25 Apr 2016 13:19:58 +0200
"H. Nikolaus Schaller" <[email protected]> wrote:
Hi Xavi,
Am 25.04.2016 um 13:09 schrieb Xavi Drudis Ferran <[email protected]>:
El Mon, Apr 25, 2016 at 11:54:19AM +0200, H. Nikolaus Schaller deia:
But I have no idea if the on-screen keyboard can be rewritten in a
way that it works with all other GUI applications (not necessarily
Qt based!). You would get a problem if you have network-manager
and can't type IP addresses... So this might be a big challenge
(who doesn't love challenges?).
I don't really know. But I took a look at the qtmoko keyboard a year
or two ago (I hardly remember any detail) and got the impression that
not as it is. But then I don't know anything that could do that. In X
it is easier, I think. But without X what is the abstraction for a
keyboard this application should plug into ?
Why "without X"? At least until we can run Wayland on the GTA04, I
think that X should be our common denominator.
It appears to me that QtMoko was using the inputmethod functionality
provided by QT and just implemented the onscreen keyboard on top. Check
the code for it below:
https://github.com/radekp/qtmoko/tree/master/src/plugins/inputmethods/fingerkeyboard
So the current abstraction is InputMethod. And that should be operative
no matter which window-system QT was built for.
Good question.
Should there have to be a
keyboard driver in the kernel or something? Should it pass as a tty ?
That would be an interesting approach. Or we use a pty (or mkfifo) and
symlinks to present a virtual /dev/event node where the keyboard
process
can write to...
But I am not sure if X11 will find it because it likely scans /sys
for input
devices and not /dev.
I played with the input subsystem several times in the past and I can
confirm that it's possible to create such a virtual device and get it
picked up by X.
This is what xboxdrv [0] does, for example, and it can be done using
uinput [1] in an easy way. Python bindings [2] are good for
experimentation.
It is also possible to plug into one of the input method frameworks
(xim, scim, maliit etc.) or to use XTest to inject key events into the
target application.
I personally agree here. Better use one of the existing solutions to
this problem than trying to reinvent it.
However I think the priority should be on things that already work right
now.
Regards,
Neil
_______________________________________________
Community mailing list
[email protected]
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.openphoenux.org
_______________________________________________
Community mailing list
[email protected]
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.openphoenux.org
