On Aug 31, 2015, at 12:26 PM, Markus Armbruster wrote: > 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.
I honestly don't know very much about this libvirt, but it will take a lot of work and effort to make it run on Mac OS X. > >> 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. I was told about this feature. Someone said it wouldn't work on Mac OS X. > >> 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.
