Re: [Qemu-devel] RFC: running the user interface in a thread ...

[Gerd Hoffmann <kraxel@redhat.com>]

  Hi,

> >> Related:  Possibly we should move UIs to another *process* instead?
> >> At least the ones which use a UI toolkit (i.e. sdl, gtk, cocoa).
> > 
> > Is the worth the effort ? The majority of mgmt apps use spice/vnc which
> > is already out of process.

When you are using libvirt you are not using sdl/gtk/cocoa, period.

It is quite inconvenient to setup.  gtk isn't supported in the first
place (possible to make work with <qemu:args> trickery though).  Google
finds nothing on the topic.  I highly doubt this is in widespread use.

> > Will the people do use SDL/GTK/Coca backends,
> > be doing so in a scenario where moving the UI to a separate process is
> > a benefit to them ?

Using gtk/sdl is very convenient when using qemu directly.  Running
"qemu -some-switches-to-test-stuff -cdrom /path/to/fedora-live.iso" and
have gtk ui come up is nice, so you don't have care about finding an
unused port and to startup a viewer process.

We hardly can take that away without having users scream.

We could try to go for better integration with viewers.  Launching
remote-viewer with correct parameters would be a simple start (i.e.
something along the lines of -spice port=auto,viewer=yes).  But that
wouldn't match neither gtk nor libvirt+virt-viewer feature-wise because
it wouldn't allow to control the machine (reset, shutdown, ...).  So if
we want deprecate and later drop toolkit (gtk/sdl/cocoa) UIs in favor of
something like this we need to do better.

We could build some qemu viewer app using the spice gtk widget instead
of trying to move our existing gtk code into a separate process.

spice would need a portable shared memory transport then, otherwise such
a setup wouldn't be able to match gtk/sdl in performance.

cheers,
  Gerd