From: BALATON Zoltan <balaton@eik.bme.hu>
To: Akihiko Odaki <akihiko.odaki@gmail.com>
Cc: qemu Developers <qemu-devel@nongnu.org>,
Peter Maydell <peter.maydell@linaro.org>,
Gerd Hoffmann <kraxel@redhat.com>,
Howard Spoelstra <hsp.cat7@gmail.com>
Subject: Re: [PATCH] ui/cocoa: Remove the uses of full screen APIs
Date: Fri, 19 Feb 2021 11:24:20 +0100 (CET) [thread overview]
Message-ID: <0d2beba-2a74-3a36-16d3-f1bac83dedce@eik.bme.hu> (raw)
In-Reply-To: <CAMVc7JXvAt6neB2H1Bmp-HKachc3di8FpDWy3=vP2x-PDE+xxA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1847 bytes --]
On Fri, 19 Feb 2021, Akihiko Odaki wrote:
> 2021年2月17日(水) 22:09 Gerd Hoffmann <kraxel@redhat.com>:
>>
>> On Fri, Feb 12, 2021 at 09:05:40AM +0900, Akihiko Odaki wrote:
>>> The detections of full screen APIs were wrong. A detection is coded as:
>>> [NSView respondsToSelector:@selector(exitFullScreenModeWithOptions:)]
>>> but it should be:
>>> [NSView instancesRespondToSelector:@selector(exitFullScreenModeWithOptions:)]
>>>
>>> The uses of full screen APIs were also incorrect, and if you fix the
>>> detections, the full screen view stretches the video, changing the
>>> aspect ratio, even if zooming is disabled.
>>>
>>> Remove the code as it does nothing good.
>>
>> So, it's broken right now (and probably for quite a while without anyone
>> complaining). And the attempt to fix it didn't work out very well.
>> Correct?
>
> Because the detections of APIs are wrong, the code using those APIs
> were never executed and nobody realized it was broken.
Full screen on MacOS X worked when I've last tried but that was 2 years
ago.
> I did not seriously attempt to fix it because the APIs are no longer
> the best ways to implement fullscreen. ([NSWindow -toggleFullScreen:]
> is more favorable today.) There is not much to reuse even if
> implementing fullscreen with [NSView -enterFullScreenModeWithOptions:]
> since the code is so small.
I think there are people using QEMU to run old MacOS versions on MacOS
X/macOS and may not follow this mailing list but I'm sure they'll complain
once you break it.
Regards,
BALATON Zoltan
>> Just dropping the code makes sense to me then.
>>
>> Any objections or better suggestions from the macos camp?
>> If not I'll go queue it for the next UI pull request in a day or two.
>>
>> thanks,
>> Gerd
>>
>
> Thank you for responding to my patches.
>
> Akihiko Odaki
>
>
next prev parent reply other threads:[~2021-02-19 10:25 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-12 0:05 [PATCH] ui/cocoa: Remove the uses of full screen APIs Akihiko Odaki
2021-02-17 13:09 ` Gerd Hoffmann
2021-02-19 9:38 ` Akihiko Odaki
2021-02-19 10:24 ` BALATON Zoltan [this message]
2021-02-19 11:01 ` Akihiko Odaki
2021-02-19 13:55 ` Gerd Hoffmann
2021-02-20 1:31 ` [PATCH v2] " Akihiko Odaki
2021-02-22 10:30 ` Gerd Hoffmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0d2beba-2a74-3a36-16d3-f1bac83dedce@eik.bme.hu \
--to=balaton@eik.bme.hu \
--cc=akihiko.odaki@gmail.com \
--cc=hsp.cat7@gmail.com \
--cc=kraxel@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.