On Wayland, fix invalid offsets being sent in Preedit

[kchibisov]

Even when the protocol explicitly tells to send proper UTF-8 boundaries for cursor, some IMEs don't do that, so sanity check them before sending downstream.

• Tested on all platforms changed
• Added an entry to CHANGELOG.md if knowledge of this change could be valuable to users
• Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior
• Created or updated an example program if it would help users understand this functionality
• Updated feature matrix, if new features were added or implemented

[kchibisov]

@MarijnS95 Do you know why CI on android fails?

[MarijnS95]

@kchibisov a new cargo-apk version was released yesterday with updated dependencies, one of them with a higher MSRV than winit.

[kchibisov]

@MarijnS95 I mean stable and nightly also fails, so it's not MSRV only thing.

[MarijnS95]

@kchibisov Ah right, I didn't open/read all the failed jobs on mobile.

This happens because we switched from a manual argument parser to clap, and foresaw residual arguments in cargo apk -- being one potential limiting factor.

My yank permissions seem to be gone but feel free to pull the 0.9.5 crate off of crates.io to unblock everyone while I patch residual argument support back in (don't think it's reasonable to support all arguments one could possibly pass to any cargo subcommand).

At the same time we have to discuss the MSRV bump for implied by quick-xml, don't think it really matters since cargo-apk is a host tool, but the CI here needs to be updated to install it on stable?

[kchibisov]

My yank permissions seem to be gone but feel free to pull the 0.9.5 crate off of crates.io to unblock everyone while I patch residual argument support back in (don't think it's reasonable to support all arguments one could possibly pass to any cargo subcommand).

I don't quite understand, ping me on matrix wrt that please, it's likely some crate outside the winit umbrella, since you should have perms for publishing to winit stuff.

new cargo-apk version was released yesterday

Can we use old version for the time being? It's not like we really need new one, given that we simply check that something builds?

[MarijnS95]

I don't quite understand, ping me on matrix wrt that please, it's likely some crate outside the winit umbrella, since you should have perms for publishing to winit stuff.

It is a rust-windowing crate: https://crates.io/crates/cargo-apk - I'm part of the Publishers team yet no yank button shows up for me.

new cargo-apk version was released yesterday

Can we use old version for the time being? It's not like we really need new one, given that we simply check that something builds?

I rather not hack in a fixed version for winit (which has to be reverted at some point to not be stuck at an older version), intentionally circumventing a known-broken version of cargo-apk which users won't be able to repro the CI build with locally. On the other hand it's only the magical cargo apk -- that doesn't support additional arguments, for example --no-deps for doc.

[kchibisov]

It is a rust-windowing crate: https://crates.io/crates/cargo-apk - I'm part of the Publishers team yet no yank button shows up for me.

Yank from CLI, I'm not sure I ever seen a UI for that.

[kchibisov]

@MarijnS95 I've yanked the 0.9.5 version, but be aware that you can also to that with cargo yank as well as ndk-build, since it was a breaking change, and I wasn't able to use ndk-build 0.8.1.

[MarijnS95]

@kchibisov There's UI for it, but it only seems to show when directly owning (being invited to) a crate, rather than being part of one of the teams on GitHub. That said the command succeeds for me even though you already yanked it, so it should be alright permission-wise.

I'll take to the NDK repo and see how to resolve this situation, but it's going to take some time. I might backport and publish just the change that this particular release was requested for, and leave the crate upgrades / code improvements simmer a bit longer.

[kchibisov]

Yeah, that's fine. Also if you do a breaking bump, like you did, don't mask it with patch version. Since cargo-apk 0.9.4 was not compatible with ndk-build 0.8.1, meaning that the change from 0.8.0 to 0.8.1 were breaking, breaking semver.

[MarijnS95]

@kchibisov You basically mean: please install one of the tools available to test for semver compatibility (on the CI), because, Q.E.D., it is impossible for a human on their own to keep track of it all the time?

[kchibisov]

I mean if you're not sure that something is compatible then do a breaking bump, but in general you can bump version before hand or add **Breaking** changes in a changelog, so you know how to bump. Besides that, if you have issues with infra, ect, you can reach me on irc(be aware that you might be kicked for idling for 30 days).

[MarijnS95]

I mean if you're not sure that something is compatible then do a breaking bump

As said, it was a misjudgment.

but in general you can bump version before hand or add **Breaking** changes in a changelog, so you know how to bump.

The latter is what android-ndk-rs always does, but I have to proactively notice it in every PR. This was one of the few PRs where I didn't, and added a changelog item - again, without double-checking breakage - after the fact.

Besides that, if you have issues with infra, ect

android-ndk-rs only has trouble with lack of, or exodus of maintainers.

(be aware that you might be kicked for idling for 30 days)

That seems to have happened on me for the winit Matrix channel.