Once you start the virtual keyboard from Sato, there is no way to get rid of it. Ross Burton suggested that it should disappear automatically when a text field is de-selected, or that a keyboard icon should appear on the panel that you can use to toggle it, but that is not the case. I've found this is broken in both denzil 1.2.2 and bernard 1.1.1, haven't tested other releases. I discovered this bug during a demo of Yocto at a conference, and it caused some awkwardness in the demo.
I swore there was a panel icon to hide it. I wonder where that went.
We need to add matchbox-keyboard-applet to the packageset, and use it if we've got no keyboard configured in the formfactor. People who start the virtual keyboard on a machine which claims to have a keyboard will have to suffer, sorry.
Various pieces of this have been sent to oe-core.
Remaining piece is to make the keyboard single instance
Reassigning to Jussi as this is Content. Feel free to re-assign in your team.
Verified that we can toggle the keyboard using the matchbox-keyboard-applet (keyboard panel icon). The "/etc/X11/Xsession.d/80matchboxkeyboard.sh" will start matchbox-keyboard as daemon, if "HAVE_KEYBOARD=0" set in /etc/formfactor/machconfig. keyboard single instance patch was also accepted in oe-core: 4efbda84392e00829b9619ba4d8c49bdc5128606 Based on these, we can close this bug.
Verified per above comment.
Created attachment 2920 [details] Keyboard application is never closed or hidden after launch it
Keyboard application is never closed or hidden after launched it. If you click on Keyboard icon from applications on Sato, the keyboard will never be closed or hidden, also if after this you click on the (right, corner top) keyboard icon two keyboards will be displayed. Attached you can find a picture. Refer to comment 8.
Created attachment 2921 [details] keyboard screenshot Actually it seems you can open any number of keyboards. I have not found any way of closing them.
(In reply to comment #10) > Created attachment 2921 [details] > keyboard screenshot > Actually it seems you can open any number of keyboards. > I have not found any way of closing them. Reopened [YOCTO 509]. https://bugzilla.yoctoproject.org/show_bug.cgi?id=509 I have been using "matchbox-keyboard-applet" to start/stop the keyboard (which works as expected). Automatic start/stop of the keyboard is handled in [YOCTO #6774] Quoting Ross (comment #2) " People who start the virtual keyboard on a machine which claims to have a keyboard will have to suffer, sorry. "
Some notes, please correct me if I get something wrong: * I cannot reproduce comment 10 (more than 2 keyboards) using the desktop launcher and the panel applet. Any advice? * desktop launcher has its own implementation of "Single instance" (uses custom X atoms). Other launchers (like running from terminal) will not respect this, and launcher does not count the "daemon" keyboard that may already be running. * panel applet toggles visibility of a matchbox-keyboard (also using X atom), but this only works if the keyboard is started with -d (daemon) So AFAICT this double keyboard thing is not a regression: it's always been broken and cannot really be fixed with current design. I can see two possible solutions: 1. Add a close button to non-daemon keyboards: This does not fix the problem but at least the keyboards could be closed in that case 2. Make matchbox-keyboard properly single-instance. This could be done with GLibs GApplication (where the app itself handles uniqueness using D-Bus and provides a command line interface for things like "--show,--hide,--toggle-visibility"). This would not be a big job, except matchbox-keyboard implements it's own main loop... I guess we could run GLib main loop in another thread just for GApplication?
(In reply to comment #12) > Some notes, please correct me if I get something wrong: > > * I cannot reproduce comment 10 (more than 2 keyboards) using the desktop > launcher and the panel applet. Any advice? We still can show 2 or more keyboards in sato desktop by continuously clicking on the keyboard icon (it takes a while, however, works everytime) > * desktop launcher has its own implementation of "Single instance" (uses > custom X atoms). Other launchers (like running from terminal) will not > respect this, and launcher does not count the "daemon" keyboard that may > already be running. > * panel applet toggles visibility of a matchbox-keyboard (also using X > atom), but this only works if the keyboard is started with -d (daemon) > > So AFAICT this double keyboard thing is not a regression: it's always been > broken and cannot really be fixed with current design. +1 > I can see two possible solutions: > 1. Add a close button to non-daemon keyboards: This does not fix the > problem but at least the keyboards could be closed in that case > 2. Make matchbox-keyboard properly single-instance. This could be done > with GLibs GApplication (where the app itself handles uniqueness using D-Bus > and provides a command line interface for things like > "--show,--hide,--toggle-visibility"). This would not be a big job, except > matchbox-keyboard implements it's own main loop... I guess we could run GLib > main loop in another thread just for GApplication? I think, Solution number 2 ( single-instance) could be the best solution.
I had a try at this, and using GApplication indeed works. However, since the code is based on a loop that blocks in XNextEvent(), it's not going to be easy to integrate properly... The real fix is to modify the main loop to use GMainLoop and use GSource polling on the X display file descriptor to avoid XNextEvent(). It's not horribly complex but it's also not something I'm really comfortable doing at this stage of release. So for 2.1 release, option #1 (close button) might still be valid: I'll have a look.
Adding option #3: Don't show keyboard application in the desktop. * This would not inconvenience people without a keyboard (since the panel applet works) * if someone really wants to run matchbox-keyboard when they do have a physical keyboard, then can either modify /etc/formfactor/machconfig or start matchbox-keyboard from the terminal I think I prefer this option. The keyboard is not a normal app, I don't see a need to start it as one.
Fixed in oe-core 9bc3a29ef14d12f439dece287454af8966d47062.
Verified on master: f7b520878babbaa7527151f22c031ae160512753" Button to start keyboard is gone. Keyboard can be started from terminal, as many times you want; after it is started 4th times it will occupy the screen and had to be closed from a remote session. So there is an workaround.