Native UI support (and other questions)

[coolbluewater]

Interesting project. A few questions, would appreciate realistic answers, because other UI crate owners in my experience often respond with "everything is possible" which is not helpful,

1. Is the goal to have only (or primarily) custom-rendered widgets a la flutter?
2. The release build binary size of the storybook example is 19MB, which is super excessive. Why is this?
3. Can a user control custom render itself to wgpu? Can such a control receive input events and IME events?
4. Why is the list widget named Lists (plural)?

Thanks!

[Adoo]

@coolbluewater

1. I'm not quite sure what you mean by "custom-rendered widgets like Flutter". Could you provide more details?

2. By removing debug=true and using the configuration below in Cargo.toml, the binary size is reduced to about 9.2MB on Ubuntu 20.04.

[profile.release]
opt-level = "z" 
lto = true
strip = true  # Automatically strip symbols from the binary.

This size is still large. We haven't deeply analyzed the binary size yet, but I think it's partly because we include all theme resources, like icons and fonts, in the binary. Some dependencies also have a large size. We hope to reduce the binary size by the time we release version 1.0, but it's not our main focus right now.

3. No, Ribir provides a painter for drawing 2D elements, but it doesn't expose the wgpu context to the user. Ribir is backend-agnostic for rendering. We might provide two ways to handle 3D elements in the future, but we don't have a timeline for this yet.

   • A high-level widget that supports shaders, but not only for wgpu.
   • Users have the opportunity to assemble the Ribir frame. If they opt for the wgpu backend, they can directly manage the wgpu outside of Ribir and combine its render with the Ribir frame.

4. The term "Lists" is just a typo. All widgets are currently in a rough state, and we plan to polish them in version 0.4 or 0.5.

[coolbluewater]

Thanks!

1. I mean, do all widgets have to be drawn by Ribir, or is there a way of using, e.g. native buttons (such as NSButton on macOS)?
2. The 19MB size was a release build on macOS. It's a bit concerning if we don't know why the binaries are so large. It's possible that the API itself may be contributing to bloat due to monomorphization. At this point the Ribir code base is large enough (50kloc) that it's worth investigating without delay to avoid churning the core API down the road.
3. Is input method (IME) and accessibility support planned? I notice that keyboard navigation does not work.

Is there a roadmap document? That and some better docs would really help. Many UI libraries don't put enough effort into a roadmap and documentation, that's a huge mistake IMO.

[Adoo]

1. Yes, Ribir draws all widgets itself.
2. Remove the Debug and strip the symbols, the size will be 9.2M, we do a very simple analysis before, resource and dependencies are the main reason if I not remember wrong. Yes, we need to finish it before 1.0, maybe in 0.6 or later, we will metrics fps, memory used, Binary size and so on, and trace by ci.
3. Yes, IME support, accessibility not yet. Keyboard navigation is supported in the core, but not configured in the widgets.

We have a roadmap, just list we will do in the next one or two versions. See ./ROADMAP.md.

I totally agree with you, we need to improve the documentation, and we will forwoard a step in every version.