Re: [Qemu-devel] [PATCH v2] ui/gtk: require at least GTK 2.18 and VTE 0.26

[Anthony Liguori]

Stefan Weil <address@hidden> writes:

> Am 22.02.2013 17:48, schrieb Anthony Liguori:
>> Stefan Weil <address@hidden> writes:
>>
>>> But we need a different solution because not all platforms
>>> support VTE. It must be possible to use GTK without VTE,
>>> so VTE needs its own section in configure.
>> As I mentioned eariler, the "other platforms" should start looking at
>> supporting VTE.
>>
>> Rolling our own terminal emulation is not reasonable.
>>
>> Regards,
>>
>> Anthony Liguori
>
> As I mentioned earlier, there is no VTE binary for MinGW / MinGW-w64.
> According to the VTE mailing lists, the last efforts to fix this were
> stopped
> some time ago. I tried building a VTE binary and had to get a cascade
> of required packages. Most of those packages also had to be built locally
> and needed modifications for MinGW.Even then, I had the impression that
> the VTE code still needs a lot of work to be compilable with MinGW.
>
> There _is_ already a working terminal emulation in QEMU since several years.
> I know its limitations very well and also contributed some improvements
> in the past. The QEMU terminal emulation is not excellent, but it is good
> enough for the monitor, serial console and other text windows.
>
> Therefore I strongly want to have GTK support based on QEMU's terminal
> emulation (or any other terminal emulation != VTE) for MinGW.
>

Sorry, VTE is the only way forward.  Just ignoring the obvious problem
of incomplete terminal emulation, there are many other problems with our
current terminal code.  For example, try the following with gtk:

  qemu -name "Färber"

And then with SDL

  qemu -name "Färber" -sdl

And do an 'info name' command in the monitor.  Might not seem like a big
deal if your language only has a few differences from US-ASCII but it's
a huge issue for a language like Simplified Chinese where there is no
overlap at all.

Furthermore, these languages require use of an Input Method to enter in
characters.  VTE provides a single function call to add the necessary
menu options and handles all of the details for you.

Our current console code also renders with a bitmap font.  With a high
density display, which I suspect most laptops will have in a few years
thanks to Retina, the rendered bitmap font is not even readable.  Sure,
you can scale, but scaling looks awful compared to a properly rendered
vectored font.

And then there are the issues of copy/paste, accessibility with screen
readers, I could go on for hours I think :-)

I'm 100% confident that quickest way to a decent UI for Windows is to
fixup VTE.  It doesn't seem bad right now but as we add more features,
the gap between our console code and VteTerminal will be massive.

Regards,

Anthony Liguori

> Regards,
>
> Stefan Weil