qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] GTK UI is now the default


From: Jan Kiszka
Subject: Re: [Qemu-devel] GTK UI is now the default
Date: Fri, 22 Feb 2013 15:03:06 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

On 2013-02-22 14:46, Anthony Liguori wrote:
> Jan Kiszka <address@hidden> writes:
> 
>> On 2013-02-22 00:04, Anthony Liguori wrote:
>>>
>>> Since this is a pretty visible change for a lot of people, I thought I'd
>>> send a top level note.  The GTK UI is now committed and is the default
>>> UI provided it's available.
>>>
>>> For anyone counting, it's been a little more than 7 years in the making:
>>>
>>> http://article.gmane.org/gmane.comp.emulators.qemu/9726
>>>
>>> If you want to try it, make sure you have the gtk-2.0 development
>>> packages installed and the VTE development packages.
>>
>> What's your plan now regarding persistent configuration?
> 
> There are a couple options.  We could use gconf which is the Gnome Way
> of doing it.  That's an application wide setting that isn't really
> configurable outside of the menus.
> 
> We could also extend -display to be parsed via QemuOpts.  -display vnc
> is the hard part here but I think either Paolo or I had a patch at one
> point to do it.  Paolo, was that you?  If not, I can search my branches.
> 
> If we were using QemuOpts, it could then be configured via the system
> wide config file (/etc/qemu/qemu.conf).  It wouldn't automatically be
> persisted when you clicked the menu though.
> 
>> I'd like to
>> make "Grab on hover" default here as it is how I'm used to work with
>> SDL, but also other tools like rdesktop. Clicking on some menu item each
>> time I start a guest is obviously no solution.
>>
>> Then, any concerns about adding a "control" menu? Something to issue
>> standard tasks without monitor interaction ("power down", "reset",
>> "stop")?
> 
> No, it's on my TODO list even although I'd be thrilled for you to do it.
> I'm currently working on an Edit menu for Copy/Paste in the VTE tabs.
> 
> What I'd like to get to for 1.5 is:
> 
> File
>  Stop
>  Start

A checked "Stop" item seems more handy to me.

>  Reset
>  Power Down

I think those do not fit well under "File" and rather deserve a separate
menu. File could host some "Load" / "Save VM image" etc.

>  ----------
>  Quit
> 
> Edit
>  Copy
>  Paste
> 
> Devices
>  ide1-cd0
>   Eject
>   Change
    Commit?

Yes, looks good.

> 
> View
>  ...  
> 
> One thing to note about adding new menu items is that we should take
> care to set sensitivity appropriately.  For instance, Stop should only
> be enabled if the vm is running and Start should only be enabled if the
> vm is stopped.

That is resolved with a checked item, see above.

> 
> It would be nice to set a timeout with Power Down too such that if we
> don't see a vmstate change after 30 seconds, we pop up a message dialog
> saying that the guest is not responding to ACPI requests or whatever.

Well, one after the other.

> 
> BTW, another thing that should be easy to add is a "GDB" menu item in
> the View menu that starts the gdbstub, then launches gdb with a script
> to connect back to QEMU so that from the UI, you just get a GDB prompt
> without having to do all of the target remote stuff.

That's not that easy as you have to know the binary and path as well
(/path/to/vmlinux, in most cases). But I will think about it.

> 
> In terms of the primary audience here, I think we should really be
> focused on people doing OS development or other similar operations.

We shouldn't compete with VBox GUI-wise, true. But it would not harm to
have basic usability for desktop scenarios in mind as well. Folks that
do heavy OS development tend to script / use the command line anyway.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux



reply via email to

[Prev in Thread] Current Thread [Next in Thread]