It seems that is Squeekboard is already running, the next instance will not fail to acquire a bus name, but instead lose it immediately. This message has been reported by users who experiment with Squeekboard for the first time, so let's make it easier for them to find the solution without having to reach out.
This is the Bulgarian (BDS) layout. I took the liberty to remove "э"
from the layout, as it is not part of the Bulgarian alphabet and it was
left there for historical reasons, also not to mess with the layouts for
physical keyboards. Removing it gives more space for the shift_l and
backspace keys.
I've also added the letter "small i with grave" to the special symbols, as
it is occasionally used in Bulgarian.
Layout type switching outside of overlay was always done with gsettings in the middle, assuming that all clicks on languages in the popover result in a gsettings event. That's a bad assumption if there's only one xkb lang present.
This is a simple work around. A better solution would be to turn the entire system of layout switching into a central object that receives messages about changes that need to be applied, and then applies them.
From now on, all the parameters for loading layout are handled inside a single pure function, which makes them possible to test.
As a side benefit, the old preference order function composed of a mess of nested procedures is gone.
There are some hacks here in the form of an extra field "appears_locked_from", which can be used to hint that the user should see the button as locked. Without it, there's some confusion on user side regarding buttons that change states unprompted.
This commit adds translations in Hebrew for most layouts.
Note: the hebrew file seems to be named incorrectly,
is that intentional? (he_IL.txt instead of he-IL.txt)
Signed-off-by: Kozova1 <mug66kk@gmail.com>
So far squeeboard only did half of the registration failing
to respond to the signals sent by the session.
This causes problems e.g. when exiting the session since the it
thinks the client hangs or is busy.
Closes: #274
The viibility manager state is changed from various handlers, which are not guaranteed to be reentrant, most notably the Wayland handler for preedit done.
As the state is changed, relevant requests to synchronize user-visible UI are fired from the same handler.
In case of imservice_handle_done, GTK widget show function was being called, which triggered another round of handling Wayland, leading to the done handler being called again, and flaking out.
To solve this, the phase of issuing commands needs to be separate from adjusting desired state. It seems that the easiest solution is to delay the show() and hide() calls into the next GTK main loop spin.
A better solution would probably inject itself directly after the change of desired state, so that *all* the side effects are delayed.
