cocoa-cb: re-enable wid (NSView) embedding on macOS for libmpv use

[softworkz]

In version 0.37, support for the old cocoa backend had been dropped, which unfortunately also removed the ability of embedding mpv in native applications by specifying a wid - which is still working for all other platforms.

This PR aims to remedy that situation by leveraging the existing cocoa-cb implementation which already has just about everything that it takes and it has been merely about gluing loose ends together and omitting those parts that are specific to standalone application use, like NSApplication and NSWindow.

[github-actions]

Download the artifacts for this pull request:

Windows

• mpv-v0.41.0-dev-gdd2fd7056-pr17221-20665378576-aarch64-pc-windows-msvc
• mpv-v0.41.0-dev-gdd2fd7056-pr17221-20665378576-aarch64-pc-windows-msvc-pdb
• mpv-v0.41.0-dev-gdd2fd7056-pr17221-20665378576-i686-w64-mingw32
• mpv-v0.41.0-dev-gdd2fd7056-pr17221-20665378576-x86_64-pc-windows-msvc
• mpv-v0.41.0-dev-gdd2fd7056-pr17221-20665378576-x86_64-pc-windows-msvc-pdb
• mpv-v0.41.0-dev-gdd2fd7056-pr17221-20665378576-x86_64-w64-mingw32

macOS

• mpv-v0.41.0-dev-gdd2fd7056-pr17221-20665378576-macos-14-arm
• mpv-v0.41.0-dev-gdd2fd7056-pr17221-20665378576-macos-15-arm
• mpv-v0.41.0-dev-gdd2fd7056-pr17221-20665378576-macos-15-intel
• mpv-v0.41.0-dev-gdd2fd7056-pr17221-20665378576-macos-26-arm

[softworkz]

When there's once another AI bot coming to respond, then I'll close this PR.

[CounterPillow]

When there's once another AI bot coming to respond, then I'll close this PR.

Why? Didn't you request all of these to spam this PR?

[na-na-hi]

diffray-bot is spam advertising campaign (look at all these utm_source links) "review"ing code without permission

aidenybai/react-grab#102 (comment)

Just block it.

[kasper93]

Just block it.

Done.

[softworkz]

Why? Didn't you request all of these to spam this PR?

I didn't request anything and I never heard of diffray before.
Regarding Copilot, I used to believe that it's a repo setting, but it seems it came from my account (they recently offered me Copilot Pro for free, which I didn't decline), so that part is probably on my own. Disabled now, apologies for that part.

[Akemi]

i am very hesitant to add this feature to the old cocoa-cb backend:

• we have a quasi feature freeze for cocoa-cb
  • i am planing to deprecated it officially
  • don't want to add complexity/ possible bugs to something that 'works' mostly
  • don't want to add more complexity to a backend that is a quasi frankenstein between mpv core and libmpv
• this implementations seems very invasive and i don't think it needs to be like that
• opengl is abandoned/deprecated by Apple since many years/decades (~2010/2018)
• cocoa-cb isn't useful on newer hardware/software

what benefit does this give us over a similar macvk feature for example?

i am inclined to just closing this PR sorry.

[softworkz]

this implementations seems very invasive and i don't think it needs to be like that

In which ways do you think this PR would be invasive? When you take a closer look you'll see that every change involves a clear separation of cases. The existing code paths for the working case are entirely untouched.

we have a quasi feature freeze for cocoa-cb
opengl is abandoned/deprecated by Apple since many years/decades (~2010/2018)
cocoa-cb isn't useful on newer hardware/software

And still, there were 98 commits to the osdep/mac folder in 2024...

what benefit does this give us over a similar macvk feature for example?

• It closes that gap for libmpv window embedding that was caused by the removal of the cocoa backend
  The reasons that were given for the removal of that backend were plausible (like old and unmaintained code) but these don't apply to the cocoa-cb backend, which is the natural replacement for the case of libmpv window embedding.

• The cocoa-cb backend goes the libmpv route, so it's just natural to allow making use of it via libmpv embedding as well

• There's currently no path for NSView embedding with macvk, so it closes that gap until there is one

• It is working on VMs/emulators where macvk is unavailable, which is crucial for development and automated testing, especially when developing cross-platform apps from a single code base

• The policy of MPV has always been to support a range of different backends on each platform rather than just "the most preferable one" and dropping all others, I don't see why it should be done differently for Apple

Thanks a lot for looking at this PR

[llyyr]

And still, there were 98 commits to the osdep/mac folder in 2024...

Not all osdep/mac changes are related to the cocoa backend.

$ git rev-list --count --since="2021-01-01" --grep="cocoa-cb" HEAD
18

[softworkz]

And still, there were 98 commits to the osdep/mac folder in 2024...

Not all osdep/mac changes are related to the cocoa backend.

$ git rev-list --count --since="2021-01-01" --grep="cocoa-cb" HEAD
18

Right, thanks. Then it's 18. Doesn't change the argument, though. ;-)

[Akemi]

In which ways do you think this PR would be invasive? When you take a closer look you'll see that every change involves a clear separation of cases. The existing code paths for the working case are entirely untouched.

they aren't really 'untouched' they are just wrapped in ifs now. this adds a whole new level of complexity to the whole backend. anyway i think this is more appropriate for a proper code review, in the case i decide to merge it.

And still, there were 98 commits to the osdep/mac folder in 2024...

Right, thanks. Then it's 18. Doesn't change the argument, though. ;-)

i am not sure what kind of argument you are trying to make? first of all the amount of commits is irrelevant (might not even catch all commits directly/solely related to cocoa-cb though), but the content is. of those 18 commits (since 2021) or 16 (since 2024, not even sure why 2024 when the past year is 2025) the majority are bug fixes, feature replacements, things that were a necessity because other parts of the code changed or are plainly unrelated to cocoa-cb because only the commit message mentioned it. only one commit is an actual new feature (8a61929 #14017). something i did in 2020/2021 and only was added in 2024. even mentioned on the PR that this is the last new feature.

• It closes that gap for libmpv window embedding that was caused by the removal of the cocoa backend
  The reasons that were given for the removal of that backend were plausible (like old and unmaintained code) but these don't apply to the cocoa-cb backend, which is the natural replacement for the case of libmpv window embedding.
• The cocoa-cb backend goes the libmpv route, so it's just natural to allow making use of it via libmpv embedding as well

especially because it uses libmpv (rendering API) internally it shouldn't be used from an external libmpv instance/handler imo.

• There's currently no path for NSView embedding with macvk, so it closes that gap until there is one

there is no way in cocoa-cb either atm, hence my question. if we speak PRs, we have/had a similar one for macvk support too.

• It is working on VMs/emulators where macvk is unavailable, which is crucial for development and automated testing, especially when developing cross-platform apps from a single code base

not sure what point you try to make. the feature is not available atm, so there isn't even anything to test regarding cross platform support of wid embedding.

• The policy of MPV has always been to support a range of different backends on each platform rather than just "the most preferable one" and dropping all others, I don't see why it should be done differently for Apple

not sure where you got that policy from. we support what we feel like supporting and maintaining. nothing is dropped here it's quasi deprecated, like mentioned. those are different things, eg i am still fixing bugs. Apple dropped the support in the first place, i don't feel like supporting something Apple doesn't support, like already mentioned.

[softworkz]

Thanks a lot for your reply.

they aren't really 'untouched' they are just wrapped in ifs now. this adds a whole new level of complexity to the whole backend. anyway i think this is more appropriate for a proper code review, in the case i decide to merge it.

What I meant is that the "code paths" (not the code itself) are untouched in terms of the existing functionality - in other words: I made the changes very carefully to avoid any kinds of regression.
If you like, I can add some comments for better clarity (I just adapted to what I've seen, so there are just few in this PR).

Right, thanks. Then it's 18. Doesn't change the argument, though. ;-)

i am not sure what kind of argument you are trying to make?

I simply meant to say that here has still been quite a bit of work done recently. I looked at the Git log of the osdep/mac folder and there was a substantial amount of commits in 2024 which didn't seem to fit together to yours saying it's deprecated and kind-of frozen, but that's just a detail that made me wonder whether you might generally tend to turn down Mac PRs - after seeing not much other committers in the Git log from that folder. ;-)

especially because it uses libmpv (rendering API) internally it shouldn't be used from an external libmpv instance/handler imo.

I see it somewhat differently: the code is perfectly suitable for the purpose - it already does almost everything that is needed for use via libmpv. All that was needed is to connect the loose ends and add some conditional treatment here and there.
Without your code, this wouldn't have been possible to accomplish in a reasonable amount of time and with the same - long-term proven - quality of your implementation.

I know very well how uncomfortable it can sometimes feel when an alien person comes around and starts drilling holes into your code. I have some hope that it might get better when you review it (in case).

There's currently no path for NSView embedding with macvk, so it closes that gap until there is one
there is no way in cocoa-cb either atm, hence my question.

There has been one until not too long ago (via cocoa) - the sample is still sitting in the samples repo, confusing people for why it doesn't work - WID embedding works for all other platforms - that's what I meant by "closing the gap".

if we speak PRs, we have/had a similar one for macvk support too.

I haven't seen that one. Is it good? IMO, both ways should work with WID. I had planned to look into that as well.

• It is working on VMs/emulators where macvk is unavailable, which is crucial for development and automated testing, especially when developing cross-platform apps from a single code base

not sure what point you try to make. the feature is not available atm, so there isn't even anything to test regarding cross platform support of wid embedding.

I meant in case it would have been merged.

not sure where you got that policy from...

Yea, sorry, "policy" was a stupid term in this context, I should have found a better wording, but I'm glad you got what I meant to express :-)

Thanks again for your time

[softworkz]

Thinking about it - how would you feel about having a descendant class of CocoaCB instead, which implements the different impls in overrides? The cocoa_cb_common.swift file could remain mostly unchanged in that case.