Pascal Hertleif

> could we fake it by `#[requires()]` and `#[suggests()]` being both a derive macro attribute AND a attribute proc macro? Worth looking into. I just tested a custom macro crate...

Fair enough. Unless the whole Component derive becomes a proc macro (which would be surprising to users I bet), there is no easy way to get this. Next best thing...

That’s a good idea, I’d merge in this trait :) this will add a teeny tiny bit of a runtime crate though which we’d need to add as a dependency....

#82 adds impls for `embedded_can::Frame` which has an id method. I'll go with that one :)

Added https://github.com/bevyengine/bevy/issues/14800 with a suggestion to also generate doc comments from this. (Didn't want to add this here so we can land this quicker.)

While investigating https://github.com/bevyengine/bevy/pull/13669#issuecomment-2160283863 I saw that there was chance that this method is called with a display handle that relates to a display (monitor) that was disconnected. This led to...

Thanks for looking at this! Yeah that's the error code I saw. Here is the full log with a few `dbg` calls right before the ffi calls -- it doesn't...

Sure! I did this now: ```diff + dbg!(video_mode); + dbg!(video_mode.monitor()); + dbg!(video_mode.monitor().native_identifier()); + dbg!(video_mode.monitor()); + dbg!(video_mode.native_mode.0); + let available_monitors = monitor::available_monitors(); + dbg!(available_monitors); + + let monitor = &video_mode.monitor(); +...

Rebase now. @madsmtm did you have time to look at this? Is there anything else I should check?

Just thought about this again. If it makes sense, I could change it so that instead of the `assert` we parse the return code into a proper `Result` type. Initially...