Should the map be controlled from rust or from higher level languages?

[bchapuis]

The map is currently controlled by handling the user inputs with Rust (e.g. pan, pinch, shift, tilt and zoom handlers). Would it make sense to provide an api to control the map (moveTo, zoomTo, etc.) and delegate the control of the inputs to higher level languages (i.e. js, swift, kotlin, etc.)? The expectations in terms of user experience may vary a lot from one environment to the other (e.g. mobile, desktop, web, embed, navigation system, etc.).

[maxammann]

I discussed this shortly with somebody in a wgpu channel on matrix. Right now there is ready-to-go solution for both approaches.

Pro "Handling in Rust":

• More portable
• More flexibility in terms of supported gestures

Pro "Handling in Platform SDK":

• Requires SDK bindings
• "Feels" better and more correct
• Does not require winit

Right now we use winit which is quite unstable from my perspective. In the long run, either this library needs to be more stable, or we should stop using it.

[maxammann]

There is also a fork from winit: https://github.com/tauri-apps/tao

[DerKarlos]

The actual control is just a default example and both, renderer and control are called by app examples.
The map rendering and the controls could be in separate crates. So the user may write controls however he/she likes.
The render crate needs an API of course.
For a native generation for Linux/Mac/Windows there are tools to link a rust crate to other languages.
What about Web-WASM? A .wasm needs an JS wrapper. Does Rust-Wasm support this?