On 02/20/2012 08:27 AM, Gerd Hoffmann wrote:
Hi,
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.
/me suggests to simply have no default terminals with qemu -gtk.
One thing I wa
Hi,
> 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.
/me suggests to simply have no default terminals with qemu -gtk.
> One thing I was contemplating but ultimately didn't do wa
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
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
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 j
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
