Programmingkid <programmingk...@gmail.com> writes: > On Aug 31, 2015, at 3:52 AM, Markus Armbruster wrote: > >> Programmingkid <magiccatsoftw...@gmail.com> writes: >> >>> On Aug 29, 2015, at 12:39 PM, Max Reitz wrote: >>> >>>> On 29.08.2015 17:57, Programmingkid wrote: >>>>> >>>>> On Aug 29, 2015, at 11:40 AM, Max Reitz wrote: >>>>> >>>>>> On 27.08.2015 03:05, G 3 wrote: >>>>>>> I want to share files between my host and guest computer. A feature I >>>>>>> want to add would be a new menu item in the Machine menu called "Mount >>>>>>> Image File...". When the user selects it, a file open dialog box >>>>>>> displays. The user can then select the image file with the file he wants >>>>>>> to use. After pushing the OK button, the image file would be mounted >>>>>>> like a USB flash drive. This menu item would only show up if there is >>>>>>> usb support in the guest machine. >>>>>>> >>>>>>> Would you be open to accepting such a feature? >>>>>> >>>>>> Generally I'd expect this to be functionality exposed by the management >>>>>> layer. For instance using virt-manager, this can be achived as follows: >>>>>> Switch to "Details", then click "Add Hardware", choose "Storage" and >>>>>> "USB" as the "Bus type". Choose the image, click "Finish", done. >>>>> >>>>> Isn't Libvirt only available on Linux? This mount image file feature would >>>>> only be on Mac OS X. >>>> >>>> I'm not sure whether that sounds like a good idea, because then people >>>> using bare qemu on Linux would complain that it isn't available with >>>> Gtk. So if this was to be implemented, it would have to implemented >>>> cross-platform (or at least in a way so it can be used cross-platform >>>> later on). >>> >>> If making QEMU more user-friendly is a crime, I plead guilty! >>> >>> 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. >> >> I think you've used up your "speculation on what Linux users like" quota >> on this list for 2015. Now let's get back on topic. >> >> [More snipped...] >> >>>>>> The main problem I see with adding this functionality to qemu itself >>>>>> would be having to get even further into the GUI business, which hasn't >>>>>> worked out too well so far… >>>>> >>>>> That is because of several reasons. One being maintainers not wanting to >>>>> advance the GUI because they feel another program should be QEMU's >>>>> GUI. I'm sure there are plenty of good ideas that would advance QEMU's >>>>> GUI. These ideas just need to be accepted into QEMU rather than put off. >>>> >>>> Another is that some people simply feel that qemu should focus on being >>>> a backend than having to mess with frontend work, too. See the recent >>>> discussion on the Gtk code setting the locale and thus breaking QMP for >>>> an example why they have a point. >>> >>> We can have both. Command-line options are there that can turn on or >>> off the GUI. >>> Example: --disable-gtk. >>> >>> 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. >>> >>>> I guess you'll better talk to Markus about this. :-) >>>> >>>> Quote: "We should've stayed out of the GUI business." >>>> >>>> (http://lists.nongnu.org/archive/html/qemu-devel/2015-08/msg03049.html) >>> >>> That is totally fine for the Linux users. If they want to use the >>> command-line only, >>> let them. They are only hurting themselves :) >> >> You're attacking a strawman. > > I think the word attack is a little strong. We were just having a > little informal > conversation.
We're having a technical argument. Such arguments can occasionally get a little heated, but that's fine, we don't mean each other harm :) > Sorry if the Linux jokes weren't so funny. No offense taken. >> Nobody is arguing against having a nice >> GUI. My argument is that one application trying to do everything tends >> to result in the application doing most of it badly. > > That's what you believe? Are you saying if we do add a few features to the GUI > it automatically becomes bad? Isn't that kind of pessimistic? Is all hope > gone? I think we QEMU developers have our hands full with our core mission, and saddling ourselves with GUI development on top risks failure. You're welcome to prove me wrong. > Running Virt-manager on Mac OS X isn't currently possible. So my only > choice is to advance > the GUI. Very rarely something is your only choice. You could work on libvirt and virt-manager under Mac OS X. A quick grep shows #ifdef __APPLE__ in libvirt sources, which suggests it already runs there. You could write your own GUI layered on top of QEMU. > This feature would making transferring files from and to the > guest actually easy > to do. That sounds like a good idea. Plumbing for easy file sharing is part of our core job. I think Max pointed you to the work being done by Stefan (NFS over AF_VSOCK). A less capable, but more portable alternative could be USB MTP. > This patch would only affect Mac > OS X users, so Linux > users won't notice a difference. No harm done to them. There's always the opportunity cost.
