[Qemu-devel] QEmu-Gui for all possibility's
Hi Peoples, i guess, Qemu would have been more popular, if exist a really well Gui for Users who whant work in cli/promt. It's give not a possible for build up a .. maybe a QT-Surface for Qemu, something like Qemu Manager, but this/QM it is nomore on the current state and it is not maintained anymore .. i have wrote something on reboot.pro as suggestion : http://reboot.pro/topic/21103-a-pretty-well-gui-for-qemu/ would be great , if something exist in future to be in able for use qemu in grafical and with all possibilitys what should be possible.. also in Gui :) and QT it is well for the big 3 Desk-Systems best regards Blacky blackysgate.de communitymember of Reactos.org communitymember of OpenMandriva.org
[Qemu-devel] QEMU GUI-Frontend based on Libvert API
Hi All, I know there's been several thread discussions regarding GUI-Frontend for QEMU and there already exist some projects that offers GUI for QEMU. But, recently, I've come to learn about an open source project called libvert which is actively being developed at http://www.libvirt.org. Below is a short description and the goal for this project: *(Note: The content below was taken from the following link: http://www.devx.com/amd/Article/31817/1763) libVirt, an open source project stewarded and driven by Red Hat, with contributions from Red Hat, IBM, Novell, Bull, VMware, and others. The libVirt project is a community-sponsored project that aims to bring more simplicity and standards to the Linux VM world. At its core, libVirt is a C toolkit that provides interaction with virtualization capabilities of the Linux operating system (and those related to Linux). The goal of libVirt is to provide the lowest possible generic and stable layer to manage VMs running on a machine. To accomplish this goal, libVirt will not try to be all things related to virtualization—instead libVirt will provide consistent and stable APIs to enable other tools to be built and used on top of the libVirt layer. Although the premise for libVirt seems pretty simple, the project has turned out some very mature features and tools, including: * Local administration tools—including a shell (virsh), a GNOME application, and a GNOME monitoring applet. * Plenty of control interfaces—shell scripting, Python and Perl bindings, and robust APIs. * Monitoring interfaces—feeding stats and states to applications, daemons, and the API hooks for other applications to utilize * A robust policy framework—enabling complex policies to monitor, control, and correct domains running on the node. * An XML structure for defining domains—portable, easily parsed, and human readable. A big advantage of libVirt's vendor-neutral stance is that you can define a framework for your VMs, applications, and policies that will run with most of the popular VMMs (XEN or QEMU). Code once—a somewhat unique aspect in the development space. Currently, there is a project called Virt-Manager that is building a GUI-Frontend using the LibVirt API. More info on the Virt-Manager project can be found here: http://people.redhat.com/berrange/virt-manager/ For me, I personally like the idea and focus of libVirt project and would like to see if any QEMU developers from the list would have an interest to team up with me to develop an open source GUI-Frontend based on the LibVirt API. I must admit here, that I do have a personal interest and motivation for developing such a project - The reasons are: I am planning to launch (soon) an open source community web site called OpenSourceDemo.com (OSD)... The site will make available DEMO's for some of the most popular Free Open Source Software applications. The site will make available 2 types of demo's. One type of demo will be online web based demos. The other will come in the form of a Software Appliance which is a pre-built and pre-configured software that is packaged in a single image file that can be downloaded and run on users local PC using a product like VMware Player or QEMU. Initially, before learning much about QEMU, I had plans to offer VMware Player to users on the site to run and demo the appliances. However, since the site promotes open source, I would prefer to offer an open source alternative to VMware Player and think QEMU is the best option. However, I need to have a GUI product that would make it easy for users to adopt and use - especially those that are already use to VMware product. It is this idea that has motivated me to start a GUI project that supports QEMU. And, I would like to leverage the LibVirt project for this. I invite and welcome developers from the list who would have interest to contribute in the development of a QEMU GUI based on the libVirt API. Evan ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU GUI
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 mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: wxWidgets and C: was Re: [Qemu-devel] QEMU GUI
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 [EMAIL PROTECTED] 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 ___ 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
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. ___ 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 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 ___ 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
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? ___ 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
On 7/8/06, Oliver Gerlich [EMAIL PROTECTED] 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. ___ 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
On Sun, Jul 09, 2006 at 05:03:12PM -0700, John R. wrote: On 7/8/06, Oliver Gerlich [EMAIL PROTECTED] 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. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU GUI
In message: [EMAIL PROTECTED] Johannes Schindelin [EMAIL PROTECTED] 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 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
wxWidgets and C: was Re: [Qemu-devel] QEMU GUI
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. ___ 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
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 ___ 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
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. ___ 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
On Sat, 8 Jul 2006 11:13:52 -0400 Jim C. Brown [EMAIL PROTECTED] 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 signature.asc Description: PGP signature ___ 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
-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- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU GUI
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 lookfeel, 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 at qwirx.com - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU GUI
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 lookfeel, 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 lookfeel, 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 lookfeel. Plus, Java code really runs everwhere without recompiling. As opposed to C#, I might add. Ciao, Dscho ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU GUI
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 lookfeel, 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 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU GUI
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 at qwirx.com - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU GUI
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 -=| ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU GUI
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. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU GUI
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 [EMAIL PROTECTED] 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 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU GUI
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 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU GUI
On 6/21/06, Fabrice Bellard [EMAIL PROTECTED] 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
Re: [Qemu-devel] QEMU GUI
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. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU GUI
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
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 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU GUI
On Thu, 22 Jun 2006 16:50:10 -0500 Anthony Liguori [EMAIL PROTECTED] 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 signature.asc Description: PGP signature ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] QEMU GUI
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
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 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
