[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GSoC Intro - TUI interface for QMP

From: John Snow
Subject: Re: GSoC Intro - TUI interface for QMP
Date: Tue, 1 Jun 2021 19:47:08 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1

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


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 via email to

[Prev in Thread] Current Thread [Next in Thread]