11–20 of 89 posts
Is... the name a Portlandia reference?
But more than likely it's just a reference to Apple's Cocoa api.
Is... the name a Portlandia reference?
It could be a Portland reference. The city had a gourmet chocolate shop called Cacao that served "drinking chocolate" from 2005 until 2020. I know because I went in there after getting lost and drenched in a Portland February, and the staff there were kind enough to bring me towels and let me wait out the downpour while I sipped chocolate. But more than likely it's just a reference to Apple's Cocoa api.
Is... the name a Portlandia reference?
Pretty cool project, seems like it's becoming more realistic to write cross platform native desktop applications with OS-specific GUIs in Rust. It's not too far from the write-once-run-everywhere philosophy of React native, Electron and similar. One could write their UI state and application logic once while maintaining 3 entry points using the various platform GUI bindings (gtk-rs, cacao, win32?) to represent the UI…
Yes it is. Heavyweight desktop GUI applications like DAWs or CAD or image/video editing are old established technology.
> This has the advantage of a project feeling natural to the platform while still allowing for code reuse between platforms
Having written cross platform native applications: This is a pain in the ass to do well - and there isn’t a particular reason this hasn’t been doable in C/C++ since forever - Rust isn’t some silver bullet. “Abstracting” away the native GUI/UX seems to be a common pitfall for junior devs - how hard can it be they think - then they learn why Qt exists.
> It's not too far from the write-once-run-everywhere philosophy of React native, Electron and similar.
Electron is about as far removed from the philosophy of targeting platform native toolkits as one can get.
Interesting to see that AppKit is fully supported before UIKit, usually it's the reverse (if AppKit is supported at all). I suppose it kind of makes sense… the case for sharing a Rust core across platforms is stronger on macOS, because on iOS the optimizations you're trading away (such as the native network stack scheduling requests from apps to fire while the antenna is already awake) have a bigger impact on iDevice…
Assuming your trepidation is because memory management is somehow more manual in Rust I would argue that it's actually not. This isn't something I'm saying because I want to convince you to use Rust; I'm actually of the opinion that Rust doesn't give you enough direct control of memory allocation and has iffy support for custom allocators on top.
Rust's memory management is much more like a garbage collected language in practice, hence why I consider it too indirect.
Earlier quoted context omitted.
The GUI bindings are usually the hard part.
Speaking of, does anyone know how Qt bindings for Rust are these days? Last time I looked, there were several awkward Rust APIs for Qt, suffering in part from the fact that Qt's API is inheritance-based.
Is... the name a Portlandia reference?
If you use the Cocoa API with ObjC or Swift, you get Automatic Reference Counting (ARC), generated by the compiler. I guess with this you'd have to retain / release your objects manually again?
Pretty cool project, seems like it's becoming more realistic to write cross platform native desktop applications with OS-specific GUIs in Rust. It's not too far from the write-once-run-everywhere philosophy of React native, Electron and similar. One could write their UI state and application logic once while maintaining 3 entry points using the various platform GUI bindings (gtk-rs, cacao, win32?) to represent the UI…
You can write your core application logic once and share it, but you need to have the interaction with the actual UI/window manager be per-platform. The reason electron apps are so bad on Mac is not that the core application logic is bad, it's that a whole bunch of basic Mac platform behaviors are broken.
"modern" cross platform UI toolkits are no better than Java. To paraphrase Ford: "you can do any platform you like, as long as it's windows".
[edit: to be very clear, I include "catalyst" in the cross platform toolkits that make noticeably worse apps on Mac. Trying to share a single interface "language" for different platforms just leads to what is at best mediocre UI.]