gsoc2022/ideas: Add rust winit port

[kallisti5]

No description provided.

[kallisti5]

I just stumbled across this one. It would make a great GSOC project.

It would benefit Haiku, and allow a student to focus on a rust-centric project.

[kallisti5]

See https://github.com/rust-windowing/winit/tree/master/src/platform_impl

Overall this project would be linking the winit crate to the various app_server API calls.
It seems like getting basic windowing working would be a great project since it is a lot more user-space focused.

[pulkomandy]

@nielx I thiik you have ben working on beapi bindings for rust, maybe you have some comments or extra info on this?

[kallisti5]

one more quick note, this one feels "completable" within a GSOC project.

My gut looks at other projects like "improving rust support across as many crates as you can" as more important, but projects like those are more squishy (and as we have found out in the past... "squishy" makes for bad GSOC projects since milestones aren't strong)

This one feels pretty solid since forming a set of milestones is clear:

• Add basic haiku platform support
• Successfully spawn a window with winit
• Get all the examples working

[nielx]

I like the idea, but I think there is one step missing, which is actually 'binding' to the native API. This either means automatically generate bindings to the C++ API using one of the existing tools to do that, or reimplementing the C++ API in pure Rust. I can tell from experience that the latter is going to be a hard one to solve, and should definitely be out of scope. The first would be more feasible. Any candidate must prove their understanding of memory management in C++ and in Rust, as a lot of time will be spent on preventing memory leaks and ownership issues. I do not have any experience with the bindings generator, so I actually do not know how much time should then be spent on also Rustify-ing the generated bindings.