Features/GtkDisplayState: Difference between revisions

From QEMU
(Created page with '== Summary == Replace the current SDL DisplayState driver with a GTK driver. == Owner == * '''Name:''' Anthony Liguori * '''Email:''' anthony@codemonkey.ws == Detailed Summar…')
 
mNo edit summary
Line 5: Line 5:
== Owner ==
== Owner ==


* '''Name:''' Anthony Liguori
* '''Name:''' [[User:AnthonyLiguori|Anthony Liguori]]
* '''Email:''' anthony@codemonkey.ws
* '''Email:''' anthony@codemonkey.ws



Revision as of 02:40, 2 March 2010

Summary

Replace the current SDL DisplayState driver with a GTK driver.

Owner

Detailed Summary

Qemu suffers from a number of usability problems that boil down to the fact that we use SDL to render the guest screen and cannot easily expose any UI elements to the user. This includes, but is not limited to:

  • The human monitor is exposed in a tab that's only accessible via a keyboard short cut. A user has no way of discovering the monitor without consulting documentation.
  • The human monitor is not scrollable which means that common commands cannot be discovered by executing 'help'
  • Copy and paste is not supported in the human monitor or any virtual console
  • We use the title bar to expose status information (such as the key sequence for exiting grab)
  • We have no way to notify the user when important events happen (such as guest out of disk space)
  • We can not use GUI dialogs to prompt the user for file paths or passwords

We can solve all of these problems by introducing a DisplayState driver that uses a modern tool kit. GTK is a nice choice because it is portable and has a favorable license.

There are some downsides to introducing a GTK driver that should be considered:

  • SDL supports non-windowed environments such as framebuffer devices
  • SDL has far fewer dependencies than GTK
  • The current limitations of SDL mean that a VNC client has roughly the same experience as the SDL window. The GTK elements would not be accessible via VNC leading to either severely reduced functionality for VNC or continuing to maintain the existing code
  • A GTK GUI could be written outside of qemu using gtk-vnc. It's arguable that we should focus on building this instead of adding to the qemu process directly