Hacker News Reader

Writing objective-c code for mac os GUI apps was one of those things that finally made "interfaces"/"protocols" really click for me as a young developer. Just implement (some, not even all) method in "FooWidgetDelegate", and wire your delegate implementation into the existing widget. `willFrobulateTheBar` in your delegate is called just before a thing happens in the UI and you can usually interfere or modify with the behavior before the UI does it. Then `didFrobulateTheBar` is called after with the old and new values or whatever other context makes sense and you can hook in here for doing other updates in response to the UI getting an update. If you don't implement a protocol method, the default behavior happens, and preserving the default behavior is baked into the process, so you don't have to re-implement the whole widget's behavior just to modify part of it.

It's probably one of the better UI frameworks I think I've used (though admittedly a lot of that also is in part due to "InterfaceBuilder" magic and auto-wiring. Still I often wish for that sort of elegant "billions of hooks, but you only have to care about the ones you want to touch" experience when I've had to use other UI libraries.

  > I feel like I must be in some sort of honeymoon phase but I 100% completely understand now why many Mac-native apps are Mac-native.

it seems like everybody prefers ios, but i really still think after all these years i prefer appkit; it really is so well documented and the quality of the api is the best i've seen by a long mile

> Reading all the really, super old documentation that explains entire subsystems in amazingly technical depth

Any links?

> Maybe this is also why Smalltalk fiends are such fans.

I started getting interested in Smalltalk after I tried writing a MacOS program by calling the Objective-C runtime from Rust and had a surprisingly good time. A Smalltalk-style OO language feels like a better base layer for apps than C.

> Any links?

For example, this guide I was reading just earlier: https://developer.apple.com/library/archive/documentation/Co...

Generally everything in that documentation archive is absolutely amazing. I don't know why it's an archive; presumably they laid off or reassigned the entire team working on it and there will be no more. The closest thing today would probably be Technotes: https://developer.apple.com/documentation/technotes

> Writing GUIs for the Linux desktop is also a terrible experience.

I've found the DX for GTK to be at least tolerable. Not fantastic, but I can at least look at a particular API, guess how the C-based GObject code gets translated by my language bindings of choice, and be correct more often than not. The documentation ranges from serviceable to incomplete, but I can at least find enough discussion online about it to get it to do what I want.

Also, GTK apparently ships with a built-in inspector tool now. Ctrl-Shift-I in basically any GTK app opens it. That alone is extremely useful, and you basically have to do nothing to get it. It's free.

I've never tried Qt. The applications that use it always seem off to me.

As for OLE, you're actually thinking of COM, not OLE. They were co-developed together: COM is a cross-language object system (like GObject), while OLE is a set of COM interfaces for embedding documents in other arbitrary documents. Like, if you want to put a spreadsheet into a Word document, OLE is the way you have to do that. Microsoft even built much of IE[0] on top of OLE to serve as its extension mechanism.

OLE is dead because its use case died. Compound documents as a concept don't really work in the modern era where everything is same-origin or container sandboxed. But COM is still alive and well. It's the glue that holds Windows together - even the Windows desktop shell. All the extension interfaces are just COM. The only difference is that now they started packaging COM objects and interfaces inside of .NET assemblies and calling it "WinRT". But it's the same underlying classes. If you use, say, the Rust windows crate, you're installing a bunch of language bindings built from WinRT metadata that, among other things, call into COM classes that have been there for decades.

Mac apps are Mac native because Apple gives enough of a shit about being visually consistent that anyone using a cross-platform widget toolkit is going to look out of place. Windows abandoned the concept of a unified visual identity when Windows 8 decided to introduce an entirely new visual design built around an entirely new[1] widget toolkit, with no consideration of how you'd apply any of that to apps using USER.dll/Common Controls. As it stands today, Windows does not have a good answer to "what widget toolkit do I use to write my app", and even Microsoft's own software teams either write their own toolkits or just use Electron.

[0] Petition to rename ActiveX to WebOLE

[1] OK, yes, XAML existed in the Vista era, but that was .NET only, and XAML apps didn't look meaningfully different from ones building their own USER.dll window classes like it's 1993.

> As for OLE, you're actually thinking of COM, not OLE. They were co-developed together: COM is a cross-language object system (like GObject), while OLE is a set of COM interfaces for embedding documents in other arbitrary documents. Like, if you want to put a spreadsheet into a Word document, OLE is the way you have to do that. Microsoft even built much of IE[0] on top of OLE to serve as its extension mechanism.

Oops, you are right about COM. I got them mixed up because I was thinking of the integration in WordPad.

> Mac apps are Mac native because Apple gives enough of a shit about being visually consistent that anyone using a cross-platform widget toolkit is going to look out of place. Windows abandoned the concept of a unified visual identity when Windows 8 decided to introduce an entirely new visual design built around an entirely new[1] widget toolkit, with no consideration of how you'd apply any of that to apps using USER.dll/Common Controls. As it stands today, Windows does not have a good answer to "what widget toolkit do I use to write my app", and even Microsoft's own software teams either write their own toolkits or just use Electron.

Mac apps are Mac native because the APIs are amazing and the ROI can be really really good. It takes so much effort to do the same from scratch, especially cross-platform, that, you're right, I can smell anything written in Qt (because the hitboxes and layout are off) or GTK (because the widget rendering is off).

With that said though, wxWidgets seems to translate EXTREMELY well to macOS, though last I used it, it didn't have good support for Mojave's dark mode. Maybe support is better nowadays. For example, Audacity appears to me as just a crammed Mac-native app rather than blatant use of a cross-platform toolkit, and wxPython used well can be completely mistaken for fully native.

wxWidgets calls the underlying native controls directly; Qt uses it to inform how to render but still does its own thing, at least according to a discussion I had with a Qt engineer some years back.

(I am open to being corrected)

wxWidgets has properly supported dark mode for a bit now.

9front can mount old DOC/XLS documents as OLE 'filesystems' first and then extract the tables/text from them.

As for sandboxing, 9front/plan9 uses namespaces, but shared directories exist, of course. That's the point on computing, the user will want to bridge data in one way or another. Be with pipes, with filesystems/clipboard (or a directory acting as a clipboard with objects, which would be the same in the end).

Welcome to Smalltalk, Lisp, Java and .NET, which alongside NeXTSTEP/OS X, share a common linage of tooling ideas, and programming language features.

Hence why given the option I rather stay in such environments.

Now Android Studio is the product of Google's mess, and I am glad to have moved away from Android development, it also doesn't have anything to do with enjoying pure Java development on desktop (Swing, SWT, JavaFX) and server.