On Sep 28, 2015, at 4:09 PM, Markus Armbruster wrote: > Programmingkid <programmingk...@gmail.com> writes: > >> On Sep 25, 2015, at 11:42 AM, Markus Armbruster wrote: >> >>> Programmingkid <programmingk...@gmail.com> writes: >>> >>>> On Sep 24, 2015, at 2:57 AM, Markus Armbruster wrote: >>>> >>>>> Programmingkid <programmingk...@gmail.com> writes: >>>>> >>>>>> On Sep 23, 2015, at 4:35 PM, Peter Maydell wrote: >>>>>> >>>>>>> On 17 September 2015 at 21:17, Programmingkid >>>>>>> <programmingk...@gmail.com> wrote: >>>>>>>> Add "Mount Image File..." and a "Eject Image File" menu items to >>>>>>>> cocoa interface. This patch makes sharing files between the >>>>>>>> host and the guest user-friendly. >>>>>>>> >>>>>>>> The "Mount Image File..." menu item displays a dialog box having the >>>>>>>> user pick an image file to use in QEMU. The image file is setup as >>>>>>>> a USB flash drive. The user can do the equivalent of removing the >>>>>>>> flash drive by selecting the file in the "Eject Image File" submenu. >>>>>>>> >>>>>>>> Signed-off-by: John Arbuckle <programmingk...@gmail.com> >>>>>>> >>>>>>> I've thought a bit about this, and I really don't think this sort >>>>>>> of feature should be part of QEMU itself. Our general design for >>>>>>> how QEMU does this sort of thing is that an external program >>>>>>> (virt-manager, for instance) is responsible for providing most >>>>>>> of the UI conveniences the user wants, and QEMU's "ui" code is >>>>>>> a fairly simple minimum-functionality affair. I agree with Markus >>>>>>> that this separation of concerns has generally worked OK for us. >>>>>>> >>>>>>> I don't think OSX should be an exception to this design model: >>>>>>> (a) being an odd special case is never a good idea >>>>>>> (b) as a practical matter, I'm the only person who really reviews >>>>>>> OSX patches, and I don't have either the time nor the UI or OSX >>>>>>> expertise to deal with maintaining what will effectively be a >>>>>>> vm-manager grafted onto the side of QEMU >>>>>>> >>>>>>> So I think your efforts would be better spent in either porting >>>>>>> one of the Linux frontends like libvirt/virt-manager, or in >>>>>>> writing a custom OSX specific frontend. >>>>>> >>>>>> I understand that time is precious. It is one of those things >>>>>> that we only have a finite amount of. Every user can agree >>>>>> to that. This patch was pretty hairy looking with the QDict >>>>>> and other unfamiliar code. With that said I'm not ready to >>>>>> give up on this patch. It is a huge time saver for the user. >>>>>> Without it, the user would need to spend a lot of time >>>>>> investigating documentation. What's worse is the user >>>>>> would have to type out full paths to files they need. This >>>>>> would definitely be error prone and frustrating. >>>>> >>>>> Nobody is challenging the idea that many users appreciate a GUI. >>>>> >>>>> What we've been trying to tell you is where in this software layer cake >>>>> the GUI should be. In Peter's words, "our general design for how QEMU >>>>> does this sort of thing is that an external program (virt-manager, for >>>>> instance) is responsible for providing most of the UI conveniences". >>>> >>>> That is easy for you to say. Linux already has virt-manager. Mac OS >>>> X doesn't. >>>> Expecting someone to just go and port another program to Mac OS X is >>>> unreasonable. The amount of time and energy it would take to do so >>>> would make it hard. >>> >>> On the purely technical level, it may or may not be harder than mashing >>> everything into QEMU. >>> >>> On the getting-patches-merged level, mashing everything into QEMU is a >>> non-starter, as Peter and I have told you multiple times. >>> >>> That tips the balance somewhat. >>> >>>>>> This patch can definitely be more simplified. QMP >>>>>> commands could be used in place of C functions. >>>>>> This would reduce the patch size greatly. >>>>> >>>>> You're quite welcome to use QMP the way it wants to be used: as an >>>>> external interface. >>>>> >>>>> Abusing it as internal interface won't fly. >>>> >>>> The QMP interface is primarily there to help a gui interact with QEMU. That >>>> is what I intend to use it for. >>> >>> Nope, the QMP interface's purpose is to let other programs interact with >>> QEMU. >>> >>> You're free to use it for other purposes to your heart's content. Just >>> don't count on patches to be merged when they do things maintainers have >>> told you not to do :) >> >> I did do as you said and used C functions in place of the original hmp >> commands. > > Yes, you did, to address my hard objections there. A hard objection is > about a technical issue in my area of expertise, and especially the > areas I maintain. Unaddressed hard objections NAK patches. > > I also have opinions on matters outside the areas I maintain, like > whether we should be in the GUI business, but mere opinions don't NAK > patches.
Are you against the GTK interface that works on Linux? > >> I guess there never was any hope for this patch. :( > > Getting a patch rejected isn't a pleasant experience. Would you like to > see my collection of rejected patches? No thank you.
