Diggory Hardy

So we have to go with the most limited API and provide bogus data to everything else? How about allowing a capability/data mis-match, but filling in bogus data on only...

So the purpose is to prevent mis-use of a feature which likely isn't going to be well tested... perhaps a good idea, though it's still easy enough to write a...

> We certainly can fill bogus data and log warnings if you do so instead of hard failing in those builders. This has ~~two~~ three advantages: - A nicer API...

Ultimately the biggest issue remains that *many* devs have no idea how to use/test IME and accessibility tools. I've installed IBus, but there's no configuration to use IME with English...

So, I read [the Wayland `zwp_text_input_v3` protocol](https://wayland.app/protocols/text-input-unstable-v3). Are `hint` and `purpose` expected to change or allowed to remain constant? The inclusion in `ImeRequest::Update` hints that they are allowed to change....

Regarding hint and purpose, they do not look like the kind of thing which *should* change, but if this assumption proves to be wrong then the API can be extended...

@dcz-self you make a good argument for the initial provision of size and position. But, considering the protocol requires that surrounding-text be double-buffered, I believe I have a good argument...

> All of those are Options. [..] Perhaps this should be communicated better Yes — in particular, that `fn request_ime_update` aggregates all types of request behind a single method with...

Enablement is confirmed by `Ime::Enabled`, so `enable` does not need to return an error at all. There is a small benefit to this design: encourage users to react to the...

> Squeekboard supports the current protocol version, but it only inputs events. I created my own SUPER MESSY demo IME for ongoing development: https://codeberg.org/dcz/stiwri although I think I never implemented...