On Jan 14, 2015, at 1:29 PM, Peter Maydell wrote: > On 14 January 2015 at 18:18, Programmingkid <programmingk...@gmail.com> wrote: >> >> On Jan 14, 2015, at 12:19 PM, Peter Maydell wrote: >>> (2) Having done this I find that all my other application windows >>> have been squashed down into a corner of my screen, presumably because >>> we've told MacOSX "the screen is 640x480" and it's rearranged the >>> app windows to suit. We mustn't mess things up like this. >> >> This can't be avoided. When the screen resolution changes, all the >> applications usually adjust to the new size. It is the same thing >> that happens when you use a full screen game. > > No, when I use other full screen programs this doesn't happen at all. > QEMU with this patch is the first time I've ever seen this from > any OSX app.
How long have you been a Mac user? I am shocked you have never seen this before. I'm guessing full screen gaming was never your thing. > >>> (3) I managed to get at the underlying "QEMU" window with its title >>> bar somehow even when in full screen mode: I could move it about the >>> screen with the mouse... >> >> Really? I think you said you had Mac OS 10.7. I don't have that, but >> I do have access to Mac OS 10.9. Just send me the instructions on how >> to reproduce this. > > I run 10.9.5. I don't know exactly how I got to that window, > and I don't really want to mess about with this patch because > behaviour (2) above is so obnoxious. > >>> (4) I get a lot of compile warnings for this patch: >>> > >> Disabling the depreciation warning would eliminate these errors. > > Not all of them are deprecation warnings. Also I would prefer not > to disable deprecation warnings, as then we'll have no notice > of what might break on future OSX versions. I'm sure we will know exactly when a depreciated function isn't implemented anymore. We will probably see some message in the Console. Or a backtrace to a crash will show us where and when QEMU crashed. I guess I could also use non-depreciated functions in the patch. The thing is QEMU will determine what to use at runtime, so the depreciation messages might not go away. > >>>> int w = surface_width(surface); >>>> int h = surface_height(surface); >>>> - /* cdx == 0 means this is our very first surface, in which case we >>>> need >>>> - * to recalculate the content dimensions even if it happens to be the >>>> size >>>> - * of the initial empty window. >>>> - */ >>>> - bool isResize = (w != screen.width || h != screen.height || cdx == >>>> 0.0); >>>> - >>>> + bool isResize = (w != screen.width || h != screen.height); >>> >>> (6) This looks like you've just dropped a bug fix. How are you >>> dealing with this case if not by the method described in the >>> now-deleted comment? >> >> If the guest does change its resolution, then we try to match it >> in the host. When I eliminated this code, it made the guest look >> so much better. I was actually able to read documents in the guest >> at full screen. > > The point is that you've dropped a bugfix which isn't related to > full screen at all -- if this is the first call to switchSurface > we *must* display it, which is what the cdx check does. See > commit 381600dad. This bugfix does change the appearance of full screen mode. Have you seen a guest at full screen? The cdx and cdy variables make the guest OS look very distorted.