Dev Q: What Cocoa API/features can MacVim use now?

29 views
Skip to first unread message

sam

unread,
Sep 12, 2020, 11:24:25 PM9/12/20
to vim_mac
A couple questions about MacVim development:

The current release (snapshot 165) of MacVim targets macOS 10.9+. Does that mean that new code can use any Cocoa API from macOS 10.9 or before? For example, NSStackView was introduced in macOS 10.9. MacVim doesn't currently make use of this API, but if a potential contributor wanted to work on a feature, could they use it?

It also appears that MacVim does manual memory management. ARC was introduced well before macOS 10.9. Could new code use ARC if it is in its own file and compiled with the fobj-arc flag? Is there a reason not to migrate MacVim to ARC?

Yee Cheng Chin

unread,
Sep 13, 2020, 5:55:07 AM9/13/20
to vim...@googlegroups.com
Actually, MacVim uses new APIs all the time! For example, it supports Touch Bar which requires 10.12.2. Features that use these newer APIs do have to be optional with the correct compile-time and runtime checks, unless we make a conscious decision to update the minimal target (10.9). To be fair, MacVim is not actively tested on older macOS versions like 10.9, and so we would only know of issues if people file bugs against MacVim.

I'm curious what you intend to use NSStackView for though? If it's a major feature, you may want to file a WIP PR/issue or contact us first just to get some feedbacks. MacVim's philosophy is to be the most integrated / native gVim implementation on macOS, and intentionally not bloated with non-Vim features, so I'm curious what feature would need NSStackView.

ARC: It's mostly legacy. Developers' time is limited, and I think it's better to spend time on implementing other features / fixing existing bugs than converting to ARC. If you want to write new code, please use the existing memory allocation mechanism instead of ARC. The reason is the same as why companies have coding standards: inconsistencies in the codebase tends to be worse than whatever problem you are trying to fix.

Thanks for contributing!

--
--
You received this message from the "vim_mac" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_mac+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_mac/37b2f7a4-322c-42e9-9157-e2c68222d061n%40googlegroups.com.

Yee Cheng Chin

unread,
Sep 13, 2020, 6:21:22 AM9/13/20
to vim...@googlegroups.com
Actually, thinking about it more I think I would be ok with selective usage of ARC in new files. Again, maybe chat with me first, as I'm curious what the use case is, and autorelease works differently between ARC and manual.

sam

unread,
Sep 13, 2020, 3:34:50 PM9/13/20
to vim_mac
I was mostly asking to get a sense of how you think about using Cocoa APIs and doing development going forward. You've basically answered this well. I have my own Mac project and I've personally found it challenging to keep up with the changes Apple makes with each OS release while maintaining backward compatibility.

I was thinking about NSStackView in the context of the Preference window. MacVim now has more preference options than before and may add more in the future. Stack views can be helpful in assuring proper alignment of the various controls and also handling localization since different languages will result in strings of different dimensions. They can also selectively hide sections which could be used to cleanly handle things like the DISABLE_SPARKLE option. I haven't implemented anything - it was more of a thought experiment at this point.

Thank you for all the work you do on MacVim. It's a great project.

Yee Cheng Chin

unread,
Sep 20, 2020, 5:36:38 PM9/20/20
to vim...@googlegroups.com
Yeah, maintaining backwards compatibility on macOS is definitely a big pain point in MacVim! Apple doesn't exactly make it easy either since they tend to want everyone to use the latest and greatest but given Vim's philosophy, MacVim has mostly erred on the side of caution and try to make sure it still runs on old OS versions. Maybe it's a fool's errand as I don't get good visibility into what % of users use which OS version (it's not like MacVim collects telemetry from users and I have no plan to do so).

If you want to refactor the preference pane to use NSStackView, feel free to work on that! (I just merged your PR to hide Sparkle update settings) I do agree it will be useful and as we discussed anything 10.9+ can be used without needing additional checks, which includes NSStackView. I think I briefly looked into it before but my unfamiliarity with it made me drop it half way through to work on other things. And yes, I see adding more options in the future to expose more options instead of relying on half-supported "defaults write" style configuration, and localization will be very welcome, although it would require MacVim contributors to submit translations. (I will likely send another email out in the future when I want to do a localization push).

Thanks for helping out!

Reply all
Reply to author
Forward
0 new messages