Is it a backend library for Slint?
No. This is rust bindings to the native apple UI toolkits, UIKit and AppKit (on iOS and macos respectively). Using a library like this, your software will have a fully native look and feel. The result should be indistinguishable from the equivalent Swift or Obj-C app from the point of view of a user. Including all accessibility hooks, fully native widgets and things like that. The downside is that code written agains…
macOS Apps in Rust
31–40 of 89 posts
Re: macOS Apps in Rust
#32Earlier quoted context omitted.
I think it's pretty difficult mapping the Qt memory management model to Rust, for the same reason we haven't seen working Golang bindings for Qt either. I have some experience with the Python bindings (PySide or PyQt) and both of them use pretty extensive wrapper generator frameworks specially developed for the task (SIP in the case of PyQt, Shiboken in the case of PySide), coming up with something like that is not a…
> https://github.com/therecipe/qt Do these not work? (Not a rhetorical question - I haven’t tried them.)
The project also seems dead since 2020 or so, a current fork is https://github.com/bluszcz/cutego/ But I haven't tried that one.
Re: macOS Apps in Rust
#33Pretty 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't write good UI apps with cross platform code. The basic idioms of each platform are different. 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"…
Re: macOS Apps in Rust
#34Re: macOS Apps in Rust
#35A tangent: does anyone have recommendations for a library for easy Swift-Rust interop? This is a cool tool, but I’d much rather make a GUI natively with e.g. SwiftUI and then call out to Rust for business logic. The previous times I’ve looked into this, both languages had to communicate through a C intermediate, and handling more complex types became a chore…
Re: macOS Apps in Rust
#36Earlier quoted context omitted.
You can't write good UI apps with cross platform code. The basic idioms of each platform are different. 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 toolkits are a way of getting something good enough, quickly. Our standards may be different, but I would say you can get something good. You likely won’t get something great though. I agree with your statement about modern toolkits being no better than Java, but Java is pretty good. I’d have no problem starting a new project with it today. All that said, I’d much rather have a well written native appl…
https://www.oreilly.com/library/view/filthy-rich-clients/978...
Re: macOS Apps in Rust
#37If 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?
Rust has ARC too so I very much doubt it.
Re: macOS Apps in Rust
#38If 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?
No. Rust has RAII so you can have retain on 'clone' operations and release on drops, just like the native Rc/Arc types do. This is, incidentally, how the servo bindings to core-foundation work (I prefer those bindings where there is overlap). Servo bindings: https://github.com/servo/core-foundation-rs Other crates of interest on this topic: - https://crates.io/crates/objc - https://crates.io/crates/block
Re: macOS Apps in Rust
#39A tangent: does anyone have recommendations for a library for easy Swift-Rust interop? This is a cool tool, but I’d much rather make a GUI natively with e.g. SwiftUI and then call out to Rust for business logic. The previous times I’ve looked into this, both languages had to communicate through a C intermediate, and handling more complex types became a chore…
Re: macOS Apps in Rust
#40Earlier quoted context omitted.
> https://github.com/therecipe/qt Do these not work? (Not a rhetorical question - I haven’t tried them.)
They used to work until the big modules change a few golang releases ago. Now, nothing works anymore unless you exhume a sufficiently old golang compiler. The project also seems dead since 2020 or so, a current fork is https://github.com/bluszcz/cutego/ But I haven't tried that one.
If you just want to pretend modules never happened, then export GO111MODULE=off and use the latest Go compiler.