Re: GSoC Intro - TUI interface for QMP

[John Snow <jsnow@redhat.com>]

On 5/26/21 11:35 AM, Niteesh G. S. wrote:
> Hello Stefan,
> 
> On Mon, May 24, 2021 at 7:02 PM Stefan Hajnoczi <stefanha@redhat.com 
> <mailto:stefanha@redhat.com>> 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.

--js