From: "Daniel P. Berrangé" <berrange@redhat.com>
To: John Snow <jsnow@redhat.com>
Cc: qemu-devel@nongnu.org, Peter Maydell <peter.maydell@linaro.org>
Subject: Re: [PATCH 1/1] docs/qapi-domain: Improve QAPI indices
Date: Mon, 2 Jun 2025 12:16:21 +0100 [thread overview]
Message-ID: <aD2IBR5FTFCSrV8x@redhat.com> (raw)
In-Reply-To: <20250523180809.41211-2-jsnow@redhat.com>
On Fri, May 23, 2025 at 02:08:09PM -0400, John Snow wrote:
> This patch changes the "by type" categorization in favor of using
> sub-categories of a literal "By type" category instead. A new "By
> module" categorization is also added that follows a similar pattern.
I'm not much of a fan of this. IMHO unless you are looking at the
module(s) for the subsystem you are the maintainer of, the split
of definitions across modules comes across as somewhat arbitrary
and unpredictable.
Looking at this from the POV of a consumer of QMP, our entrypoint
to research is either a command name or an event name.
The data type names of enums/alternates/objects are an internal
QEMU detail that's not part of the public API.
If we consider the index currently:
Alternates | Commands | Enums | Events | Modules | Objects | A | .... | Z
The A ... Z bits link to a mix of all type names, which is a bit
overwhealming.
At the same time the page is twice as big as it needs to be
as the same info is repeated under the A-Z index and the
other per-type indexes.
I think what would help would be to make the index dynamic
eg
A | B | C | D | E | ... | X | Y | Z
[ ] Show internal types
The A-Z index would default to showing commands and events.
Selecting the "Types" checkbox would toggle display of the
alternate/enum/object names, which could be done via having
a CSS class on each index entry, and javascript which just
toggles 'display: none' / 'display: block' CSS property on
the elements with the given class. I'm not convinced we need
the modules in the index.
> Alphabetical sorting has been improved and will sort in a case
> insensitive manner for all categories, now.
This is trivial and nice and could be a standalone fix ?
> Lastly, the "main" QAPI Index (qapi-index.html) is altered to index
> *everything* from all namespaces, adding disambiguation where necessary
> to do so.
This looks a bit wierd having the same types and modules repeated
multiple times.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2025-06-02 11:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-23 18:08 [PATCH 0/1] Sphinx: refactor QAPI indices John Snow
2025-05-23 18:08 ` [PATCH 1/1] docs/qapi-domain: Improve " John Snow
2025-06-02 11:16 ` Daniel P. Berrangé [this message]
2025-06-05 8:46 ` Markus Armbruster
2025-06-05 16:36 ` John Snow
2025-06-13 21:07 ` John Snow
2025-07-24 7:29 ` Markus Armbruster
2025-07-24 9:35 ` Markus Armbruster
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=aD2IBR5FTFCSrV8x@redhat.com \
--to=berrange@redhat.com \
--cc=jsnow@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).