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@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