This will help make the init procedure safer, by limiting the number of Rust objects that need to be carried to the C side and may be mangled on the way there.
The second benefit is that it allows outputs to become part of new state management.
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.
Use a GOptionContext to display command line options (that are already
handled by e.g. gtk_init anyway).
This turns:
$ squeekboard -h
Debug: Tried file "/home/agx/.local/share/squeekboard/keyboards/us.yaml", but it's missing: No such file or directory (os error 2)
Info: Loaded layout Resource: us
Debug: Tried file "/home/agx/.local/share/squeekboard/keyboards/us.yaml", but it's missing: No such file or directory (os error 2)
Info: Loaded layout Resource: us
** (squeekboard:8015): WARNING **: 19:03:13.125: DBus unavailable, unclear how to continue. Is Squeekboard already running?
into the more useful
$ squeekboard -h
Usage:
squeekboard [OPTION…] - A on screen keyboard
Help Options:
-h, --help Show help options
--help-all Show all help options
--help-gtk Show GTK+ Options
Application Options:
--display=DISPLAY X display to use
...
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.
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
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).
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.
This ensures that the layout type information is accessible to the state manager when new layout information arrive.
The should be thought of as a stopgap measure. A proper solution would be to separate the state properly, and probably turn layout information coming from random places into messages that some object (thread?) collects and displays.
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.
This allows us to remove a lot of #ifdef's. Either we want to use
a config.h or we don't. Since we'll want it for e.g. optional gsound
support later on let's have it.
