Re: [PATCH v2 17/31] qapi/qom: Add ObjectOptions for input-*
Am 26.02.2021 um 21:55 hat Eric Blake geschrieben:
On 2/24/21 7:52 AM, Kevin Wolf wrote:
> This adds a QAPI schema for the properties of the input-* objects.
>
> ui.json cannot be included in qom.json because the storage daemon can't
> use it, so move GrabToggleKeys to common.json.
>
> Signed-off-by: Kevin Wolf <kwolf(a)redhat.com>
> ---
> qapi/common.json | 12 ++++++++++
> qapi/qom.json | 58 ++++++++++++++++++++++++++++++++++++++++++++++++
> qapi/ui.json | 13 +----------
> 3 files changed, 71 insertions(+), 12 deletions(-)
>
> +##
> +# @InputBarrierProperties:
> +#
> +# Properties for input-barrier objects.
> +#
> +# @name: the screen name as declared in the screens section of barrier.conf
> +#
> +# @server: hostname of the Barrier server (default: "localhost")
> +#
> +# @port: TCP port of the Barrier server (default: "24800")
I can understand this being a string (if non-numeric, it can be treated
as a well-known service name instead), but...
> +#
> +# @x-origin: x coordinate of the leftmost pixel on the guest screen
> +# (default: "0")
...why are these other fields a string instead of an integer? But you
are just doing faithful translation of what we already have.
I wondered the same. Most properties of the user creatable objects make
sense, but for some, I can't imagine why we thought this was a good
idea.
Well, moving descriptions to the QAPI schema can hopefully help to avoid
introducing new cases in the future because they become more obvious.
Bummer - our naming for this member implies that it is experimental,
which is a misnomer (it is quite stable, when viewed in tandem with
y-origin). Not your fault. Would 'origin-x' and 'origin-y' be any
better as new aliases in a followup patch?
Oh, good point. Makes sense, once the alias series is in.
Kevin