21–30 of 138 posts
Earlier quoted context omitted.
I’d say the license is: “ Use it at your own risk, and don't blame me if anything bad happens. Oh, and if you extend it, make sure there isn't any Objective-C in it!” I’d classify it as Open Source.
I do love the vibe of that license
Earlier quoted context omitted.
MacOS apps are typically written in either Objective-C or Swift as these are the officially supported languages for the MacOS APIs. The code in this template is interfacing with the Objective-C runtime but with pure C.
That has always been possible. Also, under the ObjC layer, is good ol' ANSI C (FreeBSD Unix). There's a number of apps that run on modern Macs, that were written in C, but it is unusual to see ones that leverage the GUI. That said, it's possible to walk from Boston to Portland (OR), but I'd rather take a plane.
I did a straight C++ app for MacOS but 1) I used SDL2 and 2) it was a full-screen game so no Cocoa UI needed. It was kind of fun though in a retro-computing way. (I'm a big fan of SDL now.)
Earlier quoted context omitted.
Oh no that won't fly at all. People around here really like "proper" licenses. And they'll tell you about it.
I don't like the (perhaps actually a) license, because it set's limits on what the user can do with the source code. (Not allowing Objective C in it.)
No license typically means copyright with all rights reserved in the U.S. Perhaps you want to release this into the public domain (see SQLite)?
As someone with no experience in native application development, could someone explain to me why this is significant? I have a rough idea, but I would like to understand it properly.
Ultimately, because new people keep being born and missed the years where this was pretty common and haven't yet bumped into the corners where it still is.
The repo and the SO discussion it was inspired by are themselves 11 years old and seem to be rooted in a new generation of iOS app developers starting to get more deeply curious about the system they're running on and how else it might be approached, which this person then ran with on MacOS.
Apple invites people to get started in making software for their platforms using (what's meant to be) more accessible tooling like Objective-C, Interface Builder, Swift, SwiftUI, etc but there's of course a whole BSD-rooted operating system sitting there once those those developers start digging. It's no secret, but it's a discovery that some people need to make on their own.
Earlier quoted context omitted.
MacOS apps are typically written in either Objective-C or Swift as these are the officially supported languages for the MacOS APIs. The code in this template is interfacing with the Objective-C runtime but with pure C.
That has always been possible. Also, under the ObjC layer, is good ol' ANSI C (FreeBSD Unix). There's a number of apps that run on modern Macs, that were written in C, but it is unusual to see ones that leverage the GUI. That said, it's possible to walk from Boston to Portland (OR), but I'd rather take a plane.
As someone with no experience in native application development, could someone explain to me why this is significant? I have a rough idea, but I would like to understand it properly.
I guess it's normally impossible to write a GUI application for mac os without objective-c libraries doing the talking to the OS, but what do I know.
(Where they would have found many many dusty but detailed man pages and docs waiting for them)
As someone with no experience in native application development, could someone explain to me why this is significant? I have a rough idea, but I would like to understand it properly.
It's similar how you might attempt to build a C++ class from only C components by creating a vtable.
I did a straight C++ app for MacOS but 1) I used SDL2 and 2) it was a full-screen game so no Cocoa UI needed. It was kind of fun though in a retro-computing way. (I'm a big fan of SDL now.)
[1] https://github.com/libsdl-org/SDL/tree/main/src/video/cocoa