What versions of winit and wgpu do which versions of iced use?

Short version of question: I need a version of iced which is compatible with winit 0.29, how can I get this?

Long version:

I am attempting to add iced support into an existing wgpu application (if it helps, it’s here. I am following the “integration” example from iced 0.10. It appears that iced works with winit and wgpu, but the way it wants you to use each is to use the “vended” winit and wgpu (such as iced_wgpu::wgpu)¹. However, with wgpu, using the “vended” version is impractical for my use case¹, and with winit, it is not possible².

Therefore it appears the only way for me to use iced, especially if I want to do the things the “integration” example does, is for my Cargo.toml to exactly match the versions of winit and wgpu that iced wants. (If I do not do this, I get many cryptic errors containing "have similar names, but are actually distinct types"³). However, I cannot figure out what these are. It does not appear to be documented. From the error messages I’m getting, it appears the version of wgpu linked to iced 0.10.0 is 0.16.3 and the version of winit is 0.28.7. I was able to downgrade my wgpu to 0.16 fairly easily, but downgrading from 0.29 to 0.28 is a much bigger imposition⁴.

I have multiple questions.

  • Is it somewhere documented which versions of the related libraries (winit, wgpu) that each version of iced uses? Ideally there would be a table like "use iced 0.10 for winit X wgpu Y, use current trunk for winit Q wgpu P). (If not, I will probably file a github issue asking this be added to the documentation.)

  • Which Iced/At what future point should I expect Iced to work with winit 0.29 or later? (I am looking through your Cargo.tomls and have not yet figured this out). What winit is trunk using?

  • Could the version incompatibility ergonomics be better? Right now the only way to tell you do/don’t have the correct connected is to use the library, and eventually (not immediately, weirdly) there will be a type mismatch and you’ll be able to pick out the library version Iced wanted you to use from the error message. To me it would be better if there were a way to request an iced feature --unvended-library, which would cause iced to use the app’s main winit/wgpu instead of bundling its own, and if that version is incompatible throw an error early instead of waiting for a type mismatch. Is this idea possible enough it’s worth filing a github feature request?

  • This all seems very inconvenient. Is there something I am missing that would make it easier?

¹ My use case is I am writing graphics demos/games, and I wish to add iced support for debug UIs; that is, I will not be shipping Iced in the final product, but while developing the game I will be adding debug overlays to tweak things. This means iced will be behind a --feature (in the current application linked above, it’s behind a --feature and in a special branch). This means my base code must be able to compile without iced and cannot simply import iced’s versions of winit/wgpu.

² The “integration” example uses winit directly, not an iced_winit::winit or whatever. So unless I am missing something, it is simply necessary for my app to match iced’s version of winit.

³ Following the Integration example against Winit 0.29, “ModifiersEvent” seems to have been replaced with a new class named “Modifiers”, and iced_winit::conversion::window_event fails with “expected &WindowEvent<'_>, found &WindowEventwinit::event::WindowEvent and WindowEvent<'_> have similar names, but are actually distinct types”.

⁴ There is a specific 0.29-specific PR that I must have in order for my wasm target to work at all.

There isn’t anything like that. We don’t offer support for old versions, so users should use either the latest release or master.

The latest iced_winit release uses winit 0.28, but in master we use our own fork with additional features (custom URL schema handling). In any case, I have plans to work on updating winit soon.

Probably! But generally, if a crate has the name of another crate in its name, it’s reasonable to expect that the crate is an extension of the original one; and therefore requires versions to match. In other words, their public APIs use types of the original crate. This is why both iced_wgpu and iced_winit expose winit and wgpu, respectively.

Remember that you can always check the specific dependencies of a crate in crates.io.

I totally understand. I am afraid you are using iced for a use case that hasn’t received much attention yet!

We have been mostly focused on the happy path: relying on iced directly to build standalone applications. And that is quite the experimental path already! Everything else is considered very advanced stuff, so the inconveniences you are experiencing are not surprising.

It is certainly possible to build your own runtime loop on top of iced_runtime directly without relying on iced_winit, though. But it’s a bunch of work and I can’t guarantee it will be less frustrating. I imagine certain ideas need to adapt to support the use case properly.

egui seems to be a quite popular solution for use cases like yours! Have you considered using it instead? Or is there something particular to iced that you want to use?

Hm, okay. Let me try a different angle.

The thing I need, ultimately, is the ability to make an app that sometimes uses Iced and sometimes does not (split on things like feature or branch). In the non-Iced branch it would be ideal to not have to import iced or unnecessary packages specific to Iced. I was trying to do this by forcing iced to use the same packages I was already importing outside Iced, but if that’s not possible— what about the opposite?

Would it be possible in some future world for there to be crates for just iced_wgpu::wgpu and iced_winit::winit? That is, get those two re-exports or something equivalent to those two re-exports but without having to take in the iced_wgpu and iced_winit support packages. That way, in the non-iced branch I would already be using iced’s specific versions/forks, and in the iced branch I could just turn the rest of iced on. I don’t know how complicated it would be at your end to enable that.

(Alternately, maybe iced_wgpu and iced_winit turn out to be low-weight and just get tree-shaken out if I have them in my Cargo.toml but I only use the ::wgpu and::winit subpackages out of them?)

egui seems to be a quite popular solution for use cases like yours! Have you considered using it instead?

Several people recommended it to me, yeah. I was going for iced first because egui has no wgpu integration example (they have an opengl integration example that theoretically could be reworked into a wgpu integration example, so maybe I should just try that…)

Why isn’t this possible? You just need to make sure the versions match.