[zackbrown]

Pax does solve this, but we're now discussing a different problem than element-level look-and-feel or accessibility. Three ways you can slice this with Pax, ft. pseudocode:

1. Conditional templating, like:

  <SomeLayout>
    if $is_android {
     //Only render the back button for Android
     <BackButton />
    }
    /* ... */
  </SomeLayout>

2. Dynamic properties where Rust logic checks for the target platform, like:

  <SomeElement some_property={self.get_platform_specific_value()} />

3. Maintain a separate codebase (or different specific components) for each target platform, in the spirit of React Native

Or any mix of the above.

[zamadatix]

Does this actually render a native Android back button to the canvas or are you simply saying Pax solves this by not restricting the user from making their own solution to the problem?

[zackbrown]

Pax's Android chassis isn't built yet — but a Pax `<Button>` will render an actual native Android button to a layer on top of a separate canvas layer where vector drawing occurs.

That native Android button will be affine-transformed, clipped, and occluded so that the two layers together act as a single coherent screen, and the developer can simply position / transform / layout that `<Button>` alongside, on top of, or underneath virtual / drawn elements as if they were on the same canvas.

This "dual layer" approach is already implemented for Pax's `<Text>` element on macOS (native SwiftUI `Text`) and Web (native `<div>` + HTML text) — see: https://docs.pax-lang.org/intro-example.html

[zamadatix]

This could be very interesting, I'll have to keep an eye on the development. Thanks!