On Aug 29, 2015, at 3:34 PM, Max Reitz wrote: > On 29.08.2015 20:34, MagicCat Software wrote: >> >> On Aug 29, 2015, at 2:01 PM, Max Reitz wrote: >> >>> On 29.08.2015 19:36, Programmingkid wrote: >>>> >>>> On Aug 29, 2015, at 12:39 PM, Max Reitz wrote: > > [snip] > >>>> If making QEMU more user-friendly is a crime, I plead guilty! >>> >>> Yes, in some people's eyes it is a crime because they say qemu should >>> rather be machine-friendly. >> >> These people have the mentality of terminator robots. > > Just want to add that by "machine-friendly" I meant "friendly to an > upper management layer who will be really, really nice to the user". > >>> User-friendliness is always expensive, >>> difficult to maintain, and a neverending source of complaints. >> >> Really? It has been months since Peter Maydell implemented my GUI patches >> for the cocoa interface, and I haven't seen a complaint about it yet. > > By definition, a user interface is something the user interacts with. > People are prone to complain about things they interact with which > aren't to their exact liking.
But that doesn't mean we just give up. I think this means we should challenge ourselves to be better. > > What I mean to say is that humans are more complex than machines. It's > much more difficult to please a human than to please libvirt. I guess. > >> >>> So while it is always a nice thing to have, it comes at a hefty price. >> >> If programmers follow good programming practices, the code should be >> pretty much maintenance free. > > [citation needed] > >> But I do understand that public API's do >> change over time. >> >>> >>>> I'm not a Linux user. I am a proud Macintosh user. We Mac users >>>> like our software easy to use. I know this goes against the Linux >>>> way of life. That is why this patch would only work on Mac OS X. >>>> This will keep QEMU on Linux hard to use... just the way you guys >>>> like it. >>> >>> Erm, well, I think I won't reply to that other than *cough* virt-manager >>> *cough*. >> >> Linux exclusive probably. > > Your point? > > You said applications on Linux are generally more difficult to use than > comparable applications on OS X, by design. I said "Well, there's > virt-manager." You say it's available only on Linux. So how does that > make qemu on Linux more difficult to use than on OS X? It doesn't make QEMU more difficult to use on Linux. I was just saying this virt-manager sounds like a good program to have, but isn't available to Mac OS X users. > >>>>>> Mac OS X users don't have all the fancy GUI wrappers >>>>>> for QEMU :( >>>>> >>>>> Good thing most GNU/Linux distributions are free. ;-) >>>>> >>>>> (sorry, could not resist) >>>> >>>> ....lolz >>>> >>>> But on the other hand, you get what you pay for. >>> >>> Working qemu/KVM with a nice management layer on top of it? >> >> Linux has a few advantages. > > Which don't really matter here, because this thread should really not be > about which OS is better (which is a rather pointless question and even > more so on the qemu mailing list). > > The point why I brought up libvirt and virt-manager is simply that those > tools do exactly what you want qemu to do. The ratio of how much GUI > work we do and how much work we do to have qemu interact nicely with > libvirt shows to me very clearly that our current direction is to > separate the frontend (libvirt + GUI) from the backend (qemu). This philosophy doesn't have to be universal. There might be Linux users who don't want to use virt-manager but who still want a nice GUI to use. Lets give the user the power to decide what GUI to use. > > It's a pity that libvirt is not available for OS X, but in my humble > opinion that's libvirt's fault and not qemu's. Putting features into > qemu we apparently decided to leave to libvirt and any management > application on top of it doesn't seem quite right. It doesn't seem quite right to the GTK-Linux people, but it perfectly ok with the cocoa-Macintosh people. Who wouldn't like the idea of making QEMU more user-friendly. Right now in order to move files between guest and host, the user has to depend on using an image file as a hard drive. That means shutting down and restarting the guest a lot. Not fun. The feature I propose would make rebooting the guest a thing of the past. QEMU would be a lot more robust. > > [snip] > >>>> Ideally I want QEMU's GUI to be similar to VirtualBox's GUI. Doing stuff >>>> like >>>> freezing and restoring a session would be awesome and a real time saver. >>> >>> Might be trivially possible with the things I described, since there is >>> HMP's savevm/loadvm. >> >> It is just a few patches away from working well. >> >>> On the other hand, I don't think you'll find (m)any friends for making >>> qemu's GUI as feature-rich as VBox's. There have long been >>> "non-invasive" GUIs for managing qemu VMs (such as qtemu), so this isn't >>> some recent development. >> >> Probably true. >> >>> >>> Maybe I can get you interested in writing a management application for >>> OS X? I do not think that would be more difficult than plugging these >>> features directly into qemu, and I think everyone would like that idea. >>> As an OS X user, there shouldn't be any visible difference; and all >>> non-OS-X users would not have any reason to complain. >> >> Part of making QEMU easier for the user is not having to install more >> software. >> If everything came with in one package, that would be a blessing. > > I don't know how installing software works under OS X, but as far as I > can recall, it was pretty similar to most Linux distributions in that > there are package managers. So you'd install the frontend your heart > desires and it'd pull in qemu as a dependency. Sometimes package > managers support optional dependencies, too. So one of qemu's optional > dependencies might be your frontend. Alternatively, your frontend could > just be part of the qemu package. Installing software on Mac OS X is done by simply using a .dmg file and the default installer application. The user just pushes the install button and that's it. > > Other than that, the difficulty of having to install two packages > instead of one doesn't quite strike me as a good argument. Less stuff to have to install means less of a headache for the user. > >>> Because, as much as you may think this is worthless to hear, what you >>> are describing is exactly what virt-manager offers. >> >> Maybe someone might port Virt-manager to other platforms. Shouldn't be too >> difficult. It probably uses multi-platform libraries like GTK. > > The thing is that it works on top of libvirt. Oh. Then it would be harder to port Virt-manager.
