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