Re: [Qemu-devel] [PATCH v3] ui/cocoa.m: Add Mount image file menu item

[Programmingkid]

On Sep 28, 2015, at 4:09 PM, Markus Armbruster wrote:

> Programmingkid <address@hidden> writes:
> 
>> On Sep 25, 2015, at 11:42 AM, Markus Armbruster wrote:
>> 
>>> Programmingkid <address@hidden> writes:
>>> 
>>>> On Sep 24, 2015, at 2:57 AM, Markus Armbruster wrote:
>>>> 
>>>>> Programmingkid <address@hidden> writes:
>>>>> 
>>>>>> On Sep 23, 2015, at 4:35 PM, Peter Maydell wrote:
>>>>>> 
>>>>>>> On 17 September 2015 at 21:17, Programmingkid
>>>>>>> <address@hidden> 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 <address@hidden>
>>>>>>> 
>>>>>>> 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.