Re: [PATCH v2 17/31] qapi/qom: Add ObjectOptions for input-*

[Kevin Wolf <kwolf@redhat.com>]

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