Re: [Qemu-devel] VMware Player
On Wed, 2006-06-14 at 18:10 +0200, Oliver Gerlich wrote: > Btw. regarding your earlier question about a Qemu GUI similar to VMware: > AFAIK at least two people have posted GUI patches for Qemu (look in the > mailing list archive); so far there has been little response to that, > and I suppose that these patches "just" need testing and some feedback > (as they seem to be pretty intrusive, with changing the video output and > the input handling stuff). > Real world, gui's are just so easy & desirable, especially if the gui is consistent across os's, and part of the original distro. I think take-up would be huge (well huge-er, current takeup is huge) Kim ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [usb] display device identifier string for user with info usb
On Wed, 2006-06-14 at 18:17 +0200, Fabrice Bellard wrote:
> OK for this patch, but the following must be changed:
>
> 1) All instances of strcpy and strncpy must be replaced by pstrcpy.
>
> 2) product_name_size must be passed as parameter to usb_host_find_device().
lo. Attached is something I hope you will find to be more clean. I
used a define for product name size since this is used in two places to
define an array size (in usb_host_device_open() and the FindDeviceState
struct).
--- qemu/hw/usb.h 2006-05-25 18:58:51.0 -0500
+++ qemu/hw/usb.h 2006-06-15 00:56:38.0 -0500
@@ -128,6 +128,7 @@
int (*handle_data)(USBDevice *dev, int pid, uint8_t devep,
uint8_t *data, int len);
uint8_t addr;
+char devname[32];
int state;
uint8_t setup_buf[8];
--- qemu/hw/usb-hub.c 2006-05-25 18:58:51.0 -0500
+++ qemu/hw/usb-hub.c 2006-06-15 01:27:09.0 -0500
@@ -544,6 +544,8 @@
s->dev.handle_control = usb_hub_handle_control;
s->dev.handle_data = usb_hub_handle_data;
+pstrcpy(s->dev.devname, sizeof(s->dev.devname), "QEMU USB Hub");
+
s->nb_ports = nb_ports;
for(i = 0; i < s->nb_ports; i++) {
port = &s->ports[i];
--- qemu/hw/usb-hid.c 2006-05-25 18:58:51.0 -0500
+++ qemu/hw/usb-hid.c 2006-06-15 01:26:37.0 -0500
@@ -521,6 +521,8 @@
s->dev.handle_data = usb_mouse_handle_data;
s->kind = USB_TABLET;
+pstrcpy(s->dev.devname, sizeof(s->dev.devname), "QEMU USB Tablet");
+
return (USBDevice *)s;
}
@@ -539,5 +541,7 @@
s->dev.handle_data = usb_mouse_handle_data;
s->kind = USB_MOUSE;
+pstrcpy(s->dev.devname, sizeof(s->dev.devname), "QEMU USB Mouse");
+
return (USBDevice *)s;
}
--- qemu/hw/usb-msd.c 2006-05-26 16:53:41.0 -0500
+++ qemu/hw/usb-msd.c 2006-06-15 02:17:18.0 -0500
@@ -374,6 +374,7 @@
{
MSDState *s;
BlockDriverState *bdrv;
+char msd_info_str[32];
s = qemu_mallocz(sizeof(MSDState));
if (!s)
@@ -389,6 +390,10 @@
s->dev.handle_control = usb_msd_handle_control;
s->dev.handle_data = usb_msd_handle_data;
+snprintf(msd_info_str, sizeof(msd_info_str), "QEMU USB MSD(%.17s)",
+ filename);
+pstrcpy(s->dev.devname, sizeof(s->dev.devname), msd_info_str);
+
s->scsi_dev = scsi_disk_init(bdrv, usb_msd_command_complete, s);
usb_msd_handle_reset((USBDevice *)s, 0);
return (USBDevice *)s;
--- qemu/vl.c 2006-06-14 12:32:25.0 -0500
+++ qemu/vl.c 2006-06-15 00:56:38.0 -0500
@@ -3412,8 +3447,8 @@
speed_str = "?";
break;
}
-term_printf(" Device %d.%d, speed %s Mb/s\n",
-0, dev->addr, speed_str);
+term_printf(" Device %d.%d, Speed %s Mb/s, Product %s\n",
+0, dev->addr, speed_str, dev->devname);
}
}
--- qemu/usb-linux.c 2006-05-25 18:58:51.0 -0500
+++ qemu/usb-linux.c 2006-06-15 02:35:56.0 -0500
@@ -44,11 +44,13 @@
int vendor_id, int product_id,
const char *product_name, int speed);
static int usb_host_find_device(int *pbus_num, int *paddr,
+char *product_name,
const char *devname);
//#define DEBUG
#define USBDEVFS_PATH "/proc/bus/usb"
+#define PRODUCT_NAME_SZ 32
typedef struct USBHostDevice {
USBDevice dev;
@@ -145,8 +147,9 @@
char buf[1024];
int descr_len, dev_descr_len, config_descr_len, nb_interfaces;
int bus_num, addr;
+char product_name[PRODUCT_NAME_SZ];
-if (usb_host_find_device(&bus_num, &addr, devname) < 0)
+if (usb_host_find_device(&bus_num, &addr, product_name, devname) < 0)
return NULL;
snprintf(buf, sizeof(buf), USBDEVFS_PATH "/%03d/%03d",
@@ -230,6 +233,14 @@
dev->dev.handle_reset = usb_host_handle_reset;
dev->dev.handle_control = usb_host_handle_control;
dev->dev.handle_data = usb_host_handle_data;
+
+if (product_name[0] == '\0')
+snprintf(dev->dev.devname, sizeof(dev->dev.devname),
+ "host:%s", devname);
+else
+pstrcpy(dev->dev.devname, sizeof(dev->dev.devname),
+product_name);
+
return (USBDevice *)dev;
}
@@ -337,6 +348,7 @@
int product_id;
int bus_num;
int addr;
+char product_name[PRODUCT_NAME_SZ];
} FindDeviceState;
static int usb_host_find_device_scan(void *opaque, int bus_num, int addr,
@@ -345,8 +357,11 @@
const char *product_name, int speed)
{
FindDeviceState *s = opaque;
-if (vendor_id == s->vendor_id &&
-product_id == s->product_id) {
+if ((vendor_id == s->vendor_id &&
+product_id == s->product_id) ||
+(bus_num == s->bus_num &&
+addr == s->addr)) {
+pstrcpy(s->product_name, PRODUCT_NAME_SZ, product_name);
s->bus_num = bus_num;
s->ad
RE: [Qemu-devel] Sparse file support under windows
Attached updated patch (this time against CVS HEAD) bye Frediano Ziglio PS: Thanks for apply my patches > > At least the default should be sparse files if the filesystem > supports them. > > Fabrice. > > ZIGLIO, Frediano, VF-IT wrote: > > Good question. As you like... I can remove option if you > prefer. I don't > > know how performs sparse file on windows so perhaps someone > can still > > prefer normal file for performance. > > > > freddy77 > > > > > > > >>OK for the idea, but why is a new option needed ? Sparse file usage > >>should be automatic if the filesystem supports it. > >> > >>Regards, > >> > >>Fabrice. > >> > >>ZIGLIO, Frediano, VF-IT wrote: > >> > >>>Hi, > >>> this patch add sparse file support under Windows > >> > >>(supported on NTFS). > >> > >>>It add a -s flag to qemu create and qemu convert. It > >> > >>contain also a new > >> > >>>implementation for ftruncate witch not fill manually space > >> > >>but only use > >> > >>>SetEndOfFile (so to handle correctly sparse file) > >>> > >>>freddy77 > >>> > >>> > >>> > >>> > >> > >>-- > >>-- > >> > >>>___ > >>>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 > > > > > > > > ___ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel > > sparse.diff Description: sparse.diff ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Final path for windows close problem
Updated patch against CVS HEAD bye Frediano Ziglio close.diff Description: close.diff ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] -redir revisited
Am 14.06.2006 um 21:53 schrieb Ed Swierk: On 6/5/06, René Korthaus <[EMAIL PROTECTED]> wrote: I researched current qemu cvs and found out that the patch was integrated not complete but to 95%. There are two lines in slirp/ misc.c that need a change (patch attached). Tested to work with Mac OS X host and debian guest i could reach the Apache running inside the guest via localhost:8080 with the appropriate -redir command. It looks like kju: is based on qemu 0.8.0, which definitely had the bug you found. However, this was fixed in 0.8.1. Did you try a current version of qemu (0.8.1 or cvs) without your patch? Yes, indeed, cvs worked. I didn't get that patch on the list... Thanks for your help! Patch is withdrawn... I'm having trouble seeing how your patch could help solve the redir problem, since as far as I can tell, our_addr is no longer used for anything at all. Grepping for our_addr comes up with a buch of hits that are either #if 0'ed or irrelevant (e.g. get_dns_addr, which references our_addr before our_addr has been set). This was just copy&paste from the patch of November 2005 I mentioned before. --Ed ___ 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] VMware Player
On 6/15/06, kadil <[EMAIL PROTECTED]> wrote: On Wed, 2006-06-14 at 18:10 +0200, Oliver Gerlich wrote: Real world, gui's are just so easy & desirable, especially if the gui is consistent across os's, and part of the original distro. I think take-up would be huge (well huge-er, current takeup is huge) Kim Some of us appriciate the fact that qemu has no "GUI" per se. ;0) -- why does the size matter? ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VMware Player
On Thursday 15 June 2006 14:18, WaxDragon wrote: > On 6/15/06, kadil <[EMAIL PROTECTED]> wrote: > > On Wed, 2006-06-14 at 18:10 +0200, Oliver Gerlich wrote: > > Real world, gui's are just so easy & desirable, especially if the gui is > > consistent across os's, and part of the original distro. I think > > take-up would be huge (well huge-er, current takeup is huge) > > > > Kim > > Some of us appriciate the fact that qemu has no "GUI" per se. ;0) Sure. But to 'sell' the project to wider audience, which may be helpful for its longer term development, a GUI is necessary. Usability engineering isn't as much fun as hacking the JIT, or whatever, but in the end usability counts. A lot. J ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VMware Player
Hi, On Thu, 15 Jun 2006, Julian Seward wrote: > On Thursday 15 June 2006 14:18, WaxDragon wrote: > > On 6/15/06, kadil <[EMAIL PROTECTED]> wrote: > > > On Wed, 2006-06-14 at 18:10 +0200, Oliver Gerlich wrote: > > > Real world, gui's are just so easy & desirable, especially if the gui is > > > consistent across os's, and part of the original distro. I think > > > take-up would be huge (well huge-er, current takeup is huge) > > > > > > Kim > > > > Some of us appriciate the fact that qemu has no "GUI" per se. ;0) > > Sure. But to 'sell' the project to wider audience, which may be > helpful for its longer term development, a GUI is necessary. > Usability engineering isn't as much fun as hacking the JIT, ... which is why most GUIs seem to be cobbled together, are badly designed and implemented: either the developer is bored to death, or it is a bad (or inexperienced) developer to begin with ... > or whatever, but in the end usability counts. A lot. Which is exactly why I like to wrap up things in a really small Tcl/Tk wrapper. And usually after that, the discussions with the employer revolve around what color this and that button should have. Sigh. Ciao, Dscho ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VMware Player
Some of us appriciate the fact that qemu has no "GUI" per se. ;0) Your right! the keyword is "some" but not all. I think if QEMU is to be adopted by the masses it will need to come up with a quality GUI-Frontend. However the CLI can always be in place for those who want and prefer to use it. Otherwise, I think most users will prefer to stay with VMware and especially that there VMware player AND VMware server edition is now FREE. I appreciate the effort that some are making to develop a GUI for QEMU - There's a few project I see that trying to achieve this. But, I wish they all could come together and work together to develop a nice GUI. I would like to see a sub-project exist in the QEMU site so all can come and contribute to that effort. joe WaxDragon wrote: On 6/15/06, kadil <[EMAIL PROTECTED]> wrote: On Wed, 2006-06-14 at 18:10 +0200, Oliver Gerlich wrote: Real world, gui's are just so easy & desirable, especially if the gui is consistent across os's, and part of the original distro. I think take-up would be huge (well huge-er, current takeup is huge) Kim Some of us appriciate the fact that qemu has no "GUI" per se. ;0) ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VMware Player
Hi, On Thu, 15 Jun 2006, Joe Lee wrote: > > Some of us appriciate the fact that qemu has no "GUI" per se. ;0) > Your right! the keyword is "some" but not all. I think if QEMU is to be > adopted by the masses it will need to come up with a quality GUI-Frontend. You're right! However, as Julian pointed out: it is less than fascinating to work on a GUI, _especially_ if it is for the masses who tend to criticize without contributing*Footnote 1*. So, unless the people who want a GUI so badly do it themselves, I think they will have to hire somebody to do it for them. Remember: since it is free, there is customer, and therefore no customer can be lost! Ciao, Dscho [1] I remember we had a great discussion on this list, where somebody thought it would be such a good idea to _demand_ features. And since it is Open Source, the good developers should work for free. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VMware Player
Joe Lee wrote: Some of us appriciate the fact that qemu has no "GUI" per se. ;0) Your right! the keyword is "some" but not all. I think if QEMU is to be adopted by the masses it will need to come up with a quality GUI-Frontend. However the CLI can always be in place for those who want and prefer to use it. Otherwise, I think most users will prefer to stay with VMware and especially that there VMware player AND VMware server edition is now FREE. I appreciate the effort that some are making to develop a GUI for QEMU - There's a few project I see that trying to achieve this. But, I wish they all could come together and work together to develop a nice GUI. I would like to see a sub-project exist in the QEMU site so all can come and contribute to that effort. IIRC Fabrice has (quite some time ago) stated that he'd like to see a Qemu GUI that is integrated into the app (ie. not an external application that only captures the Qemu window), and also that the GUI should be done in GTK (though I'm not sure about the exact wording, so I might be spreading false rumours here ;) This would mean that the next steps for a GUI would be to "migrate" input event handling and graphics output from SDL to a GUI toolkit like GTK. Incidentally, that is more or less what the patches do which are floating around on the mailing list. I guess the reason why they were not integrated in CVS is that they are quite big and intrusive, and that Fabrice waits for some more feedback and testing of the patches. So, in the end, testing is probably something that anyone can do who has enough spare time and wants to put that time into developing a GUI for Qemu :) Regards, Oliver ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: VMware Player
Julian Seward <[EMAIL PROTECTED]> writes: > On Thursday 15 June 2006 14:18, WaxDragon wrote: >> On 6/15/06, kadil <[EMAIL PROTECTED]> wrote: >> > On Wed, 2006-06-14 at 18:10 +0200, Oliver Gerlich wrote: >> > Real world, gui's are just so easy & desirable, especially if the gui is >> > consistent across os's, and part of the original distro. I think >> > take-up would be huge (well huge-er, current takeup is huge) >> >> Some of us appriciate the fact that qemu has no "GUI" per se. ;0) > > Sure. But to 'sell' the project to wider audience, which may be > helpful for its longer term development, a GUI is necessary. For what it's worth, VMware Player doesn't have much of a GUI. It has about five menu items, a couple of buttons, and maybe one dialog box. -- "While the Melissa license is a bit unclear, Melissa aggressively encourages free distribution of its source code." --Kevin Dalley <[EMAIL PROTECTED]> ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Sparc64 fixes
Hi, This patchset contains the following fixes to Sparc64 target: gdbstub.c: added 'p' protocol support to bypass the broken 'g' protocol, fix off-by-one error in register numbering, allow 64-bit breakpoints hw/sun4u.c: fixed broken VGA, switch to Cirrus target-sparc/translate.c: mulx and udivx didn't work, fix gdb memory reads With the patches applied I can debug with gdb64, VGA console works using OpenBIOS, and there are no mulx/udivx-related crashes. I'd be interested to hear if adding the 'p' protocol has any side effects on other architectures. If so, I can limit the protocol to Sparc64 only. _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ qemu-sparc.patch-60.bz2 Description: Binary data ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: VMware Player
Good point on that, BUT it's not just about the GUI. It's about an "easy" way to install the product and run a given app without the need to create/setup a VM - To me that is the benefit of the VMware player. However, not much of a big benefit IF QEMU is made easy to install and has a nice GUI along with it - IMO. Joe Ben Pfaff wrote: Julian Seward <[EMAIL PROTECTED]> writes: On Thursday 15 June 2006 14:18, WaxDragon wrote: On 6/15/06, kadil <[EMAIL PROTECTED]> wrote: On Wed, 2006-06-14 at 18:10 +0200, Oliver Gerlich wrote: Real world, gui's are just so easy & desirable, especially if the gui is consistent across os's, and part of the original distro. I think take-up would be huge (well huge-er, current takeup is huge) Some of us appriciate the fact that qemu has no "GUI" per se. ;0) Sure. But to 'sell' the project to wider audience, which may be helpful for its longer term development, a GUI is necessary. For what it's worth, VMware Player doesn't have much of a GUI. It has about five menu items, a couple of buttons, and maybe one dialog box. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: VMware Player
On 6/15/06, Joe Lee <[EMAIL PROTECTED]> wrote: Good point on that, BUT it's not just about the GUI. It's about an "easy" way to install the product and run a given app without the need to create/setup a VM - To me that is the benefit of the VMware player. However, not much of a big benefit IF QEMU is made easy to install and has a nice GUI along with it - IMO. Joe I've seen several projects ship preinstalled images with prebuilt qemu binaries, and a script to start it. It doesn't get much easier than that. WD -- why does the size matter? ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VMware Player
You're right! However, as Julian pointed out: it is less than fascinating to work on a GUI, _especially_ if it is for the masses who tend to criticize without contributing*Footnote 1*. I am not sure I agree if that thought. It really depends on the mission or goal of the project. In the case for QEMU, I am not sure what its goal/mission is. Is the project just to scratch an itch to server a few people who needs it? Is it to fill a void over what exist in commercial software? Or, is the intent to develop something FREE and then offer some support service around the product? As far as users criticizing, that always going to be the case in Open Source - Show me a project where users don't criticize. As far as contribution goes, not everyone has the talent and ability to contribute - Like me. The way I see it, criticizing (when done in a constructive way) is not a bad thing. It is what drives the project when others share there views on features/functionality good or bad! -joe Johannes Schindelin wrote: Hi, On Thu, 15 Jun 2006, Joe Lee wrote: Some of us appriciate the fact that qemu has no "GUI" per se. ;0) Your right! the keyword is "some" but not all. I think if QEMU is to be adopted by the masses it will need to come up with a quality GUI-Frontend. You're right! However, as Julian pointed out: it is less than fascinating to work on a GUI, _especially_ if it is for the masses who tend to criticize without contributing*Footnote 1*. So, unless the people who want a GUI so badly do it themselves, I think they will have to hire somebody to do it for them. Remember: since it is free, there is customer, and therefore no customer can be lost! Ciao, Dscho [1] I remember we had a great discussion on this list, where somebody thought it would be such a good idea to _demand_ features. And since it is Open Source, the good developers should work for free. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: VMware Player
WaxDragon wrote: On 6/15/06, Joe Lee <[EMAIL PROTECTED]> wrote: Good point on that, BUT it's not just about the GUI. It's about an "easy" way to install the product and run a given app without the need to create/setup a VM - To me that is the benefit of the VMware player. However, not much of a big benefit IF QEMU is made easy to install and has a nice GUI along with it - IMO. Joe I've seen several projects ship preinstalled images with prebuilt qemu binaries, and a script to start it. It doesn't get much easier than that. WD Can you point me to the one you know about? Joe ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VMware Player
Johannes Schindelin wrote: Hi, On Thu, 15 Jun 2006, Joe Lee wrote: Some of us appriciate the fact that qemu has no "GUI" per se. ;0) Your right! the keyword is "some" but not all. I think if QEMU is to be adopted by the masses it will need to come up with a quality GUI-Frontend. You're right! However, as Julian pointed out: it is less than fascinating to work on a GUI, _especially_ if it is for the masses who tend to criticize without contributing*Footnote 1*. So, unless the people who want a GUI so badly do it themselves, I think they will have to hire somebody to do it for them. Remember: since it is free, there is customer, and therefore no customer can be lost! Ciao, Dscho [1] I remember we had a great discussion on this list, where somebody thought it would be such a good idea to _demand_ features. And since it is Open Source, the good developers should work for free. BTW, I am curious to know how much would it cost to develop a good GUI-Frontend for QEMU that would be comparable to VMware. How much man hours would this likely take? Joe ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VMware Player
Hi, On Thu, 15 Jun 2006, Joe Lee wrote: > > > > You're right! However, as Julian pointed out: it is less than fascinating to > > work on a GUI, _especially_ if it is for the masses who tend to criticize > > without contributing*Footnote 1*. > > I am not sure I agree if that thought. It really depends on the mission or > goal of the project. In the case for QEMU, I am not sure what its goal/mission > is. Is the project just to scratch an itch to server a few people who needs > it? Is it to fill a void over what exist in commercial software? Or, is the > intent to develop something FREE and then offer some support service around > the product? As far as I know: Fabrice started the project because he had this idea that translation should be faster than interpreting, and not much more difficult. He proved his point. And many people actually use QEmu, which is all the better. > As far as users criticizing, that always going to be the case in Open > Source - Show me a project where users don't criticize. Yes. And developers will always complain about those who profit and don't contribute. > As far as contribution goes, not everyone has the talent and ability to > contribute - Like me. I doubt that. You _can_ contribute. You actually do it right now. > The way I see it, criticizing (when done in a constructive way) is not a > bad thing. It is what drives the project when others share there views > on features/functionality good or bad! This is a contribution! By telling what is important to you, you contribute to the future value of the project (note that I say "project", not "product"...) There is a subtle point-of-no-return though. The story I was referring to, was where a person did not contribute, but instead called people names if they did not do what she wanted, which was effectively to work hard and for free. Which is just not fair. Ciao, Dscho P.S.: Actually, it was a "he", but I say "she" here, because he was a real pussy, and I am very happy he left the list. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VMware Player
Hi, On Thu, 15 Jun 2006, Joe Lee wrote: > BTW, I am curious to know how much would it cost to develop a good > GUI-Frontend for QEMU that would be comparable to VMware. How much man > hours would this likely take? I do not know VMware. Anybody? I would be interested, too, to know how complicated that frontend is... Should not be too difficult to reproduce it in Tcl/Tk (with a proper Tcl script as config format). Ciao, Dscho ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VMware Player
Johannes Schindelin wrote: Hi, On Thu, 15 Jun 2006, Joe Lee wrote: BTW, I am curious to know how much would it cost to develop a good GUI-Frontend for QEMU that would be comparable to VMware. How much man hours would this likely take? I do not know VMware. Anybody? I would be interested, too, to know how complicated that frontend is... Should not be too difficult to reproduce it in Tcl/Tk (with a proper Tcl script as config format). Ciao, Dscho I am hoping some experience developers would comment on this! Joe ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VMware Player
Johannes Schindelin wrote: Hi, On Thu, 15 Jun 2006, Joe Lee wrote: You're right! However, as Julian pointed out: it is less than fascinating to work on a GUI, _especially_ if it is for the masses who tend to criticize without contributing*Footnote 1*. I am not sure I agree if that thought. It really depends on the mission or goal of the project. In the case for QEMU, I am not sure what its goal/mission is. Is the project just to scratch an itch to server a few people who needs it? Is it to fill a void over what exist in commercial software? Or, is the intent to develop something FREE and then offer some support service around the product? As far as I know: Fabrice started the project because he had this idea that translation should be faster than interpreting, and not much more difficult. He proved his point. And many people actually use QEmu, which is all the better. As far as users criticizing, that always going to be the case in Open Source - Show me a project where users don't criticize. Yes. And developers will always complain about those who profit and don't contribute. As far as contribution goes, not everyone has the talent and ability to contribute - Like me. I doubt that. You _can_ contribute. You actually do it right now. The way I see it, criticizing (when done in a constructive way) is not a bad thing. It is what drives the project when others share there views on features/functionality good or bad! This is a contribution! By telling what is important to you, you contribute to the future value of the project (note that I say "project", not "product"...) There is a subtle point-of-no-return though. The story I was referring to, was where a person did not contribute, but instead called people names if they did not do what she wanted, which was effectively to work hard and for free. Which is just not fair. Ciao, Dscho P.S.: Actually, it was a "he", but I say "she" here, because he was a real pussy, and I am very happy he left the list. I share your view. Complaining and bitching in the wrong way is not a good thing. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] QEMU Build error on Sparc/Solaris 10 with 20060615 CVS
gmake -C mips-softmmu all gmake[1]: Entering directory `/home/jonathan/experimental/qemu-snapshot-2006-06-15_23/mips-softmmu' gcc -Wall -O2 -g -fno-strict-aliasing -mcpu=ultrasparc -m32 -ffixed-g2 -ffixed-g3 -fno-delayed-branch -fno-omit-frame-pointer -ffixed-i0 -fno-reorder-blocks -fno-optimize-sibling-calls -I. -I.. -I/home/jonathan/experimental/qemu-snapshot-2006-06-15_23/target-mips -I/home/jonathan/experimental/qemu-snapshot-2006-06-15_23 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/home/jonathan/experimental/qemu-snapshot-2006-06-15_23/fpu -I/home/jonathan/experimental/qemu-snapshot-2006-06-15_23/slirp -c -o op.o /home/jonathan/experimental/qemu-snapshot-2006-06-15_23/target-mips/op.c /home/jonathan/experimental/qemu-snapshot-2006-06-15_23/target-mips/op.c: In function `float64_is_unordered': /home/jonathan/experimental/qemu-snapshot-2006-06-15_23/target-mips/op.c:972: warning: implicit declaration of function `float_raise' /home/jonathan/experimental/qemu-snapshot-2006-06-15_23/target-mips/op.c:972: error: `float_flag_invalid' undeclared (first use in this function) /home/jonathan/experimental/qemu-snapshot-2006-06-15_23/target-mips/op.c:972: error: (Each undeclared identifier is reported only once /home/jonathan/experimental/qemu-snapshot-2006-06-15_23/target-mips/op.c:972: error: for each function it appears in.) /home/jonathan/experimental/qemu-snapshot-2006-06-15_23/target-mips/op.c: In function `float32_is_unordered': /home/jonathan/experimental/qemu-snapshot-2006-06-15_23/target-mips/op.c:1004: error: `float_flag_invalid' undeclared (first use in this function) gmake[1]: *** [op.o] Error 1 gmake[1]: Leaving directory `/home/jonathan/experimental/qemu-snapshot-2006-06-15_23/mips-softmmu' gmake: *** [subdir-mips-softmmu] Error 2 [EMAIL PROTECTED] [~/experimental/qemu-snapshot-2006-06-15_23/] 231> -- -- Jonathan Kalbfeld +1 323 620 6682 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VMware Player
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Johannes Schindelin schrieb: > Hi, > > On Thu, 15 Jun 2006, Joe Lee wrote: > > >>BTW, I am curious to know how much would it cost to develop a good >>GUI-Frontend for QEMU that would be comparable to VMware. How much man >>hours would this likely take? > > > I do not know VMware. Anybody? I would be interested, too, to know how > complicated that frontend is... There are some screenshots of "VMware Workstation" at http://www.vmware.com (see Products menu). Didn't find screenshots of "VMware Player" there, but Google image search shows a few for "VMplayer". > Should not be too difficult to reproduce > it in Tcl/Tk (with a proper Tcl script as config format). If you are familiar with Tcl/Tk, maybe you could give some hints on how to embed the Qemu window into such an app? I think there are only two ways for making a GUI: - - embed the Qemu SDL window into another application (there seem to be various hacks that do this under X11; not sure about Win32) - - replace Qemu's SDL part with some GUI toolkit (GTK, Tcl/Tk...) I guess the second way is quite a lot of work. The first way is a bit "hackish", as eg. events have to propagated from the GUI app to the Qemu window... how would this work with Tcl/Tk? Probably with the second way it would also be difficult to display real-time status info in the GUI (eg. guest CPU load, guest HDD accesses, network accesses). Regards, Oliver -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEkd9lTFOM6DcNJ6cRArqJAKC5wiG3lsVMA5TmNp7EdqRa1cDbrQCeNGI2 8oVTKgDXpLo2QJN0NxQQP/U= =IACV -END PGP SIGNATURE- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Doing a Tcl/Tk based frontend
On Thu, 2006-06-15 at 17:29, Oliver Gerlich wrote: > If you are familiar with Tcl/Tk, maybe you could give some hints on how > to embed the Qemu window into such an app? Embedding the emulator's window might not be the best way to attack the problem. Especially since you would need to be able to detach it to be able to go full screen. I have pondered the Tk frontend idea before so lemme dump my random thoughts on the subject and see how many holes get punched in em. How about one Tk window as a 'master controller' for all VMs and each running VM opens a new window. The master window gets a tab for each running VM and a seperate interpreter spawned to monitor the console (running on stdin/stdout piped back to Tcl) for events and update the widgets and send commands in response to user input. That gets you media insert/remove, serial port attachment, etc. Doing it that way means QEMU itself requires no modifications, but might in reality need some small adjustment to make the console interface more rigid, otherwise I suspect expect would need to get involved to deal with communications with with the existing console. -- John M. http://www.beau.org/~jmorris This post is 100% M$Free! Geekcode 3.1:GCS C+++ UL$ P++ L+++ W++ w--- Y++ b++ 5+++ R tv- e* r ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VMware Player
Hi, On Fri, 16 Jun 2006, Oliver Gerlich wrote: > Johannes Schindelin schrieb: > > > > On Thu, 15 Jun 2006, Joe Lee wrote: > > > >>BTW, I am curious to know how much would it cost to develop a good > >>GUI-Frontend for QEMU that would be comparable to VMware. How much man > >>hours would this likely take? > > > > I do not know VMware. Anybody? I would be interested, too, to know how > > complicated that frontend is... > > There are some screenshots of "VMware Workstation" at > http://www.vmware.com (see Products menu). Didn't find screenshots of > "VMware Player" there, but Google image search shows a few for "VMplayer". Thanks. But I would like to know if there is a developer who has experience with the GUI. It is one thing to see the GUI, another to work with it. > > Should not be too difficult to reproduce > > it in Tcl/Tk (with a proper Tcl script as config format). > > If you are familiar with Tcl/Tk, maybe you could give some hints on how > to embed the Qemu window into such an app? I would go the easy way: just before starting QEmu, hide the Tk window... no need for embedding. Yes, I know this is a lame answer. But I am quite certain that most users would be happy about it. They do not *need* to do something fancy. They run the virtual machine, shut it down, and that's it. Ciao, Dscho ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Doing a Tcl/Tk based frontend
On Thu, Jun 15, 2006 at 05:52:14PM -0500, John Morris wrote: > On Thu, 2006-06-15 at 17:29, Oliver Gerlich wrote: > > > If you are familiar with Tcl/Tk, maybe you could give some hints on how > > to embed the Qemu window into such an app? > > Embedding the emulator's window might not be the best way to attack the > problem. Especially since you would need to be able to detach it to be > able to go full screen. I have pondered the Tk frontend idea before so > lemme dump my random thoughts on the subject and see how many holes get > punched in em. With the new VNC server capability there is no need to embed the emulator's existing window. You can just have a GTK/QT widget which acts as a VNC client taking the video feed & displaying directly within the GUI management app. Similarly you can redirect the QEMU monitor console to a UNIX pipe when lauching QEMU, so the management app can fully control the QEMU engine to do suspend/resume, snapshots, media changesi. I wrote an GUI app in Python which did the latter already: http://people.redhat.com/berrange/olpc/sdk/olpc-qemu-admin-demo.html At the time I wrote it there wasn't any VNC support in QEMU, so I couldn't hook up the display, but with the 0.8.1 release it wouldn't be much effort to embed the display directly in the app via VNC. So I don't think there are any changes required in QEMU itself to be able to create a fully featured QEMU frontend easily on a par with VMWare Desktop, if not better. 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] Doing a Tcl/Tk based frontend
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel P. Berrange schrieb: > On Thu, Jun 15, 2006 at 05:52:14PM -0500, John Morris wrote: > >>On Thu, 2006-06-15 at 17:29, Oliver Gerlich wrote: >> >> >>>If you are familiar with Tcl/Tk, maybe you could give some hints on how >>>to embed the Qemu window into such an app? >> >>Embedding the emulator's window might not be the best way to attack the >>problem. Especially since you would need to be able to detach it to be >>able to go full screen. I have pondered the Tk frontend idea before so >>lemme dump my random thoughts on the subject and see how many holes get >>punched in em. > > > With the new VNC server capability there is no need to embed the emulator's > existing window. You can just have a GTK/QT widget which acts as a VNC client > taking the video feed & displaying directly within the GUI management app. > Similarly you can redirect the QEMU monitor console to a UNIX pipe when > lauching QEMU, so the management app can fully control the QEMU engine > to do suspend/resume, snapshots, media changesi. > > I wrote an GUI app in Python which did the latter already: > > http://people.redhat.com/berrange/olpc/sdk/olpc-qemu-admin-demo.html > > At the time I wrote it there wasn't any VNC support in QEMU, so I couldn't > hook up the display, but with the 0.8.1 release it wouldn't be much effort > to embed the display directly in the app via VNC. So I don't think there > are any changes required in QEMU itself to be able to create a fully > featured QEMU frontend easily on a par with VMWare Desktop, if not better. > > Regards. > Dan. VNC is a good idea... But isn't it a bit "laggy" for this purpose? I think people accept a laggy mouse cursor in a VNC window that comes over the network, but won't really accept that in virtual machine that's running directly on their desktop. OTOH, I'm no VNC expert :) and maybe there are tricks to speed this up?! Regards, Oliver -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEke5ATFOM6DcNJ6cRAoRrAKCh1pM+Ig5WTv4ZeoGSvkjtT7M/mACeM1XL iH7ztKK9+HwNsnO5EA0XqBA= =gGkF -END PGP SIGNATURE- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VMware Player
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Johannes Schindelin schrieb: > Hi, > > On Fri, 16 Jun 2006, Oliver Gerlich wrote: > > >>Johannes Schindelin schrieb: >> >>>On Thu, 15 Jun 2006, Joe Lee wrote: >>> >>> BTW, I am curious to know how much would it cost to develop a good GUI-Frontend for QEMU that would be comparable to VMware. How much man hours would this likely take? >>> >>>I do not know VMware. Anybody? I would be interested, too, to know how >>>complicated that frontend is... >> >>There are some screenshots of "VMware Workstation" at >>http://www.vmware.com (see Products menu). Didn't find screenshots of >>"VMware Player" there, but Google image search shows a few for "VMplayer". > > > Thanks. But I would like to know if there is a developer who has > experience with the GUI. It is one thing to see the GUI, another to work > with it. > > >>>Should not be too difficult to reproduce >>>it in Tcl/Tk (with a proper Tcl script as config format). >> >>If you are familiar with Tcl/Tk, maybe you could give some hints on how >>to embed the Qemu window into such an app? > > > I would go the easy way: just before starting QEmu, hide the Tk window... > no need for embedding. > > Yes, I know this is a lame answer. But I am quite certain that most users > would be happy about it. They do not *need* to do something fancy. They > run the virtual machine, shut it down, and that's it. Heh :) that's what the current Qemu GUIs do already (many of which are mainly configuration GUIs). Thinking about it, at this point maybe an "official" configuration file format would be useful for all frontends and would really help unifying the GUIs (there has been a lot of talk about this already anyway). Regards, Oliver -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEke9mTFOM6DcNJ6cRAkLIAKDkkPPgGVR6OHyQ6sD5h71OYO5zYgCgkb6I KzNbrMmbEBuYzPgQ5fck5BA= =e/PC -END PGP SIGNATURE- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Doing a Tcl/Tk based frontend
Daniel P. Berrange wrote: On Thu, Jun 15, 2006 at 05:52:14PM -0500, John Morris wrote: On Thu, 2006-06-15 at 17:29, Oliver Gerlich wrote: If you are familiar with Tcl/Tk, maybe you could give some hints on how to embed the Qemu window into such an app? Embedding the emulator's window might not be the best way to attack the problem. Especially since you would need to be able to detach it to be able to go full screen. I have pondered the Tk frontend idea before so lemme dump my random thoughts on the subject and see how many holes get punched in em. With the new VNC server capability there is no need to embed the emulator's existing window. You can just have a GTK/QT widget which acts as a VNC client taking the video feed & displaying directly within the GUI management app. I definitely think this is the write approach too.I'm still at the proof-of-concept phase those. The VNC client code seems to work well (it's asynchronous and uses glib) but I haven't integrated it into a widget just yet. This is coming straight off my hard drive so YMMV. http://hg.codemonkey.ws/gvnc/ Similarly you can redirect the QEMU monitor console to a UNIX pipe when lauching QEMU, so the management app can fully control the QEMU engine to do suspend/resume, snapshots, media changesi. I wrote an GUI app in Python which did the latter already: http://people.redhat.com/berrange/olpc/sdk/olpc-qemu-admin-demo.html At the time I wrote it there wasn't any VNC support in QEMU, so I couldn't hook up the display, but with the 0.8.1 release it wouldn't be much effort to embed the display directly in the app via VNC. So I don't think there The tricky part is the VNC widget. Reusing any of the existing vnc clients isn't really an option. The client end of the protocol has way too many states making a state machine really nasty. I ended up settling on a coroutine based approach which I'm sure will raise some eyes. Of course, one could easily replace the coroutines with threads though (I just have an aversion to threading. I've also got code laying around for basic software scaling which I also think is important for proper fullscreen support. Just need a little more free time :-) Regards, Anthony Liguori are any changes required in QEMU itself to be able to create a fully featured QEMU frontend easily on a par with VMWare Desktop, if not better. Regards. Dan. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Doing a Tcl/Tk based frontend
Oliver Gerlich wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 VNC is a good idea... But isn't it a bit "laggy" for this purpose? I think people accept a laggy mouse cursor in a VNC window that comes over the network, but won't really accept that in virtual machine that's running directly on their desktop. OTOH, I'm no VNC expert :) and maybe there are tricks to speed this up?! The right way to solve this is emulation of hardware cursor offloading. The problem is that modern desktops like to use colored cursors and the current Cirrus emulation only supports monochromatic cursors :-( Really no way around this without a special guest driver or new VGA emulation. On the other hand, I had toyed with a shared memory based display driver. That would give you more or less equivalent performance. However, I really don't think localhost VNC is that bad. Regards, Anthony Liguori Regards, Oliver -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEke5ATFOM6DcNJ6cRAoRrAKCh1pM+Ig5WTv4ZeoGSvkjtT7M/mACeM1XL iH7ztKK9+HwNsnO5EA0XqBA= =gGkF -END PGP SIGNATURE- ___ 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] Doing a Tcl/Tk based frontend
On Fri, Jun 16, 2006 at 01:33:26AM +0200, Oliver Gerlich wrote: > Daniel P. Berrange schrieb: > > On Thu, Jun 15, 2006 at 05:52:14PM -0500, John Morris wrote: > > With the new VNC server capability there is no need to embed the emulator's > > existing window. You can just have a GTK/QT widget which acts as a VNC > > client > > taking the video feed & displaying directly within the GUI management app. > > Similarly you can redirect the QEMU monitor console to a UNIX pipe when > > lauching QEMU, so the management app can fully control the QEMU engine > > to do suspend/resume, snapshots, media changesi. > > > > I wrote an GUI app in Python which did the latter already: > > > > http://people.redhat.com/berrange/olpc/sdk/olpc-qemu-admin-demo.html > > > > At the time I wrote it there wasn't any VNC support in QEMU, so I couldn't > > hook up the display, but with the 0.8.1 release it wouldn't be much effort > > to embed the display directly in the app via VNC. So I don't think there > > are any changes required in QEMU itself to be able to create a fully > > featured QEMU frontend easily on a par with VMWare Desktop, if not better. > > > > Regards. > > Dan. > > VNC is a good idea... But isn't it a bit "laggy" for this purpose? I > think people accept a laggy mouse cursor in a VNC window that comes over > the network, but won't really accept that in virtual machine that's > running directly on their desktop. OTOH, I'm no VNC expert :) and maybe > there are tricks to speed this up?! There is no performance issue with native VNC on either localhost or a LAN. I know of places where people use a VNC session to a remote Linux desktop for day-to-day software development with no serious performance issues. Basically if your network is reasonably fast then there should be no issues. NB, I'm talking LAN - not WAN / Internet here, so assuming 100mb ethernet. That said its possible that a combination of VNC, and slow emulation of the display adapter within the guest OS could lower performance a bit more, but I'm still fairly optimistic that its usable. In any case slow display adapter emulation would affect the native SDL display mode too. 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] Doing a Tcl/Tk based frontend
Daniel P. Berrange wrote: VNC is a good idea... But isn't it a bit "laggy" for this purpose? I think people accept a laggy mouse cursor in a VNC window that comes over the network, but won't really accept that in virtual machine that's running directly on their desktop. OTOH, I'm no VNC expert :) and maybe there are tricks to speed this up?! There is no performance issue with native VNC on either localhost or a LAN. That's not quite true. I did quite a bit of benchmarking with VNC localhost. I figure the best case scenario is raw encoding. Even with my very optimized client, there is a slight latency and more importantly, a non trivial CPU overhead (~5%) Basically, if you can't see the host cursor, you can't notice the cursor latency. The CPU overhead only adds a trivial amount of time when qemu is CPU bound. Certainly acceptable IMHO. I'm 100% it's the right approach to take. Regards, Anthony Liguori I know of places where people use a VNC session to a remote Linux desktop for day-to-day software development with no serious performance issues. Basically if your network is reasonably fast then there should be no issues. NB, I'm talking LAN - not WAN / Internet here, so assuming 100mb ethernet. That said its possible that a combination of VNC, and slow emulation of the display adapter within the guest OS could lower performance a bit more, but I'm still fairly optimistic that its usable. In any case slow display adapter emulation would affect the native SDL display mode too. Dan ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VMware Player
QEMU leaves me with very few 'itches to be scratched' ... The basic tasks that a QUI should confine itself to, IMO, are already pretty darn easy - define/manage a VM (via a shell script for me), start it, stop it, pause it...etc.. Even so, I've been thinking about this for some time - months probably... What I'd develop, if I were to undertake such a task, is a very simple app that can start qemu according to some configuration, and simply hook into the monitor to issue such commands as sendkey, stop, cont ...etc ... I do not imagine a need to have this app embed the qemu VM in itself, only start it & hook into the monitor. Besides, I don't want to loose precious real estate - I like the window that a running VM is in just how it is - no changes. I've used VMWare in the past a lot. I found the toolbars & menus to be nothing more than clutter & annoyance. The majority of the work I do with a VM has everything to do with the VM, and nothing to do with things that can be done with an additional GUI, however it would be nice to have one for simplifying those extra tasks... Specifically, I imagine something sitting in my Sys. Tray. This Sys. Tray icon menu thing would have options to invoke qemu's monitor commands for easy access ...or a list of all VMs, each with a sub-menu (I'm thinking stop, cont, loadvm, savevm, commit, usb stuff, change device x). Also, I can use the Sys. Tray Icon to bring up it's window with all the niceties to create a new VM, manage existing VMs...etc. Right now, I have a shell script that has the 'configuration' of my VM - changing of that 'configuration' would need to go in the GUI. I also use the monitor thing for stop, cont, loadvm, startvm, commit, usb stuff & change device x - that would need to go in the GUI. Beyond that, what does more bling really bring to the table? On Thursday 15 June 2006 16:03, Joe Lee wrote: > Johannes Schindelin wrote: > > Hi, > > > > On Thu, 15 Jun 2006, Joe Lee wrote: > >> BTW, I am curious to know how much would it cost to develop a good > >> GUI-Frontend for QEMU that would be comparable to VMware. How much man > >> hours would this likely take? > > > > I do not know VMware. Anybody? I would be interested, too, to know how > > complicated that frontend is... Should not be too difficult to reproduce > > it in Tcl/Tk (with a proper Tcl script as config format). > > > > Ciao, > > Dscho > > I am hoping some experience developers would comment on this! > Joe > > > ___ > 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] VMware Player
Rick Vernam wrote: QEMU leaves me with very few 'itches to be scratched' ... The basic tasks that a QUI should confine itself to, IMO, are already pretty darn easy - define/manage a VM (via a shell script for me), start it, stop it, pause it...etc.. Even so, I've been thinking about this for some time - months probably... What I'd develop, if I were to undertake such a task, is a very simple app that can start qemu according to some configuration, and simply hook into the monitor to issue such commands as sendkey, stop, cont ...etc ... I do not imagine a need to have this app embed the qemu VM in itself, only start it & hook into the monitor. Besides, I don't want to loose precious real estate - I like the window that a running VM is in just how it is - no changes. I've used VMWare in the past a lot. I found the toolbars & menus to be nothing more than clutter & annoyance. The majority of the work I do with a VM has everything to do with the VM, and nothing to do with things that can be done with an additional GUI, however it would be nice to have one for simplifying those extra tasks... Specifically, I imagine something sitting in my Sys. Tray. This Sys. Tray icon menu thing would have options to invoke qemu's monitor commands for easy access ...or a list of all VMs, each with a sub-menu (I'm thinking stop, cont, loadvm, savevm, commit, usb stuff, change device x). Also, I can use the Sys. Tray Icon to bring up it's window with all the niceties to create a new VM, manage existing VMs...etc. Right now, I have a shell script that has the 'configuration' of my VM - changing of that 'configuration' would need to go in the GUI. I also use the monitor thing for stop, cont, loadvm, startvm, commit, usb stuff & change device x - that would need to go in the GUI. Beyond that, what does more bling really bring to the table? On Thursday 15 June 2006 16:03, Joe Lee wrote: Johannes Schindelin wrote: Hi, On Thu, 15 Jun 2006, Joe Lee wrote: BTW, I am curious to know how much would it cost to develop a good GUI-Frontend for QEMU that would be comparable to VMware. How much man hours would this likely take? I do not know VMware. Anybody? I would be interested, too, to know how complicated that frontend is... Should not be too difficult to reproduce it in Tcl/Tk (with a proper Tcl script as config format). Ciao, Dscho I am hoping some experience developers would comment on this! Joe ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel I glad to see many people sharing comments and making suggestions since this thread topic started. I seems there enough interest to have a GUI-Frontend for QEMU. I am hopeful this can lead to getting something started. I'd like to see a poll from people who would be willing to participate and contribute to getting something started. -joe ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VMware Player
On Thursday 15 June 2006 23:31, Joe Lee wrote: > I glad to see many people sharing comments and making suggestions since > this thread topic started. I seems there enough interest to have a > GUI-Frontend for QEMU. I am hopeful this can lead to getting something > started. > > I'd like to see a poll from people who would be willing to participate > and contribute to getting something started. > > -joe I'd absolutely love to. Although I have no experience with Qt, GTk, Tcl/Tk ...etc (only win32 GUI stuff, which I haven't done in years). Nor do I know anything about qemu internals... :-) ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VMware Player
On Thu, 2006-06-15 at 09:18, Joe Lee wrote: > I appreciate the effort that some are making to develop a GUI for QEMU - > There's a few project I see that trying to achieve this. But, I wish > they all could come together and work together to develop a nice GUI. I > would like to see a sub-project exist in the QEMU site so all can come > and contribute to that effort. Geez, why not ask for world peace while you are at it. One GUI? So which toolkit? Pick Gtk and watch the K folk whine. Ok, so KDE it is. Oops, now the Gnomes are all over ya. And of course since I suspect a non-trivial percentage of QEMU users are on Windows, Solaris, etc. they ain't gonna like either of those choices much. Face it, putting a GUI on something like QEMU is going to require at least a one per desktop/platform effort. And that can best be kept with the GNOME/KDE/etc software repositories because they require constant updating on the schedule of the rest of the desktop environment to stay current. Think of it like mkisofs/cdrecord/growisofs/cdrdao vs the abundance of graphical front ends that all make use of them. Nobody has to totally reinvent the wheel because those solid CLI only parts can be reused by each project and each graphical environment gets a totally native (ok, several) GUI CD/DVD authoring/burning program instead of one crappy ported program. -- John M. http://www.beau.org/~jmorris This post is 100% M$Free! Geekcode 3.1:GCS C+++ UL$ P++ L+++ W++ w--- Y++ b++ 5+++ R tv- e* r ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VMware Player
John Morris wrote: On Thu, 2006-06-15 at 09:18, Joe Lee wrote: I appreciate the effort that some are making to develop a GUI for QEMU - There's a few project I see that trying to achieve this. But, I wish they all could come together and work together to develop a nice GUI. I would like to see a sub-project exist in the QEMU site so all can come and contribute to that effort. Geez, why not ask for world peace while you are at it. One GUI? So which toolkit? Pick Gtk and watch the K folk whine. Ok, so KDE it is. Oops, now the Gnomes are all over ya. And of course since I suspect a non-trivial percentage of QEMU users are on Windows, Solaris, etc. they ain't gonna like either of those choices much. Face it, putting a GUI on something like QEMU is going to require at least a one per desktop/platform effort. And that can best be kept with the GNOME/KDE/etc software repositories because they require constant updating on the schedule of the rest of the desktop environment to stay current. Think of it like mkisofs/cdrecord/growisofs/cdrdao vs the abundance of graphical front ends that all make use of them. Nobody has to totally reinvent the wheel because those solid CLI only parts can be reused by each project and each graphical environment gets a totally native (ok, several) GUI CD/DVD authoring/burning program instead of one crappy ported program. That may not be true - I'm not sure but I think something reasonable could be done in Java. There is certainly a Java VNC client available which could play a part. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
