Path to support labels, text, images, etc in iOS about cacao HOT 7 OPEN

I threw together a basic Architecture document - not perfect by any means, but it walks (or stumbles) through the View<T> type to kind of explain how things are typically set up. Can try to find time to flesh it out more.

from cacao.

Cool, I can look at setting something up today.

Tauri apps might be hard on tvOS, if I'm understanding (at a glance) what you want to do, as no WebView is supported there. It's by far the least explored platform for Cacao though, so plenty of time to dig further anyway.

from cacao.

Unfortunately the iOS demo is (for the moment) barebones, yeah - it was mostly done first to make sure I could even support the UIScene+Delegate APIs that modern iOS needs, which was tricky to figure out how to do.

The good news is that from here on out adapting things shouldn't be too bad. I'm guessing the feature flags you hit were the target_os = "macos" ones in lib.rs? If so, yeah - that's mostly just to gate things so the iOS demo compiled, and it acts as a marker for what's support across the two.

If you want to jump in, the text module is probably the most straightforward to make compatible with iOS. It'd really come down to two things needing to be done:

• If the target's iOS, just call UIFont instead of NSFont. No docs in front of me but the initializers should be common enough that I think this'll just work.
• Add a label/ios.rs, which currently could be a clone of label/macos.rs but with swapped class names.
• Update label/mod.rs to support UILabel, which with how it's currently set up, would mostly (I think) just be calling something other than stringValue.

Images are also theoretically decent to start with, but there's a custom draw handler I added and the API for that is slightly different across OS's so I might want to revisit it. Not sure.

I think an architecture.md is a great idea - I'm in moreso docs writing mode right now anyway so it fits in. If I can find some time this afternoon I'll get it added.

from cacao.

Oh, and:

Also, is there a obj-c spec you're working off of or just using your ios/macos dev experience to know which NS concepts to bridge over?

Ish, yeah. I've been aiming for somewhat of a "common" API between the two OS's for two reasons:

• I think eventually Swift/UI will be the blessed path for Apple's ecosystem, and anything that's ultra confusing is just a negative in comparison.
• Each control should always expose an objc property that can be unsafely message passed to directly if need be, so people can drop to the underlying ObjC level and do anything not covered.
• I'm wagering that anybody who needs or wants the nuances of AppKit vs UIKit would be looking at writing separately in ObjC or Swift anyway. Gonna guess that Rust users would prefer the "one damn API" approach first with the option for flexibility.

I'd say that in general I try to err towards the iOS-style methods, since I think people are more familiar with those.

tl;dr yeah, a lot of it is my personal experience with ios/macos/tvos experience, but I'm pretty open to whatever. If it's helpful I suppose I could put together a channel somewhere for more discussion on this?

from cacao.

I could put together a channel somewhere for more discussion on this?

I would be interested to join! We are looking to build @tauri-apps for iOS/tvOS and maybe migrate our wry macOS implementation.

btw; amazing work!

from cacao.

FWIW, #48 adds image support for iOS. I would be curious what "core controls" people would need/want supported on iOS so that shoring up that side of things could happen.

(I know this issue is old, so apologies for raising a zombie here)

from cacao.

(#48 has been merged)

from cacao.