On Aug 29, 2015, at 3:52 PM, Max Reitz wrote: > On 29.08.2015 20:34, MagicCat Software wrote: >> >> On Aug 29, 2015, at 2:01 PM, Max Reitz wrote: > > [snip] > >>> 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. > > I just looked into it, and without having an OS X to test it on I have a > few things to complain about: > > (1) 'change' always uses 'raw' as the format, but the selector > apparently offers you the full range of image formats > (supportedImageFileTypes).
So far it has worked out just fine. Doesn't QEMU detect the format itself? If I didn't use raw, what would I use? Is the file extension also the format type? > (2) I think it should be possible to add block devices with removable > media at runtime (I didn't try, though), and also remove them. The > current code doesn't account for that. I think block devices should be used also. I use to have a menu item called "Use real CDROM" in the machine menu. I will bring it back soon. QEMU booting up a real hard drive partition? Definitely! > (3) supportedImageFileTypes is static. The list might change at any time > and the likelihood of people adding or removing formats there when > adding/removing them to/from the block layer itself is pretty low. Also, > the list depends on compile and (in the future at least) maybe even > runtime options. For instance, it's missing vdi, vhd (vpc), and vhdx. > vhdx in turn can be disabled at compile time. I have no problem adding these missing file types. > > (4) NSBeep()? Is that necessary? Won't the alert itself be audible if so > desired by the user? Well, alert boxes don't make a sound when they show up. I just wanted to make sure I caught the user's attention. To answer your question, we don't need NSBeep().
