From: Markus Armbruster <armbru@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: qemu-devel@nongnu.org, Gerd Hoffmann <kraxel@redhat.com>,
Eric Blake <eblake@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
libvir-list@redhat.com
Subject: Re: [PATCH 2/3] ui: Switch "-display sdl" to use the QAPI parser
Date: Tue, 17 May 2022 11:08:15 +0200 [thread overview]
Message-ID: <87ilq4sf0g.fsf@pond.sub.org> (raw)
In-Reply-To: <870d24be-6c37-ff3d-616b-68255345ebb9@redhat.com> (Thomas Huth's message of "Tue, 17 May 2022 10:34:23 +0200")
Thomas Huth <thuth@redhat.com> writes:
> On 12/05/2022 14.16, Markus Armbruster wrote:
[...]
>>> This introduces the new "DisplaySDL" QAPI struct that is used to hold
>>> the parameters that are unique to the SDL display. The only specific
>>> parameter is currently "grab-mod" which is modeled as a string, so that
>>> it could be extended for other arbitrary modifiers later more easily.
>>
>> Are the values of @grab-mod parsed in any way, or do we recognize a set
>> of fixed strings?
>>
>> The former would be problematic. We try hard to represent complex data
>> as JSON instead of inventing little ad hoc languages.
>>
>> If it's the latter, use an enum. Makes introspection more useful, and
>> adding enumeration values is no harder than adding string literals.
>
> It's currently only two strings that are used to replace the old behavior.
> But in the long run, I think it would be nice to have more flexibility here,
> so that a user could specify an arbitrary combination of modifier keys. I
> don't think that an enum will really scale here, so I'd prefer to go with
> the current approach and use the string for more flexibility.
"Arbitrary combination of modifier keys" sounds like set of enum to me.
We approximate sets with lists in QAPI.
next prev parent reply other threads:[~2022-05-17 9:12 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-11 17:51 [PATCH 0/3] ui: Remove deprecated sdl parameters and switch to QAPI parser Thomas Huth
2022-05-11 17:51 ` [PATCH 1/3] ui: Remove deprecated parameters of the "-display sdl" option Thomas Huth
2022-05-12 8:16 ` Daniel P. Berrangé
2022-05-11 17:51 ` [PATCH 2/3] ui: Switch "-display sdl" to use the QAPI parser Thomas Huth
2022-05-12 8:20 ` Daniel P. Berrangé
2022-05-12 12:16 ` Markus Armbruster
2022-05-17 8:34 ` Thomas Huth
2022-05-17 9:08 ` Markus Armbruster [this message]
2022-05-17 9:49 ` Paolo Bonzini
2022-05-17 11:19 ` Markus Armbruster
2022-05-17 13:18 ` Thomas Huth
2022-05-11 17:51 ` [PATCH 3/3] ui: Remove deprecated options "-sdl" and "-curses" Thomas Huth
2022-05-12 8:21 ` Daniel P. Berrangé
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ilq4sf0g.fsf@pond.sub.org \
--to=armbru@redhat.com \
--cc=eblake@redhat.com \
--cc=kraxel@redhat.com \
--cc=libvir-list@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.