| Message ID | E4DF3C32-9FE0-42F6-B99F-2273D06AF966@gmail.com |
|---|---|
| State | New |
| Headers | show |
On Sep 10, 2015, at 8:49 PM, Programmingkid wrote: > Remove the open dialog code that runs when no arguments are supplied with QEMU. > Not everyone needs a hard drive or cdrom to boot their target. A user might only > need to use their target's bios to do work. With that said, this patch removes > the unneeded open dialog code. > > Signed-off-by: John Arbuckle <programmingkidx@gmail.com> > > --- > ui/cocoa.m | 56 ++------------------------------------------------------ > 1 files changed, 2 insertions(+), 54 deletions(-) > > diff --git a/ui/cocoa.m b/ui/cocoa.m > index 334e6f6..1dc9bc6 100644 > --- a/ui/cocoa.m > +++ b/ui/cocoa.m > @@ -814,7 +814,6 @@ QemuCocoaView *cocoaView; > { > } > - (void)startEmulationWithArgc:(int)argc argv:(char**)argv; > -- (void)openPanelDidEnd:(NSOpenPanel *)sheet returnCode:(NSInteger)returnCode contextInfo:(void *)contextInfo; > - (void)doToggleFullScreen:(id)sender; > - (void)toggleFullScreen:(id)sender; > - (void)showQEMUDoc:(id)sender; > @@ -895,29 +894,8 @@ QemuCocoaView *cocoaView; > - (void)applicationDidFinishLaunching: (NSNotification *) note > { > COCOA_DEBUG("QemuCocoaAppController: applicationDidFinishLaunching\n"); > - > - // Display an open dialog box if no arguments were passed or > - // if qemu was launched from the finder ( the Finder passes "-psn" ) > - if( gArgc <= 1 || strncmp ((char *)gArgv[1], "-psn", 4) == 0) { > - NSOpenPanel *op = [[NSOpenPanel alloc] init]; > - [op setPrompt:@"Boot image"]; > - [op setMessage:@"Select the disk image you want to boot.\n\nHit the \"Cancel\" button to quit"]; > -#if (MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_6) > - [op setAllowedFileTypes:supportedImageFileTypes]; > - [op beginSheetModalForWindow:normalWindow > - completionHandler:^(NSInteger returnCode) > - { [self openPanelDidEnd:op > - returnCode:returnCode contextInfo:NULL ]; } ]; > -#else > - // Compatibility code for pre-10.6, using deprecated method > - [op beginSheetForDirectory:nil file:nil types:filetypes > - modalForWindow:normalWindow modalDelegate:self > - didEndSelector:@selector(openPanelDidEnd:returnCode:contextInfo:) contextInfo:NULL]; > -#endif > - } else { > - // or launch QEMU, with the global args > - [self startEmulationWithArgc:gArgc argv:(char **)gArgv]; > - } > + // launch QEMU, with the global args > + [self startEmulationWithArgc:gArgc argv:(char **)gArgv]; > } > > - (void)applicationWillTerminate:(NSNotification *)aNotification > @@ -942,36 +920,6 @@ QemuCocoaView *cocoaView; > exit(status); > } > > -- (void)openPanelDidEnd:(NSOpenPanel *)sheet returnCode:(NSInteger)returnCode contextInfo:(void *)contextInfo > -{ > - COCOA_DEBUG("QemuCocoaAppController: openPanelDidEnd\n"); > - > - /* The NSFileHandlingPanelOKButton/NSFileHandlingPanelCancelButton values for > - * returnCode strictly only apply for the 10.6-and-up beginSheetModalForWindow > - * API. For the legacy pre-10.6 beginSheetForDirectory API they are NSOKButton > - * and NSCancelButton. However conveniently the values are the same. > - * We use the non-legacy names because the others are deprecated in OSX 10.10. > - */ > - if (returnCode == NSFileHandlingPanelCancelButton) { > - exit(0); > - } else if (returnCode == NSFileHandlingPanelOKButton) { > - char *img = (char*)[ [ [ sheet URL ] path ] cStringUsingEncoding:NSASCIIStringEncoding]; > - > - char **argv = g_new(char *, 4); > - > - [sheet close]; > - > - argv[0] = g_strdup(gArgv[0]); > - argv[1] = g_strdup("-hda"); > - argv[2] = g_strdup(img); > - argv[3] = NULL; > - > - // printf("Using argc %d argv %s -hda %s\n", 3, gArgv[0], img); > - > - [self startEmulationWithArgc:3 argv:(char**)argv]; > - } > -} > - > /* We abstract the method called by the Enter Fullscreen menu item > * because Mac OS 10.7 and higher disables it. This is because of the > * menu item's old selector's name toggleFullScreen: > -- > 1.7.5.4 > Forgot to add that this patch also removes code that was incompatible with gcc 4.9.
On 11 September 2015 at 01:49, Programmingkid <programmingkidx@gmail.com> wrote: > Remove the open dialog code that runs when no arguments are supplied with > QEMU. > Not everyone needs a hard drive or cdrom to boot their target. A user might > only > need to use their target's bios to do work. With that said, this patch > removes > the unneeded open dialog code. > > Signed-off-by: John Arbuckle <programmingkidx@gmail.com> I admit to not being much of a fan of this feature of the Cocoa UI, but it has been in QEMU's OSX UI since 2005. In particular, if you remove it then double-clicking to start QEMU from the Finder won't do anything useful, and you now have to start it from the command line. I agree that it does somewhat assume the x86-centric "just provide a disk image" semantics, but it's not clear to me that the most appropriate way to deal with this is to just rip the dialog box code out entirely. thanks -- PMM
Oops, I meant to cc Andreas on this but got the address wrong. -- PMM On 14 September 2015 at 16:43, Peter Maydell <peter.maydell@linaro.org> wrote: > On 11 September 2015 at 01:49, Programmingkid <programmingkidx@gmail.com> wrote: >> Remove the open dialog code that runs when no arguments are supplied with >> QEMU. >> Not everyone needs a hard drive or cdrom to boot their target. A user might >> only >> need to use their target's bios to do work. With that said, this patch >> removes >> the unneeded open dialog code. >> >> Signed-off-by: John Arbuckle <programmingkidx@gmail.com> > > I admit to not being much of a fan of this feature of the > Cocoa UI, but it has been in QEMU's OSX UI since 2005. > In particular, if you remove it then double-clicking to > start QEMU from the Finder won't do anything useful, and > you now have to start it from the command line. > > I agree that it does somewhat assume the x86-centric > "just provide a disk image" semantics, but it's not clear > to me that the most appropriate way to deal with this is > to just rip the dialog box code out entirely. > > thanks > -- PMM
On Sep 14, 2015, at 11:49 AM, Peter Maydell wrote: > Oops, I meant to cc Andreas on this but got the address wrong. > > -- PMM > > On 14 September 2015 at 16:43, Peter Maydell <peter.maydell@linaro.org> wrote: >> On 11 September 2015 at 01:49, Programmingkid <programmingkidx@gmail.com> wrote: >>> Remove the open dialog code that runs when no arguments are supplied with >>> QEMU. >>> Not everyone needs a hard drive or cdrom to boot their target. A user might >>> only >>> need to use their target's bios to do work. With that said, this patch >>> removes >>> the unneeded open dialog code. >>> >>> Signed-off-by: John Arbuckle <programmingkidx@gmail.com> >> >> I admit to not being much of a fan of this feature of the >> Cocoa UI, but it has been in QEMU's OSX UI since 2005. QEMU supported Mac OS 10.3 since that time, but that wasn't enough of a reason to keep supporting it. >> In particular, if you remove it then double-clicking to >> start QEMU from the Finder won't do anything useful, and >> you now have to start it from the command line. What if the user finds working with OpenBIOS useful? What if the target doesn't support a hard drive? The automatic open dialog feature does get in my way when I am working with OpenBIOS. >> I agree that it does somewhat assume the x86-centric >> "just provide a disk image" semantics, but it's not clear >> to me that the most appropriate way to deal with this is >> to just rip the dialog box code out entirely. This code is from a time when the x86 target was the only thing people paid attention to. If the user forgets to supply any arguments to QEMU, he can always just quit QEMU and start again with arguments. My configuration selection feature did solve this problem by allowing the user to load a file with QEMU's arguments inside of it.
On Sep 14, 2015, at 11:43 AM, Peter Maydell wrote: > On 11 September 2015 at 01:49, Programmingkid <programmingkidx@gmail.com> wrote: >> Remove the open dialog code that runs when no arguments are supplied with >> QEMU. >> Not everyone needs a hard drive or cdrom to boot their target. A user might >> only >> need to use their target's bios to do work. With that said, this patch >> removes >> the unneeded open dialog code. >> >> Signed-off-by: John Arbuckle <programmingkidx@gmail.com> > > I admit to not being much of a fan of this feature of the > Cocoa UI, but it has been in QEMU's OSX UI since 2005. > In particular, if you remove it then double-clicking to > start QEMU from the Finder won't do anything useful, and > you now have to start it from the command line. > > I agree that it does somewhat assume the x86-centric > "just provide a disk image" semantics, but it's not clear > to me that the most appropriate way to deal with this is > to just rip the dialog box code out entirely. What does QEMU do when it is launched under Linux with no arguments supplied? If you decide to keep the code, could it be fixed so that it compiles under GCC 4.9?
On 14 September 2015 at 17:12, Programmingkid <programmingkidx@gmail.com> wrote: > > On Sep 14, 2015, at 11:49 AM, Peter Maydell wrote: > >> Oops, I meant to cc Andreas on this but got the address wrong. >> >> -- PMM >> >> On 14 September 2015 at 16:43, Peter Maydell <peter.maydell@linaro.org> wrote: >>> On 11 September 2015 at 01:49, Programmingkid <programmingkidx@gmail.com> wrote: >>>> Remove the open dialog code that runs when no arguments are supplied with >>>> QEMU. >>>> Not everyone needs a hard drive or cdrom to boot their target. A user might >>>> only >>>> need to use their target's bios to do work. With that said, this patch >>>> removes >>>> the unneeded open dialog code. >>>> >>>> Signed-off-by: John Arbuckle <programmingkidx@gmail.com> >>> >>> I admit to not being much of a fan of this feature of the >>> Cocoa UI, but it has been in QEMU's OSX UI since 2005. > > QEMU supported Mac OS 10.3 since that time, but that wasn't enough of a > reason to keep supporting it. > >>> In particular, if you remove it then double-clicking to >>> start QEMU from the Finder won't do anything useful, and >>> you now have to start it from the command line. > > What if the user finds working with OpenBIOS useful? > What if the target doesn't support a hard drive? > The automatic open dialog feature does get in my way when I > am working with OpenBIOS. > >>> I agree that it does somewhat assume the x86-centric >>> "just provide a disk image" semantics, but it's not clear >>> to me that the most appropriate way to deal with this is >>> to just rip the dialog box code out entirely. > > This code is from a time when the x86 target was the only thing people paid > attention to. If the user forgets to supply any arguments to QEMU, he can > always just quit QEMU and start again with arguments. By the way, I don't mean that I'm completely opposed to the idea of dropping the open-dialog. I'd just like to hear some input from other people who care about OSX QEMU rather than just you and me. thanks -- PMM
On Sep 19, 2015, at 10:58 AM, Peter Maydell wrote: > On 14 September 2015 at 17:12, Programmingkid <programmingkidx@gmail.com> wrote: >> >> On Sep 14, 2015, at 11:49 AM, Peter Maydell wrote: >> >>> Oops, I meant to cc Andreas on this but got the address wrong. >>> >>> -- PMM >>> >>> On 14 September 2015 at 16:43, Peter Maydell <peter.maydell@linaro.org> wrote: >>>> On 11 September 2015 at 01:49, Programmingkid <programmingkidx@gmail.com> wrote: >>>>> Remove the open dialog code that runs when no arguments are supplied with >>>>> QEMU. >>>>> Not everyone needs a hard drive or cdrom to boot their target. A user might >>>>> only >>>>> need to use their target's bios to do work. With that said, this patch >>>>> removes >>>>> the unneeded open dialog code. >>>>> >>>>> Signed-off-by: John Arbuckle <programmingkidx@gmail.com> >>>> >>>> I admit to not being much of a fan of this feature of the >>>> Cocoa UI, but it has been in QEMU's OSX UI since 2005. >> >> QEMU supported Mac OS 10.3 since that time, but that wasn't enough of a >> reason to keep supporting it. >> >>>> In particular, if you remove it then double-clicking to >>>> start QEMU from the Finder won't do anything useful, and >>>> you now have to start it from the command line. >> >> What if the user finds working with OpenBIOS useful? >> What if the target doesn't support a hard drive? >> The automatic open dialog feature does get in my way when I >> am working with OpenBIOS. >> >>>> I agree that it does somewhat assume the x86-centric >>>> "just provide a disk image" semantics, but it's not clear >>>> to me that the most appropriate way to deal with this is >>>> to just rip the dialog box code out entirely. >> >> This code is from a time when the x86 target was the only thing people paid >> attention to. If the user forgets to supply any arguments to QEMU, he can >> always just quit QEMU and start again with arguments. > > By the way, I don't mean that I'm completely opposed to the > idea of dropping the open-dialog. I'd just like to hear > some input from other people who care about OSX QEMU > rather than just you and me. Who else is there?
On 19 September 2015 at 08:01, Programmingkid <programmingkidx@gmail.com> wrote: > > On Sep 19, 2015, at 10:58 AM, Peter Maydell wrote: >> By the way, I don't mean that I'm completely opposed to the >> idea of dropping the open-dialog. I'd just like to hear >> some input from other people who care about OSX QEMU >> rather than just you and me. > > Who else is there? Andreas had some feedback on IRC. I've thought about this a bit and: (1) this "open-dialog if no command line arguments" is really QEMU trying to provide features that ought to be in a virt-manager type wrapper, not in QEMU proper. So that's one argument for dropping it. A proper wrapper VM manager program would obviously launch its VM management GUI window if started via the GUI (or would have VM config files that it would associate to itself and run if the files were clicked). (2) Dropping the dialog box brings the OSX UI code closer into line with the other UI frontends. That means that at some point in the future we could maybe restructure it so it doesn't have the weird "UI's main function takes control at startup" structure, and we can just init the UI in the same way the other UIs do. (3) if we don't drop it, we should probably only have it when we don't see the magic argument that means "we got invoked by somebody double-clicking the app in Finder". Currently I'm leaning towards "yes, just drop the dialog box completely". thanks -- PMM
On Sep 21, 2015, at 3:01 PM, Peter Maydell wrote: > On 19 September 2015 at 08:01, Programmingkid <programmingkidx@gmail.com> wrote: >> >> On Sep 19, 2015, at 10:58 AM, Peter Maydell wrote: >>> By the way, I don't mean that I'm completely opposed to the >>> idea of dropping the open-dialog. I'd just like to hear >>> some input from other people who care about OSX QEMU >>> rather than just you and me. >> >> Who else is there? > > Andreas had some feedback on IRC. > > I've thought about this a bit and: > > (1) this "open-dialog if no command line arguments" is really QEMU > trying to provide features that ought to be in a virt-manager > type wrapper, not in QEMU proper. So that's one argument for > dropping it. A proper wrapper VM manager program would obviously > launch its VM management GUI window if started via the GUI (or > would have VM config files that it would associate to itself and > run if the files were clicked). > > (2) Dropping the dialog box brings the OSX UI code closer into > line with the other UI frontends. That means that at some point > in the future we could maybe restructure it so it doesn't have > the weird "UI's main function takes control at startup" structure, > and we can just init the UI in the same way the other UIs do. > > (3) if we don't drop it, we should probably only have it when > we don't see the magic argument that means "we got invoked by > somebody double-clicking the app in Finder". > > Currently I'm leaning towards "yes, just drop the dialog box > completely". Great to hear.
On 10 September 2015 at 17:49, Programmingkid <programmingkidx@gmail.com> wrote: > Remove the open dialog code that runs when no arguments are supplied with > QEMU. > Not everyone needs a hard drive or cdrom to boot their target. A user might > only > need to use their target's bios to do work. With that said, this patch > removes > the unneeded open dialog code. > > Signed-off-by: John Arbuckle <programmingkidx@gmail.com> OK, I think I agree we should drop this dialog box. For the benefit of people who try to start QEMU from the Finder, could you make it do "if we have one argument and it is '-psn' then bring up a dialog box saying "Please start QEMU from the command line with appropriate arguments" ? I think that would be fairly simple and would help for any users out there who are using the dialog box to understand how QEMU's behaviour has changed. thanks -- PMM
On Sep 23, 2015, at 2:58 PM, Peter Maydell wrote: > On 10 September 2015 at 17:49, Programmingkid <programmingkidx@gmail.com> wrote: >> Remove the open dialog code that runs when no arguments are supplied with >> QEMU. >> Not everyone needs a hard drive or cdrom to boot their target. A user might >> only >> need to use their target's bios to do work. With that said, this patch >> removes >> the unneeded open dialog code. >> >> Signed-off-by: John Arbuckle <programmingkidx@gmail.com> > > OK, I think I agree we should drop this dialog box. For the benefit > of people who try to start QEMU from the Finder, could you make it > do "if we have one argument and it is '-psn' then bring up a dialog > box saying "Please start QEMU from the command line with appropriate > arguments" ? We could do this. I'm thinking a dialog box with a continue and a quit button. That ok?
On 23 September 2015 at 14:38, Programmingkid <programmingkidx@gmail.com> wrote: > > On Sep 23, 2015, at 2:58 PM, Peter Maydell wrote: > >> On 10 September 2015 at 17:49, Programmingkid <programmingkidx@gmail.com> wrote: >>> Remove the open dialog code that runs when no arguments are supplied with >>> QEMU. >>> Not everyone needs a hard drive or cdrom to boot their target. A user might >>> only >>> need to use their target's bios to do work. With that said, this patch >>> removes >>> the unneeded open dialog code. >>> >>> Signed-off-by: John Arbuckle <programmingkidx@gmail.com> >> >> OK, I think I agree we should drop this dialog box. For the benefit >> of people who try to start QEMU from the Finder, could you make it >> do "if we have one argument and it is '-psn' then bring up a dialog >> box saying "Please start QEMU from the command line with appropriate >> arguments" ? > > We could do this. I'm thinking a dialog box with a continue and a > quit button. That ok? Do we have any machines where continuing to run with no arguments is actually useful? -- PMM
On Sep 23, 2015, at 5:45 PM, Peter Maydell wrote: > On 23 September 2015 at 14:38, Programmingkid <programmingkidx@gmail.com> wrote: >> >> On Sep 23, 2015, at 2:58 PM, Peter Maydell wrote: >> >>> On 10 September 2015 at 17:49, Programmingkid <programmingkidx@gmail.com> wrote: >>>> Remove the open dialog code that runs when no arguments are supplied with >>>> QEMU. >>>> Not everyone needs a hard drive or cdrom to boot their target. A user might >>>> only >>>> need to use their target's bios to do work. With that said, this patch >>>> removes >>>> the unneeded open dialog code. >>>> >>>> Signed-off-by: John Arbuckle <programmingkidx@gmail.com> >>> >>> OK, I think I agree we should drop this dialog box. For the benefit >>> of people who try to start QEMU from the Finder, could you make it >>> do "if we have one argument and it is '-psn' then bring up a dialog >>> box saying "Please start QEMU from the command line with appropriate >>> arguments" ? >> >> We could do this. I'm thinking a dialog box with a continue and a >> quit button. That ok? > > Do we have any machines where continuing to run with no arguments is actually > useful? qemu-system-ppc does have openbios. This firmware does have a whole environment that the user could work on. I use to study the forth language using it.
diff --git a/ui/cocoa.m b/ui/cocoa.m index 334e6f6..1dc9bc6 100644 --- a/ui/cocoa.m +++ b/ui/cocoa.m @@ -814,7 +814,6 @@ QemuCocoaView *cocoaView; { } - (void)startEmulationWithArgc:(int)argc argv:(char**)argv; -- (void)openPanelDidEnd:(NSOpenPanel *)sheet returnCode:(NSInteger)returnCode contextInfo:(void *)contextInfo; - (void)doToggleFullScreen:(id)sender; - (void)toggleFullScreen:(id)sender; - (void)showQEMUDoc:(id)sender; @@ -895,29 +894,8 @@ QemuCocoaView *cocoaView; - (void)applicationDidFinishLaunching: (NSNotification *) note { COCOA_DEBUG("QemuCocoaAppController: applicationDidFinishLaunching\n"); - - // Display an open dialog box if no arguments were passed or - // if qemu was launched from the finder ( the Finder passes "-psn" ) - if( gArgc <= 1 || strncmp ((char *)gArgv[1], "-psn", 4) == 0) { - NSOpenPanel *op = [[NSOpenPanel alloc] init]; - [op setPrompt:@"Boot image"]; - [op setMessage:@"Select the disk image you want to boot.\n\nHit the \"Cancel\" button to quit"]; -#if (MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_6) - [op setAllowedFileTypes:supportedImageFileTypes]; - [op beginSheetModalForWindow:normalWindow - completionHandler:^(NSInteger returnCode) - { [self openPanelDidEnd:op - returnCode:returnCode contextInfo:NULL ]; } ]; -#else - // Compatibility code for pre-10.6, using deprecated method - [op beginSheetForDirectory:nil file:nil types:filetypes - modalForWindow:normalWindow modalDelegate:self - didEndSelector:@selector(openPanelDidEnd:returnCode:contextInfo:) contextInfo:NULL]; -#endif - } else { - // or launch QEMU, with the global args - [self startEmulationWithArgc:gArgc argv:(char **)gArgv]; - } + // launch QEMU, with the global args + [self startEmulationWithArgc:gArgc argv:(char **)gArgv]; } - (void)applicationWillTerminate:(NSNotification *)aNotification @@ -942,36 +920,6 @@ QemuCocoaView *cocoaView; exit(status); } -- (void)openPanelDidEnd:(NSOpenPanel *)sheet returnCode:(NSInteger)returnCode contextInfo:(void *)contextInfo -{ - COCOA_DEBUG("QemuCocoaAppController: openPanelDidEnd\n"); - - /* The NSFileHandlingPanelOKButton/NSFileHandlingPanelCancelButton values for - * returnCode strictly only apply for the 10.6-and-up beginSheetModalForWindow - * API. For the legacy pre-10.6 beginSheetForDirectory API they are NSOKButton - * and NSCancelButton. However conveniently the values are the same. - * We use the non-legacy names because the others are deprecated in OSX 10.10. - */ - if (returnCode == NSFileHandlingPanelCancelButton) { - exit(0); - } else if (returnCode == NSFileHandlingPanelOKButton) { - char *img = (char*)[ [ [ sheet URL ] path ] cStringUsingEncoding:NSASCIIStringEncoding]; - - char **argv = g_new(char *, 4); - - [sheet close]; - - argv[0] = g_strdup(gArgv[0]); - argv[1] = g_strdup("-hda"); - argv[2] = g_strdup(img); - argv[3] = NULL; - - // printf("Using argc %d argv %s -hda %s\n", 3, gArgv[0], img); - - [self startEmulationWithArgc:3 argv:(char**)argv]; - } -} - /* We abstract the method called by the Enter Fullscreen menu item * because Mac OS 10.7 and higher disables it. This is because of the * menu item's old selector's name toggleFullScreen:
Remove the open dialog code that runs when no arguments are supplied with QEMU. Not everyone needs a hard drive or cdrom to boot their target. A user might only need to use their target's bios to do work. With that said, this patch removes the unneeded open dialog code. Signed-off-by: John Arbuckle <programmingkidx@gmail.com> --- ui/cocoa.m | 56 ++------------------------------------------------------ 1 files changed, 2 insertions(+), 54 deletions(-)