[Qemu-devel] QEMU GUI

[Qemu-devel] QEMU GUI

[Fabrice Bellard]

Hi,

Concerning the QEMU GUI, my mind slightly evolved since my last posts on 
the topic: I think that a wxWidgets GUI would be the best as it is 
reasonnably portable and because it uses the native GUIs.

If someone is interested, I am ready to try to include such a GUI in the 
QEMU repository even if it is not usable yet.

Regards,

Fabrice.

Re: [Qemu-devel] QEMU GUI

[Mike Kronenberg]

Great Idea...

This would be in c++ then, or do You fancy another wxWidget flavour?  
(I remember You did not like c++ in QEMU)

If people are interested, we could try to port Q as a base, since  
it's going to be obsolete anyway (either by the new QEMU GUI or  
leopard)... :)
http://www.kju-app.org
http://www.kju-app.org/proj (trac)

Mike

On 21.06.2006, at 20:11, Fabrice Bellard wrote:

> Hi,
>
> Concerning the QEMU GUI, my mind slightly evolved since my last  
> posts on the topic: I think that a wxWidgets GUI would be the best  
> as it is reasonnably portable and because it uses the native GUIs.
>
> If someone is interested, I am ready to try to include such a GUI  
> in the QEMU repository even if it is not usable yet.
>
> Regards,
>
> Fabrice.
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] QEMU GUI

[gbeauchesne]

Hi,

> If people are interested, we could try to port Q as a base, since
> it's going to be obsolete anyway (either by the new QEMU GUI or
> leopard)... :)

I would be in a GUI that is not specific to QEMU. e.g. Xen/VT, Basilisk
II, SheepShaver, etc. ;-)

That could imply the use of an internal configs format with translators to
suit various emulators. Some IPC could also be involved to communicate
with the application for suspend, resume, fullscreen-switch, etc.

qt4 is also an interesting toolkit and the Open Source edition is
available under the GPL license for Linux/Unix, MacOS X and even Windows.

Bye,
Gwenole.

Re: [Qemu-devel] QEMU GUI

[gbeauchesne]

Hi,

> If people are interested, we could try to port Q as a base, since
> it's going to be obsolete anyway (either by the new QEMU GUI or
> leopard)... :)

I would be interested in a GUI that is not specific to QEMU. e.g. Xen/VT,
Basilisk II, SheepShaver, etc. ;-)

That could imply the use of an internal configs format with translators to
suit various emulators. Some IPC could also be involved to communicate
with the application for suspend, resume, fullscreen-switch, etc.

qt4 is also an interesting toolkit and the Open Source edition is
available under the GPL license for Linux/Unix, MacOS X and even Windows.

Bye,
Gwenole.

Re: [Qemu-devel] QEMU GUI

[Joe Lee]

>
> I would be interested in a GUI that is not specific to QEMU. e.g. Xen/VT,
> Basilisk II, SheepShaver, etc. ;-)
Gwenole, can you elaborate more on your comments above. Are your 
comments referring to having a GUI that can both run and manage several 
virtualization  product (QEMU, XEN, etc) from one central GUI interface? 
If so, I had a similar thought on this BUT was not sure how possible 
this was. Would like to hear more on what your thoughts are on this. 
Anyone else thought and comments to this would be appreciated!
-joe


gbeauchesne@mandriva.com wrote:
> Hi,
>
>   
>> If people are interested, we could try to port Q as a base, since
>> it's going to be obsolete anyway (either by the new QEMU GUI or
>> leopard)... :)
>>     
>
> I would be interested in a GUI that is not specific to QEMU. e.g. Xen/VT,
> Basilisk II, SheepShaver, etc. ;-)
>
> That could imply the use of an internal configs format with translators to
> suit various emulators. Some IPC could also be involved to communicate
> with the application for suspend, resume, fullscreen-switch, etc.
>
> qt4 is also an interesting toolkit and the Open Source edition is
> available under the GPL license for Linux/Unix, MacOS X and even Windows.
>
> Bye,
> Gwenole.
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>   

Re: [Qemu-devel] QEMU GUI

[Daniel P. Berrange]

On Wed, Jun 28, 2006 at 07:03:31PM -0400, Joe Lee wrote:
> >
> >I would be interested in a GUI that is not specific to QEMU. e.g. Xen/VT,
> >Basilisk II, SheepShaver, etc. ;-)
> Gwenole, can you elaborate more on your comments above. Are your 
> comments referring to having a GUI that can both run and manage several 
> virtualization  product (QEMU, XEN, etc) from one central GUI interface? 
> If so, I had a similar thought on this BUT was not sure how possible 
> this was. Would like to hear more on what your thoughts are on this. 
> Anyone else thought and comments to this would be appreciated!

Its entirely feasible if you have a management API to use which supports
the different virtualization backends. That would allow the GUI to be 
written to a single API, and yet control multiple systems like QEMU, Xen,
etc. The libvirt project aims to provide such a backend API, currently
supporting Xen, and a 'mock hypervisor' backend for testing purposes, and
it would be very desirable to have backends to drive QEMU & VMWare systems.
While the GUI would no doubt still have some differences in the area of
hardware /device configuration the bulk of it could be shared by using
the generic libvirt backend. I've got an early prototype of a Python/GTK 
based GUI for managing VMs via libvirt:

  http://people.redhat.com/berrange/virt-manager/

So if anyone's interested in trying to put together a QEMU backend for 
libvirt the project site is   http://libvirt.org/

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

Re: [Qemu-devel] QEMU GUI

[Joe Lee]

Daniel, thanks for your info and comments below. I really like the 
concept and work being done with virt-manager using the libvirt API.
Question:
Is the virt-manager project run by Redhat or yourself?
In what OS platform will virt-manager run under (Windows, Linux, OS-X) - 
Essentially, how cross-platform is it?
-joe

Daniel P. Berrange wrote:
> On Wed, Jun 28, 2006 at 07:03:31PM -0400, Joe Lee wrote:
>   
>>> I would be interested in a GUI that is not specific to QEMU. e.g. Xen/VT,
>>> Basilisk II, SheepShaver, etc. ;-)
>>>       
>> Gwenole, can you elaborate more on your comments above. Are your 
>> comments referring to having a GUI that can both run and manage several 
>> virtualization  product (QEMU, XEN, etc) from one central GUI interface? 
>> If so, I had a similar thought on this BUT was not sure how possible 
>> this was. Would like to hear more on what your thoughts are on this. 
>> Anyone else thought and comments to this would be appreciated!
>>     
>
> Its entirely feasible if you have a management API to use which supports
> the different virtualization backends. That would allow the GUI to be 
> written to a single API, and yet control multiple systems like QEMU, Xen,
> etc. The libvirt project aims to provide such a backend API, currently
> supporting Xen, and a 'mock hypervisor' backend for testing purposes, and
> it would be very desirable to have backends to drive QEMU & VMWare systems.
> While the GUI would no doubt still have some differences in the area of
> hardware /device configuration the bulk of it could be shared by using
> the generic libvirt backend. I've got an early prototype of a Python/GTK 
> based GUI for managing VMs via libvirt:
>
>   http://people.redhat.com/berrange/virt-manager/
>
> So if anyone's interested in trying to put together a QEMU backend for 
> libvirt the project site is   http://libvirt.org/
>
> Regards,
> Dan.
>   

Re: [Qemu-devel] QEMU GUI

[Daniel P. Berrange]

On Thu, Jun 29, 2006 at 05:05:25PM -0400, Joe Lee wrote:
> Daniel, thanks for your info and comments below. I really like the 
> concept and work being done with virt-manager using the libvirt API.
> Question:
> Is the virt-manager project run by Redhat or yourself?

At the moment its just me working on it -  I only put up those web pages
a couple of days ago so there isn't anyone else involved. The project was
initiated by Red Hat, but as with all our projects we welcome involvement
/ contribution / feedback from any community members.

> In what OS platform will virt-manager run under (Windows, Linux, OS-X) - 
> Essentially, how cross-platform is it?

My primary target at this time is Linux. The application is written in Python
with libvirt and GTK / PyGTK being primary dependancies. All the GTK stuff
is portable to Windows, and libvirt should be portable too. I'm not sure what
GTK OS-X support is like though. So although I'm not testing it on anything
other than Linux, it should be possible to make it portable if there were
demand. I honestly couldn't estimate the work to port it though, not having
any experiance developing for Windows / OS-X

Regards,
Dan.

> -joe
> 
> Daniel P. Berrange wrote:
> >On Wed, Jun 28, 2006 at 07:03:31PM -0400, Joe Lee wrote:
> >  
> >>>I would be interested in a GUI that is not specific to QEMU. e.g. Xen/VT,
> >>>Basilisk II, SheepShaver, etc. ;-)
> >>>      
> >>Gwenole, can you elaborate more on your comments above. Are your 
> >>comments referring to having a GUI that can both run and manage several 
> >>virtualization  product (QEMU, XEN, etc) from one central GUI interface? 
> >>If so, I had a similar thought on this BUT was not sure how possible 
> >>this was. Would like to hear more on what your thoughts are on this. 
> >>Anyone else thought and comments to this would be appreciated!
> >>    
> >
> >Its entirely feasible if you have a management API to use which supports
> >the different virtualization backends. That would allow the GUI to be 
> >written to a single API, and yet control multiple systems like QEMU, Xen,
> >etc. The libvirt project aims to provide such a backend API, currently
> >supporting Xen, and a 'mock hypervisor' backend for testing purposes, and
> >it would be very desirable to have backends to drive QEMU & VMWare systems.
> >While the GUI would no doubt still have some differences in the area of
> >hardware /device configuration the bulk of it could be shared by using
> >the generic libvirt backend. I've got an early prototype of a Python/GTK 
> >based GUI for managing VMs via libvirt:
> >
> >  http://people.redhat.com/berrange/virt-manager/
> >
> >So if anyone's interested in trying to put together a QEMU backend for 
> >libvirt the project site is   http://libvirt.org/
> >
> >Regards,
> >Dan.
> >  

-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

Re: [Qemu-devel] QEMU GUI

[Luca Barbato]

Fabrice Bellard wrote:
> Hi,
> 
> Concerning the QEMU GUI, my mind slightly evolved since my last posts on
> the topic: I think that a wxWidgets GUI would be the best as it is
> reasonnably portable and because it uses the native GUIs.

wx is nasty at best.

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

Re: [Qemu-devel] QEMU GUI

[Chris Wilson]

Hi Luca,

On Thu, 22 Jun 2006, Luca Barbato wrote:
> Fabrice Bellard wrote:
>> Concerning the QEMU GUI, my mind slightly evolved since my last posts on
>> the topic: I think that a wxWidgets GUI would be the best as it is
>> reasonnably portable and because it uses the native GUIs.
>
> wx is nasty at best.

I'd be interested to know why you dislike it. I actually find it very nice 
to code in wx, much easier than GTK or MFC or raw Win32 API.

I do hope that Fabrice will not mind the wx GUI being written in C++, as I 
don't know Python, which seems to be the most popular scripting language 
binding for wx.

Cheers, Chris.
-- 
_ ___ __     _
  / __/ / ,__(_)_  | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer |
\ _/_/_/_//_/___/ | We are GNU-free your mind-and your software |

Re: [Qemu-devel] QEMU GUI

[Luca Barbato]

Chris Wilson wrote:

> 
> I'd be interested to know why you dislike it.

The library is incompatible with itself depending on the configure time
options (see string constructors vs unicode string constructors)

Its ABI/API changes too often (ok, that is the result of they fixing
lots of bugs that require radical changes, but they could haven't been
on first place...)

Its architecture is a tad old.

> I actually find it very
> nice to code in wx, much easier than GTK or MFC or raw Win32 API.

Try Qt or ewl/etk if you don't like the default tcl/tk look, all 4 are
quite nicer architecture-wise and less painful to be handled as
dependence. MFC and winapi are surely worst than wx, gtk on the other
hand is simple and relatively easy to learn.

The main/only point of wx is that mimics quite well some sort of native
look&feel, and that is just nice if you have to handle windows users or
idiotic managers.


-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

Re: [Qemu-devel] QEMU GUI

[Chris Wilson]

Hi Luca,

Not wishing to start an argument, just to learn:

On Wed, 5 Jul 2006, Luca Barbato wrote:

> The library is incompatible with itself depending on the configure time 
> options (see string constructors vs unicode string constructors)

It's perfectly possible to write code that compiles and works fine on 
Unicode and non-Unicode builds (with wxT() macros).

> Its ABI/API changes too often (ok, that is the result of they fixing 
> lots of bugs that require radical changes, but they could haven't been 
> on first place...)

Not sure about ABI changes, but as far as I can see, they work hard to 
avoid incompatible API changes in stable branches, e.g. wx 2.6.x.

> Its architecture is a tad old.

But if you change it, then you break backwards compatibility. You can't 
have it both ways. Besides, what's wrong with the "old" architecture?

> Try Qt or ewl/etk if you don't like the default tcl/tk look, all 4 are
> quite nicer architecture-wise and less painful to be handled as
> dependence.

QT is only now free on Windows, and supports far fewer platforms than wx 
(no Mac support?). I personally don't like tcl as a language, and prefer 
to code in C++ for efficiency.

> MFC and winapi are surely worst than wx, gtk on the other
> hand is simple and relatively easy to learn.

GTK is also specific to Unix (not Mac) and Windows, and looks weird on 
Windows, not very native.

> The main/only point of wx is that mimics quite well some sort of native
> look&feel, and that is just nice if you have to handle windows users or
> idiotic managers.

Or platforms other than Windows and Unix.

Cheers, Chris.
-- 
_ ___ __     _
  / __/ / ,__(_)_  | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer |
\ _/_/_/_//_/___/ | We are GNU-free your mind-and your software |

Re: [Qemu-devel] QEMU GUI

[Johannes Schindelin]

Hi,

On Sat, 8 Jul 2006, Chris Wilson wrote:

> I personally don't like tcl as a language, and prefer to code in C++ for 
> efficiency.

Hmmm. "C++" and "efficiency" _does_ constitute a contradiction. Just think 
"operator+()". Honestly, the most inefficient code I saw was done in C++. 
You really should get a weapon's license before coding in C++.

> GTK is also specific to Unix (not Mac) and Windows, and looks weird on 
> Windows, not very native.

Again, hmmm. I do not agree with that "weird" argument. It is no more 
weird than _every single_ Windows version completely changing the 
look&feel, let alone the location of menu items. And they still do not 
provide anything akin to a "Help", because "Windows help" sure does not 
deserve that name. Rather "Welcome to hell" or something similar.

An important point to make is, GTK is in C, which means that even 
Microsoft based compilers respect the same ABI as anyone else (that is 
probably the reason they advertise C++ and C#, and not C, even if 
everything they produce is still C compatible, which is very visible in 
their APIs). WxLib is in C++, which means you cannot link with g++ if the 
lib was compiled with MSVC, and vice-versa. Thank you very much.

> > The main/only point of wx is that mimics quite well some sort of native
> > look&feel, and that is just nice if you have to handle windows users or
> > idiotic managers.
> 
> Or platforms other than Windows and Unix.

If in doubt, take Java. At least starting with Mustang, it really does a 
great job pleasing anyone married to their particular platform's 
look&feel. Plus, Java code really runs everwhere without recompiling. As 
opposed to C#, I might add.

Ciao,
Dscho

Re: [Qemu-devel] QEMU GUI

[M. Warner Losh]

In message: <Pine.LNX.4.63.0607080435400.29667@wbgn013.biozentrum.uni-wuerzburg.de>
            Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
: > I personally don't like tcl as a language, and prefer to code in C++ for 
: > efficiency.
: 
: Hmmm. "C++" and "efficiency" _does_ constitute a contradiction. Just think 
: "operator+()". Honestly, the most inefficient code I saw was done in C++. 
: You really should get a weapon's license before coding in C++.

You can hunt game or foot with C++.  Only one will feed your family :-)

Warner

wxWidgets and C: was Re: [Qemu-devel] QEMU GUI

[Jim C. Brown]

For the record, we can use wxWidgets in qemu even though we can not use C++
in qemu (something that I would be strongly against).

http://wxc.sourceforge.net/

Requiring this as a dependency would make it easier to deal with issues such as
C++ ABI compatibility by avoiding the direct use of C++.

There's a QtC that I considered using for a Qt GUI for qemu.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: wxWidgets and C: was Re: [Qemu-devel] QEMU GUI

[Joe Lee]

Jim C. Brown wrote:
> For the record, we can use wxWidgets in qemu even though we can not use C++
> in qemu (something that I would be strongly against).
>
> http://wxc.sourceforge.net/
>
> Requiring this as a dependency would make it easier to deal with issues such as
> C++ ABI compatibility by avoiding the direct use of C++.
>
> There's a QtC that I considered using for a Qt GUI for qemu.
>
>   
How about WX using Python - Is that an option?
-joe

Re: wxWidgets and C: was Re: [Qemu-devel] QEMU GUI

[Jim C. Brown]

On Sat, Jul 08, 2006 at 11:02:31AM -0400, Joe Lee wrote:
> Jim C. Brown wrote:
> >For the record, we can use wxWidgets in qemu even though we can not use C++
> >in qemu (something that I would be strongly against).
> >
> >http://wxc.sourceforge.net/
> >
> >Requiring this as a dependency would make it easier to deal with issues 
> >such as
> >C++ ABI compatibility by avoiding the direct use of C++.
> >
> >There's a QtC that I considered using for a Qt GUI for qemu.
> >
> >  
> How about WX using Python - Is that an option?
> -joe
> 

Good question. I'm not aware of a way to call Python code from inside of C.
I suppose if we could compile it into a shared library of some sort, that would
do the trick. (I'm assuming the Python lib would compile into something that
was callable externally using the C ABI, not the C++ ABI. If it's the latter
then using Python would still be a bad idea.)

I'm of the opinion that it would just be easier to use wxc directly instead of
trying to use a Python binding in a C project, though.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: wxWidgets and C: was Re: [Qemu-devel] QEMU GUI

[Kevin F. Quinn]

[-- Attachment #1: Type: text/plain, Size: 290 bytes --]

On Sat, 8 Jul 2006 11:13:52 -0400
"Jim C. Brown" <jma5@umd.edu> wrote:

> Good question. I'm not aware of a way to call Python code from inside
> of C. 

See http://docs.python.org/ext/ext.html

However doing this just means yet another language dependency.

-- 
Kevin F. Quinn

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: wxWidgets and C: was Re: [Qemu-devel] QEMU GUI

[Oliver Gerlich]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jim C. Brown schrieb:
> For the record, we can use wxWidgets in qemu even though we can not use C++
> in qemu (something that I would be strongly against).
> 
> http://wxc.sourceforge.net/
> 
> Requiring this as a dependency would make it easier to deal with issues such as
> C++ ABI compatibility by avoiding the direct use of C++.
> 
> There's a QtC that I considered using for a Qt GUI for qemu.
> 

Is wxC still under active development? The CVS version seems to be quite
old, and I also couldn't find any documentation.

Generally it might be quite difficult to find a GUI toolkit with C
bindings (besides GTK), as most toolkits seem to be targeted at an
object-oriented language, and many go into the direction of script
languages and "rapid application development".
So I think we should either just use GTK, or make Qemu ready for
integration of C++ GUI code (and use one of the common GUI toolkits), or
add an interface for external GUIs (and run the GUI as an external
process, written in Python or Perl or the like).

Regards,
Oliver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEsCLoTFOM6DcNJ6cRAp4dAJwPa7JW7JJzBkg3GnsP+XskTVtAPwCgzpr1
W9RuT6XdO66GtD8evBXfDKc=
=inA8
-----END PGP SIGNATURE-----

Re: wxWidgets and C: was Re: [Qemu-devel] QEMU GUI

[John R.]

On 7/8/06, Oliver Gerlich <olig9@gmx.de> wrote:

> Is wxC still under active development? The CVS version seems to be quite
> old, and I also couldn't find any documentation.
>

Well it wouldn't be the first unmaintained batch of code added to
QEMU... Slirp is the example that comes to mind. In fact I think the
QEMU developers are the de facto maintainers of the Slirp codebase.

> So I think we should either just use GTK, or make Qemu ready for
> integration of C++ GUI code (and use one of the common GUI toolkits), or

It seems pretty clear that C++ is a non-starter.

> add an interface for external GUIs (and run the GUI as an external
> process, written in Python or Perl or the like).
>

This is already possible via command line options and accessing the
monitor via perl expect or python expect. Of course an API would be
easier to use and less likely to break. I'd certainly prefer an
out-of-process GUI to admitting C++.

I'm not sure what the issue is with just using GTK. That's what the
nonpareil HP calculator emulator uses for the same reason: Eric
dislikes C++.

-- John.

Re: wxWidgets and C: was Re: [Qemu-devel] QEMU GUI

[Jim C. Brown]

On Sun, Jul 09, 2006 at 05:03:12PM -0700, John R. wrote:
> On 7/8/06, Oliver Gerlich <olig9@gmx.de> wrote:
> 
> >Is wxC still under active development? The CVS version seems to be quite
> >old, and I also couldn't find any documentation.
> >
> 
> Well it wouldn't be the first unmaintained batch of code added to
> QEMU... Slirp is the example that comes to mind. In fact I think the
> QEMU developers are the de facto maintainers of the Slirp codebase.
> 

I believe that it is still being used in other language bindings such as Eiffel, Haskell, or Ocaml.

> >So I think we should either just use GTK, or make Qemu ready for
> >integration of C++ GUI code (and use one of the common GUI toolkits), or
> 
> It seems pretty clear that C++ is a non-starter.
> 
> >add an interface for external GUIs (and run the GUI as an external
> >process, written in Python or Perl or the like).
> >
> 
> This is already possible via command line options and accessing the
> monitor via perl expect or python expect. Of course an API would be
> easier to use and less likely to break. I'd certainly prefer an
> out-of-process GUI to admitting C++.
> 

I agree with you here.

> I'm not sure what the issue is with just using GTK. That's what the
> nonpareil HP calculator emulator uses for the same reason: Eric
> dislikes C++.
> 

Mainly that GTK works only on X and Windows, and that it lacks native Windows widgets.

> -- John.
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: wxWidgets and C: was Re: [Qemu-devel] QEMU GUI

[David Fraser]

John R. wrote:
> On 7/8/06, Oliver Gerlich <olig9@gmx.de> wrote:
>
>> Is wxC still under active development? The CVS version seems to be quite
>> old, and I also couldn't find any documentation.
>>
>
> Well it wouldn't be the first unmaintained batch of code added to
> QEMU... Slirp is the example that comes to mind. In fact I think the
> QEMU developers are the de facto maintainers of the Slirp codebase.
>
>> So I think we should either just use GTK, or make Qemu ready for
>> integration of C++ GUI code (and use one of the common GUI toolkits), or
>
> It seems pretty clear that C++ is a non-starter.
I don't think so. I think the real goal here should be to decide: what
are the required features for a Qemu GUI that meets a broad range of
needs, and what would be the fastest and most maintainable way to code
them? Surely the integration with the Qemu backend would still be
decoupled enough that you could compile Qemu without the GUI using only
C if you wanted to?

David

Re: wxWidgets and C: was Re: [Qemu-devel] QEMU GUI

[Jason Gress]

I know this is a lot different than the discussion so far, but has anyone 
considered keeping SDL and using an SDL GUI similar to ZSNES?  Take a look 
(for those not familiar) at http://www.zsnes.com and grab a download.  Many 
Linux distro package managers have it also.  You don't need a SNES ROM to 
look at the GUI.  It looks like it would be hard to borrow even though it's 
GPL (parts are in ASM...) but I thought I'd bounce the idea off of the list.

	Jason

On Tuesday 11 July 2006 02:44, David Fraser wrote:
> John R. wrote:
> > On 7/8/06, Oliver Gerlich <olig9@gmx.de> wrote:
> >> Is wxC still under active development? The CVS version seems to be quite
> >> old, and I also couldn't find any documentation.
> >
> > Well it wouldn't be the first unmaintained batch of code added to
> > QEMU... Slirp is the example that comes to mind. In fact I think the
> > QEMU developers are the de facto maintainers of the Slirp codebase.
> >
> >> So I think we should either just use GTK, or make Qemu ready for
> >> integration of C++ GUI code (and use one of the common GUI toolkits), or
> >
> > It seems pretty clear that C++ is a non-starter.
>
> I don't think so. I think the real goal here should be to decide: what
> are the required features for a Qemu GUI that meets a broad range of
> needs, and what would be the fastest and most maintainable way to code
> them? Surely the integration with the Qemu backend would still be
> decoupled enough that you could compile Qemu without the GUI using only
> C if you wanted to?
>
> David
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: wxWidgets and C: was Re: [Qemu-devel] QEMU GUI

[Linas Žvirblis]

Jason Gress wrote:

> I know this is a lot different than the discussion so far, but has anyone 
> considered keeping SDL and using an SDL GUI similar to ZSNES?

I did not check the source code, but it looks just like any other
self-made bitmap-based SDL menu I have seen. It is like inventing yet
another GUI toolkit.

I am new around here, so I am a bit confused. What is this GUI all
about? Is it about (a) replacing SDL with something else for drawing the
contents of the window, or (b) providing GUI for configuring virtual
machine options, just like numerous front-ends already do?

I assume this is (a), as it is beyond me why would anyone want to do
(b), when there already are front-ends for Windows, KDE, GTK+, Java,
MacOS, etc.

Re: wxWidgets and C: was Re: [Qemu-devel] QEMU GUI

[Oliver Gerlich]

Linas Žvirblis wrote:
> Jason Gress wrote:
> 
> 
>>I know this is a lot different than the discussion so far, but has anyone 
>>considered keeping SDL and using an SDL GUI similar to ZSNES?
> 
> 
> I did not check the source code, but it looks just like any other
> self-made bitmap-based SDL menu I have seen. It is like inventing yet
> another GUI toolkit.
> 
> I am new around here, so I am a bit confused. What is this GUI all
> about? Is it about (a) replacing SDL with something else for drawing the
> contents of the window, or (b) providing GUI for configuring virtual
> machine options, just like numerous front-ends already do?
> 
> I assume this is (a), as it is beyond me why would anyone want to do
> (b), when there already are front-ends for Windows, KDE, GTK+, Java,
> MacOS, etc.
> 

Personally, I'd be interested to have a GUI for controlling a running 
Qemu instance: change CD-ROM, add/remove USB devices, save/restore VM 
snapshots (though this would also require to save/restore disk 
snapshots), and eg. provide buttons to switch between guest Virtual 
Terminals. Furthermore, I'd like to get information like guest CPU usage 
and guest hard disk access; this would probably require that the GUI is 
integrated into Qemu.
Whether actual graphics output is done via SDL or GTK or something else 
is probably not that important.

Configuration could still be done with the current command line flags, 
but if one of the many config GUIs could be integrated into Qemu, that 
might be useful as well.

Regards,
Oliver

Re: wxWidgets and C: was Re: [Qemu-devel] QEMU GUI

[Linas Žvirblis]

Oliver Gerlich wrote:

> Personally, I'd be interested to have a GUI for controlling a running
> Qemu instance: change CD-ROM, add/remove USB devices, save/restore VM
> snapshots (though this would also require to save/restore disk
> snapshots), and eg. provide buttons to switch between guest Virtual
> Terminals. 

Already exists at <http://qemuctl.sourceforge.net/>. I am not sure if it
is developed anymore, but I am going to integrate it into my own
project, in the nearest future.

> Furthermore, I'd like to get information like guest CPU usage
> and guest hard disk access; this would probably require that the GUI is
> integrated into Qemu.

Not if this data is available via monitor. And I certainly want it to
be, as this is one of the coolest features.

> Configuration could still be done with the current command line flags,
> but if one of the many config GUIs could be integrated into Qemu, that
> might be useful as well.

None of them (at least the ones I know) are written in C, so integrating
them _into_ QEMU is not really possible. And I absolutely fail to see
the reason for doing so.

If there is a need for an official GUI, choose one, write yet another,
but, please, do not enforce things on users. The current situation works
quite well for projects like cdrtools so why should it not work for QEMU?

Re: [Qemu-devel] QEMU GUI

[Luca Barbato]

Chris Wilson wrote:
> 
> QT is only now free on Windows, and supports far fewer platforms than wx
> (no Mac support?). I personally don't like tcl as a language, and prefer
> to code in C++ for efficiency.

qt/mac exists.

> 
> GTK is also specific to Unix (not Mac) and Windows, and looks weird on
> Windows, not very native.

gtk/cocoa exists.

> 
> Or platforms other than Windows and Unix.

name them, macosx has X and cocoa mostly supported by major toolkits.
tk+tile works everywhere and is also looking good.

=)

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

[Qemu-devel] Insert module into kernel

[Tieu Ma Dau]

[-- Attachment #1: Type: text/plain, Size: 760 bytes --]

Hi all,
 I want to simulate the ARM system and add a simple simulated device with its corresponding module device driver. So:
 1. I must run the command "insmod" to insert this module into kernel. But there is not this command in the ARM Linux shell
 2. I must run the command "mknod" to make a file (exp: /dev/my_simulated_device) corresponding to the simulated device. But this command is not run because the "read only" property of file system.
 3. I must make a small program in which I open the file by the command "fopen("/dev/my_simulated_device","w")" but I think that I have the problem as in the question 2
 Do you have any idea?
 Thanks
 Tieu
 
 		
---------------------------------
Yahoo! Music Unlimited - Access over 1 million songs.Try it free. 

[-- Attachment #2: Type: text/html, Size: 873 bytes --]

Re: [Qemu-devel] Insert module into kernel

[Paul Brook]

On Wednesday 12 July 2006 14:15, Tieu Ma Dau wrote:
> Hi all,
>  I want to simulate the ARM system and add a simple simulated device with
> its corresponding module device driver. So: 
> 1. I must run the command "insmod" to insert this module into kernel. 
> But there is not this command in the ARM Linux shell
> 2. I must run the command "mknod" to make a file 
> (exp: /dev/my_simulated_device) corresponding to the simulated device. But
> this command is not run because the "read only" property of file system.
> 3. I must make a small program in which I open the file by the command
> "fopen("/dev/my_simulated_device","w")" but I think that I have the problem
> as in the question 2 Do you have any idea?

None of these problems have anything to do with qemu.  They are problems with 
your root FS. Qemu works exactly the same way as a real Arm machine.

The arm_test image on the qemu website is a minimal cut-down test/demo system. 
It is not not intended to be a full general purpose linux system. Sounds like 
you need to get yourself a proper linux install. The Debian installers work 
pretty much out the box.

If you already are using a different linux distro, you need to contact whoever 
supplied it.

Paul

Re: [Qemu-devel] Insert module into kernel

[Tieu Ma Dau]

[-- Attachment #1: Type: text/plain, Size: 2174 bytes --]

Hi,
I tried your instruction as below:
+ Download the installer Debian Sarge 3.1r0 on FreeOSZoo project: http://free.oszoo.org/download.php
+ Run the ARM simulated system with the command: " ./qemu-system-arm -kernel my_own_2.6_compiled_kernel sarge.img "
+ But I got the error: 
"
VFS: Unable to mount root fs via NFS, trying floppy
VFS: Cannot open root device "<NULL>" or unknown-block(2,0)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)
"
The error arrives because this installer is only used for x86, not for ARM? or because I used wrong this installer? or the installer which Paul introduced is not the Debian Sarge on FreeOSZoo prj website?
Do you have any idea?
Tieu

Paul Brook <paul@codesourcery.com> wrote: On Wednesday 12 July 2006 14:15, Tieu Ma Dau wrote:
> Hi all,
>  I want to simulate the ARM system and add a simple simulated device with
> its corresponding module device driver. So: 
> 1. I must run the command "insmod" to insert this module into kernel. 
> But there is not this command in the ARM Linux shell
> 2. I must run the command "mknod" to make a file 
> (exp: /dev/my_simulated_device) corresponding to the simulated device. But
> this command is not run because the "read only" property of file system.
> 3. I must make a small program in which I open the file by the command
> "fopen("/dev/my_simulated_device","w")" but I think that I have the problem
> as in the question 2 Do you have any idea?

None of these problems have anything to do with qemu.  They are problems with 
your root FS. Qemu works exactly the same way as a real Arm machine.

The arm_test image on the qemu website is a minimal cut-down test/demo system. 
It is not not intended to be a full general purpose linux system. Sounds like 
you need to get yourself a proper linux install. The Debian installers work 
pretty much out the box.

If you already are using a different linux distro, you need to contact whoever 
supplied it.

Paul


 __________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[-- Attachment #2: Type: text/html, Size: 2575 bytes --]

Re: [Qemu-devel] QEMU GUI

[Christian MICHON]

On 6/21/06, Fabrice Bellard <fabrice@bellard.org> wrote:
> Hi,
>
> Concerning the QEMU GUI, my mind slightly evolved since my last posts on
> the topic: I think that a wxWidgets GUI would be the best as it is
> reasonnably portable and because it uses the native GUIs.
>
> If someone is interested, I am ready to try to include such a GUI in the
> QEMU repository even if it is not usable yet.
>

Do you still want SDL to move out of the project ?

--
Christian

Re: [Qemu-devel] QEMU GUI

[Dan Sandberg]

Christian MICHON wrote:

> On 6/21/06, Fabrice Bellard <fabrice@bellard.org> wrote:
>
>> Hi,
>>
>> Concerning the QEMU GUI, my mind slightly evolved since my last posts on
>> the topic: I think that a wxWidgets GUI would be the best as it is
>> reasonnably portable and because it uses the native GUIs.
>>
>> If someone is interested, I am ready to try to include such a GUI in the
>> QEMU repository even if it is not usable yet.
>>
>
> Do you still want SDL to move out of the project ?
>
> -- 
> Christian
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
Wouldn't it be a good idea to separate SDL from the actual VM-parts?

If the VM were made as library with a well-defined API that could be 
either statically linked at compile-time or dynamically linked like a 
.dll at run-time, then there could be several flavors of GUI:s for 
different purposes and target systems and all still continuing to 
support and improve the same VM-core so that the project does not fork 
into several.

Those who need no graphic output at all (perhaps using Qemu for a vitual 
server, sandbox or honeypot) wouldn't have to link SDL or anything else, 
just using the Qemu-VM with minimum overhead and dependences.
Those who want SDL just statically link the SDL-interface code at 
compile time, similar to the situation today.
Those who want to make a Windows only GUI in Delphi could choose to load 
Qemu as a DLL at run-time.
Those who want a C++ GUI use either way and Qemu can still be C-code 
only (which is probably faster, more code-efficient and more compatible 
with other programming languages than turning Qemu into a C++ class - my 
quess).
If anyone (like me) would like to try for instance OpenGL as a 
replacement for SDL and try to implement true hardware assistance for 
the graphic card emulation it would probably be easier not having to 
hack up Qemu.
One interesting flavor of GUI could be MONO which should work on most 
platforms with the same source code and cross networks and still have 
good graphics performance on any machine having decent OpenGL drivers 
(which will be the common case soon with more OpenGL-friendly X-window 
implementations being introduced).

Regards
Dan Sandberg

Re: [Qemu-devel] QEMU GUI

[Anthony Liguori]

Fabrice Bellard wrote:
> Hi,
>
> Concerning the QEMU GUI, my mind slightly evolved since my last posts 
> on the topic: I think that a wxWidgets GUI would be the best as it is 
> reasonnably portable and because it uses the native GUIs.

I think the first step is to validate whether wxWidgets will be 
adequate.  I've not used it myself but poked around the site a little.  
It appears there's a gl canvas which should be a reasonable place to 
start.  It seems like overkill for QEMU though.

Does anyone know a wxWidget which provides direct pixel access to 
something that ends up being a XShmImage?  If they're canvas uses a 
normal XImage performance is going to be pretty crappy.

Regards,

Anthony Liguori

> If someone is interested, I am ready to try to include such a GUI in 
> the QEMU repository even if it is not usable yet.
>
> Regards,
>
> Fabrice.
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] QEMU GUI

[Kevin F. Quinn]

[-- Attachment #1: Type: text/plain, Size: 2746 bytes --]

On Thu, 22 Jun 2006 16:50:10 -0500
Anthony Liguori <aliguori@us.ibm.com> wrote:

> Fabrice Bellard wrote:
> > Hi,
> >
> > Concerning the QEMU GUI, my mind slightly evolved since my last
> > posts on the topic: I think that a wxWidgets GUI would be the best
> > as it is reasonnably portable and because it uses the native GUIs.
> 
> I think the first step is to validate whether wxWidgets will be 
> adequate.

Part of that should be to determine what the GUI will actually do; in
particular should it "wrap" the guest window, or should it be a
separate window for guest selection, configuration etc (which is my
preference).  The latter case should allow the guest window to remain
SDL, with the guest selection/configuration stuff in wxWidgets.

>  I've not used it myself but poked around the site a
> little. It appears there's a gl canvas which should be a reasonable
> place to start.  It seems like overkill for QEMU though.

At this point you're talking about embedding the Qemu guest window
directly into the wxWidgets GUI, yes?  I'm thinking the primitives that
the graphics driver in QEMU is emulating are not at the GL level, but
at the raw hardware level - I don't know how far apart these things
are, but I'd hazard that a GL canvas won't really help.

> Does anyone know a wxWidget which provides direct pixel access to 
> something that ends up being a XShmImage?  If they're canvas uses a 
> normal XImage performance is going to be pretty crappy.

I do think the ability to pass through accelerated graphics stuff from
the guest to the host should be a big factor.  I assume this is what
the cirrus emulation currently does through SDL, to some extent at
least. This issue would make or break guest graphics performance.

I'm ignorant of details, but from a vague hand-wavy distance it should
be simple enough to retain SDL for the emulation windows (and SDL does
seem to be the tool for the job there), with a separate wxWidgets
frontend GUI to manage the launch and visibility of emulation windows,
assist in guest creation etc.

Perhaps it's worth asking the WxWidgets people what they might suggest.

> Regards,
> 
> Anthony Liguori
> 
> > If someone is interested, I am ready to try to include such a GUI
> > in the QEMU repository even if it is not usable yet.
> >
> > Regards,
> >
> > Fabrice.
> >
> >
> > _______________________________________________
> > Qemu-devel mailing list
> > Qemu-devel@nongnu.org
> > http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel


-- 
Kevin F. Quinn

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [Qemu-devel] QEMU GUI

[Anthony Liguori]

Kevin F. Quinn wrote:
> Part of that should be to determine what the GUI will actually do;

You're getting ahead of yourself.  Just getting qemu to start with 
wxWidgets instead of SDL would be a big step in the right direction.

> At this point you're talking about embedding the Qemu guest window
> directly into the wxWidgets GUI, yes?  I'm thinking the primitives that
> the graphics driver in QEMU is emulating are not at the GL level, but
> at the raw hardware level - I don't know how far apart these things
> are, but I'd hazard that a GL canvas won't really help.
>   

QEMU doesn't expose any real 2d acceleration to the drawing routines.  
Using GL canvas would be interesting though as you'd get hardware 
scaling with interpolation.  That's a big performance win.

> I do think the ability to pass through accelerated graphics stuff from
> the guest to the host should be a big factor.  I assume this is what
> the cirrus emulation currently does through SDL, to some extent at
> least. This issue would make or break guest graphics performance.
>   

Nope, currently SDL is used as one big bitmap viewer.

> I'm ignorant of details, but from a vague hand-wavy distance it should
> be simple enough to retain SDL for the emulation windows (and SDL does
> seem to be the tool for the job there), with a separate wxWidgets
>   

Bleh, why would you say that?  SDL is pretty crappy on X.  It's just a 
wrapper around XShmImage.  You can access the same thing via GTK or any 
other reasonable toolkit.

SDL is mostly useful because of the number of backend drivers that it 
supports.

Regards,

Anthony Liguori

> frontend GUI to manage the launch and visibility of emulation windows,
> assist in guest creation etc.
>
> Perhaps it's worth asking the WxWidgets people what they might suggest.
>
>   
>> Regards,
>>
>> Anthony Liguori
>>
>>     
>>> If someone is interested, I am ready to try to include such a GUI
>>> in the QEMU repository even if it is not usable yet.
>>>
>>> Regards,
>>>
>>> Fabrice.
>>>
>>>
>>> _______________________________________________
>>> Qemu-devel mailing list
>>> Qemu-devel@nongnu.org
>>> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>>>       
>>
>> _______________________________________________
>> Qemu-devel mailing list
>> Qemu-devel@nongnu.org
>> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>>     
>
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>   

Re: [Qemu-devel] QEMU GUI

[Kevin F. Quinn]

[-- Attachment #1: Type: text/plain, Size: 2815 bytes --]

On Thu, 22 Jun 2006 20:53:54 -0500
Anthony Liguori <aliguori@us.ibm.com> wrote:

> Kevin F. Quinn wrote:
> > Part of that should be to determine what the GUI will actually do;
> 
> You're getting ahead of yourself.  Just getting qemu to start with 
> wxWidgets instead of SDL would be a big step in the right direction.
> 
> > At this point you're talking about embedding the Qemu guest window
> > directly into the wxWidgets GUI, yes?  I'm thinking the primitives
> > that the graphics driver in QEMU is emulating are not at the GL
> > level, but at the raw hardware level - I don't know how far apart
> > these things are, but I'd hazard that a GL canvas won't really help.
> >   
> 
> QEMU doesn't expose any real 2d acceleration to the drawing
> routines. Using GL canvas would be interesting though as you'd get
> hardware scaling with interpolation.  That's a big performance win.

And scaling the guest window would be really useful...

> > I do think the ability to pass through accelerated graphics stuff
> > from the guest to the host should be a big factor.  I assume this
> > is what the cirrus emulation currently does through SDL, to some
> > extent at least. This issue would make or break guest graphics
> > performance. 
> 
> Nope, currently SDL is used as one big bitmap viewer.
> 
> > I'm ignorant of details, but from a vague hand-wavy distance it
> > should be simple enough to retain SDL for the emulation windows
> > (and SDL does seem to be the tool for the job there), with a
> > separate wxWidgets 
> 
> Bleh, why would you say that?  SDL is pretty crappy on X.  It's just
> a wrapper around XShmImage.  You can access the same thing via GTK or
> any other reasonable toolkit.

Ok; my ignorance is shining through :)  I thought SDL did a lot more
than that.

> SDL is mostly useful because of the number of backend drivers that it 
> supports.

Had a rummage through the wxWidgets code. It uses SDL for sound support
(or can do so, at any rate) but not for video.  With the GTK backend you
get an XShm image if XShm is supported (wxGTK asks GTK for
GDK_IMAGE_FASTEST). I don't find any references to XShm in the x11
backend, so I guess the raw X11 backend doesn't use it.  On X you'd
normally go for the GTK backend anyway.

> Regards,
> 
> Anthony Liguori
> 
> > frontend GUI to manage the launch and visibility of emulation
> > windows, assist in guest creation etc.
> >
> > Perhaps it's worth asking the WxWidgets people what they might
> > suggest.
> >
> >   
> >> Regards,
> >>
> >> Anthony Liguori
> >>
> >>     
> >>> If someone is interested, I am ready to try to include such a GUI
> >>> in the QEMU repository even if it is not usable yet.
> >>>
> >>> Regards,
> >>>
> >>> Fabrice.

-- 
Kevin F. Quinn

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 191 bytes --]