On 02/20/2012 07:59 AM, Gerd Hoffmann wrote:
On 02/20/12 14:45, Anthony Liguori wrote:
On 02/20/2012 03:17 AM, Gerd Hoffmann wrote:
On 02/20/12 00:44, Anthony Liguori wrote:
We want to expose VCs using a VteTerminal widget. We need access to
provide our
own CharDriverState in order to do this.
/me wonders why you touch vc's at all for this. Doesn't it make alot
more sense to just have a -chardev vte (which then opens a new tab in
the ui or something simliar)?
Does it? That's essentially exactly what -chardev vc does today. vc
currently works across all UIs (VNC, SDL, etc).
They all use the qemu terminal emulation and render the chars on a
displaysurface.
It seems a bit odd to
me to have to use a different argument for the GTK UI.
Why is this odd? gtk *is* different, it takes the character stream and
sends them off to the terminal emulation widget. That allows to do
stuff vc can't handle by design, for example placing vte in a new window
instead of a tab so you can watch vga and serial console side-by-side.
This would require touching a fair bit of code that handles things like
defaults. I'm not sure that having the distinction makes anything easier to
implement.
One thing I was contemplating but ultimately didn't do was QOM-ification of the
GTK front end. I couldn't rationalize why you would need to set settings but
now I think maybe it would be more useful.
So I'll take a pass in the next series at QOM-ification. I think I'll stick
with 'vc' but this would effectively be only for legacy syntax.
Regards,
Anthony Liguori
cheers,
Gerd
