All of
 help / color / mirror / Atom feed
From: John Snow <>
To: "Niteesh G. S." <>,
	Stefan Hajnoczi <>
Subject: Re: GSoC Intro - TUI interface for QMP
Date: Tue, 1 Jun 2021 19:47:08 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 5/26/21 11:35 AM, Niteesh G. S. wrote:
> Hello Stefan,
> On Mon, May 24, 2021 at 7:02 PM Stefan Hajnoczi < 
> <>> wrote:
>     On Sat, May 22, 2021 at 12:32:00AM +0530, Niteesh G. S. wrote:
>      > By end of this summer, I would like to get a basic TUI with some
>     desirable
>      > features working. Some of the features I would like to get
>     working are
>      > 1) Syntax checking
>      > 2) Syntax highlighting
>      > 3) Code completion
>      > 4) Logging
>      >
>      > I would like to hear some of the features you would like to have
>     and also
>      > your
>      > advice's on implementation.
>     Welcome Niteesh!
>     It would be great to have an QMP API documentation viewer built into the
>     TUI. When you enter a command like 'migrate' it would automatically
>     display the associated QMP command documentation from qapi/*.json.
> That's a great idea.
> Do you want the documentation as a popup or in a separate tab?
> By separate tab what I mean is a full window dedicated to documentation
> with some kind of search functionality.
> Thanks,
> Niteesh.

If we're talking about an urwid interface ...

There are a few ways to do this.

1. Explicitly, if you type something like "/help [command-name]" in the 
command bar, you could create a panel that temporarily replaces the 
history panel that shows the arguments and usage of the requested 
command name.

You could use page-up/page-down to scroll the help up and down accordingly.

To exit the help window, you could issue some keypress (like Ctrl+X? If 
you prototype this, just make it configurable -- I am sure people will 
have opinions.)

While the help window is up, the command entry bar could stay active -- 
i.e., you can type your command while the help is visible on-screen.

(As an aside: If we expect that we will have more than just one or two 
slash commands, it may be nice to have urwid create a popup suggestion 
box when you type a '/', hinting to the user what local shell commands 
are available.)

2. You could just display the help output as a flow item directly in the 
history pane, but if QEMU is receiving lots of events, you run the risk 
of having the help message flood off the screen.

Still, it might be a very simple way to implement it -- and the user can 
always just scroll up.

3. If we get around to implementing any kind of fancy syntax for the 
command entry bar, it may be possible to have the shell read the 
partially-entered command and guess which command we want to see help 
for -- maybe by pressing Ctrl+H?

A challenge will be where to pull the help text from. The QEMU server is 
not capable (today) of sending help information over the QMP socket itself.

We will need to implement a QMP command inside of QEMU directly that is 
capable of delivering this information to the client so that it can 
render it.

Since not all versions of QEMU will have this feature, the qmp-shell 
will need to be able to gracefully deal with the lack of help text, 
displaying an error indicating that this version of QEMU does not have 
help information compiled into it.


  reply	other threads:[~2021-06-01 23:49 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2021-05-21 19:02 ` Fwd: GSoC Intro - TUI interface for QMP Niteesh G. S.
2021-05-24 13:32   ` Stefan Hajnoczi
2021-05-24 17:34     ` John Snow
2021-06-02 11:08       ` Bruno Piazera Larsen
2021-06-11 14:06       ` Vladimir Sementsov-Ogievskiy via
2021-05-26 15:35     ` Fwd: " Niteesh G. S.
2021-06-01 23:47       ` John Snow [this message]
2021-06-08 15:01         ` Markus Armbruster
2021-06-08 15:49           ` John Snow
2021-06-09 11:56             ` Markus Armbruster
2021-06-09 17:06               ` John Snow
2021-06-10  7:19                 ` Markus Armbruster
2021-06-09 12:07             ` Daniel P. Berrangé
2021-06-10 14:35               ` John Snow
2021-06-09 12:03           ` 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \

* 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.