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 &WindowEvent… winit::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.