imo a simple etherpad would be sufficient and a little bit less headache
not rely on native component
When I think about reimplementing e.g. textarea with all its features (accessibility, right-to-left languages support, selection, navigation, etc) it freaks me out. I hope you know what you are doing as I have little experience with this level of GUI. As far as I understand, you need a canvas / window handler created by a "native framework" to be able to put a "native component" on it.
The Redox community has been making some pretty big strides on teasing out what a Rust GUI TK should look like.
That's why I mentioned Conrod.
I think a design like this decouples the application logic and model from the rendering of the UI in a much cleaner fashion that traditional UI frameworks.
Also, with modern rendering through the GPU, it takes more time (usually) to figure out expose events and what needs to be repainted than just repainting and compositing everything (or so Servo has seemed to have discovered).
so, just to understand that properly. a text field in conrod is just a pretty box plus a &str. The actually owned string lives somewhere in the application model. editing the text box sends an insert event, the eventloop matches on that, change the String that the text fields &str points to und somewhere later on a new frame the text field is repainted
Also, I think this sort of de-coupling will largely solve issues like, "How to handle I18n and Accessibility" as those crates/libraries could be developed independent of the UI and could even be designed to work with text input at the command-line (readline like) and/or text widgets (ncurses/forms-like).
This spreads out that sort of development responsibility better in the Rust community.
Yes, I believe your understanding of Conrod is correct.
Though, to be clear, I'm not an expert on Conrod. It is just something I've come across in looking into what was already in progress/existing that seems promising.