This actually removes the size request from panel creation. Incidentally, this still works becuae the following configure event gets the sizes from glib.
This ensures that the new state machine is fed events, as well as that its results are applied.
The old ad-hoc system is removed.
There is one regression where the last layout will be used when the panel is brought up manually.
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.
With the policy being disentangled from application, it becomes testable.
This prepares for moving the entire visibility mechanism to the new class and taking away more pieces of ServerContextService.
In addition, this is a good warmup before trying to implement sizing policy.
The `eek/layersurface.c` file should be excluded because it's an imported, "foreign" source, but clang-tidy doesn't seem to have an annotation for that.
An alternative would have been to exclude it in Meson and do the check there, but that requires clang-tidy, raising the barrier to contribute of Squeekboard even more (it already requires libfeedback, which isn't packaged widely).
Even though proper size management is being worked on, this patch
proposes a simple and easily revertable solution to device-dependent
sizing issues.
First, it provides different calculations based on the display
orientation. In landscape mode, this allows us to have a sensible
keyboard size while leaving enough screen estate for apps to be able to
display useful information.
Then, it gets rid of the weird calculation for display widths between
360 and 540px. While having some continuity is a pleasant idea, in the
real world in doesn't work, as shown by port attempts to other devices:
a 480x800 display (scale 1) would show an unusable 190px-high keyboard
(about half the size of the Librem 5 on-screen keyboard on a device I
own).
Finally, this commit makes sure we never use a hardcoded size.
Tested on the PinePhone, PineTab and Librem 5.
Note: Current behavior is preserved on the L5 in portrait mode, but
keyboard is a bit smaller in landscape mode; this is deliberate, as it
was previously using too much space (causing some apps, such as chatty,
to be unusable).
If the corresponding a11y settings is disbaled don't unfold
the keyboad at all.
This helps e.g. running the same session on laptops or when
an external keyboard is attached.
Closes: #222
This makes sure 'self' comes first. While at that fix the
function signatures and use ServerContextService directly
and add type checks so it's easy to notice when we messed up.
Phoc sends output information *after* changing keyboard surface size. Squeekboard adjusts size on surface events, but not on output in this revision, making it unaware of display size at the time of adjustment, resulting in bad adjustment.
This change hardcodes the proportions again to make it work at least on the Librem5.
The manager is used for sizing the layer surface. It promises never to exceed half the output height.
The selection of the current layout is not being done here, leading to worse behaviour in 1:1 scaling.
In the future, it could be used for sizing the keyboard itself and the suggestion box, as well as decide which layout to use, because layouts should have some sizing hints.
Layout management was pointlessly bound with the EekboardContextService with inheritance. Splitting it out will make it easier to further break apart layout state management, settings, and input method in the future.
instead keep it around for 200ms. This reduces flicker a lot since
the keyboard will not hide when switching through input fields in
e.g. contacts or chatty.