feat: add support for macOS 13 Ventura

[ShlomoCode]

Describe your changes

Added support for macOS 13 Ventura.

Related issue number(s) and link(s)

closes #211

Checklist before requesting a review

• I have performed a self-review of my code
• If this change affects core functionality, I have added a description highlighting the changes
• I have followed conventional commit guidelines

Core Functionality Changes

No change is expected for macOS 14 and above, for older systems support does not include a number of small things such as SmoothGradient or the option to cancel in warning about overlapping elements in the settings.

[ejbills]

Does the window switcher work with this? This was the main reason DD is min macOS 14, the observable property allows us to reflect the changes in index when using the switcher. I'm not sure if @published properties are a slot-in replacement - however I may be wrong.

[ShlomoCode]

It seems to work fine, although I'm actually not very familiar with the windows switcher. Is there anything special I should look out for?

CleanShot.2024-08-23.at.04.15.05.mp4

[ejbills]

I'll try it out in a bit

[ejbills]

option to cancel in warning about overlapping elements in the settings

Is this really not a thing in previous versions? I think we can make the message util take another approach if it's not available, similar to the window manager legacy func you added.

Cool PR, thank you! Love it!

[ShlomoCode]

The message still appears, only the "cancel" button will not work (we do need to hide it), but the main goal, to draw the user's attention to the overlap, has been achieved. How can I get the oldValue in macOS 13?

[ejbills]

How can I get the oldValue in macOS 13?

Store the value in a state var within the settings view.

[ShlomoCode]

Thanks, done.

[ShlomoCode]

Tested with macOS 13.0 VM, looks fine
I think it's ready

[ejbills]

Tested with macOS 13.0 VM, looks fine I think it's ready

The window switcher does not function properly, pressing tab now does nothing as the @observable was responsible for making the view react to the index changes.

[ejbills]

@ShlomoCode can you give me write permissions for your fork? I fixed the window preview observed object logic, so now the child views will react to the changes in index! Will merge after I can push.

Thanks for your hard work Shlomo, you've proven to be invaluable to the success of DockDoor!

[ejbills]

#267 (comment)

[illavoluntas]

Once this PR is merged, does it mean DockDoor will be fully compatible with Ventura at the next release?

Does the API used for Ventura work on Monterey? Or is it 13.0+?

[ShlomoCode]

Once this PR is merged, does it mean DockDoor will be fully compatible with Ventura at the next release?

Yes, 2 things I have not done at the moment are support for Window Image Resolution Scale and SmoothGradient (the package we use for this is macOS 14 only)

Does the API used for Ventura work on Monterey? Or is it 13.0+?

I can adapted quite easily to macOS 12.3, the question is how much demand is there for it?

[ShlomoCode]

@ejbills Sorry for the late reply, you should now be able to push. Pay attention to do a rebase pull first (git pull --rebase)

[illavoluntas]

I can adapted quite easily to macOS 12.3, the question is how much demand is there for it?

There will always be demand for older system compatibility. As of today, I think some people still use 10.15 Catalina, it might be the oldest most demanded version (macOS 11 Big Sur abandoned a lot of Macs).

[ShlomoCode]

OK, let's merge Ventura first.

[ShlomoCode]

@ejbills I see that fixing the broken onChange currIndex is a small change, so I just pushed it, so you don't have to push yours

[ejbills]

@ejbills Sorry for the late reply, you should now be able to push. Pay attention to do a rebase pull first (git pull --rebase)

@ejbills Sorry for the late reply, you should now be able to push. Pay attention to do a rebase pull first (git pull --rebase)

My local changes actually get rid of the coordinator being a singleton. I rewrote the logic to ensure it properly makes use of the ObservableObject pattern for passing data to child views. So, the onChange won't be necessary. I will push later today, thanks!

[ShlomoCode]

It sounds more appropriate for a separate refactor commit

[ejbills]

It sounds more appropriate for a separate refactor commit

I don't think a separate refactor commit is necessary in this case. The change to an ObservableObject pattern is directly related to the PR's purpose of adding macOS Ventura support. It's a relatively small change, impacting less than ~100 lines of code. I'll be pushing these changes soon as part of this PR, as I am away from my computer at the moment.

Further refactoring is on my todo list, and it will not be in this PR. Hope that addresses your concerns.

[ShlomoCode]

@ejbills You dropped some of my code...

When working on PR together, it is advisable to wait for a mutual review