Ggez: 0.5 winit Linux and Imgui.

Created on 5 Jan 2019  路  5Comments  路  Source: ggez/ggez

Hi !
First of all, thank you for your work, this library is a real pleasure to use.
I've tried the new 0.5 rc on my Linux machine but winit failed to compile. This is the error :
error[E0004]: non-exhaustive patterns:Shape { .. }andOrientation { .. }not covered --> ...winit-0.18.0/src/platform/linux/wayland/touch.rs:30:19 | 30 | match evt { | ^^^ patternsShape { .. }andOrientation { .. }not covered
I have another question, I have for a while now made a fork to be able to access the gfx_context property of the Context struct from my game. Indeed, Imgui needs to access to initialize itself(the renderer..) with various information such as the factory, the screen_render_target, informations about the device... Do you think you will make these attributes public? Why did you only allow a "crate" access to gfx_context? I think that having the possibility to use Imgui is a real advantage for GGEZ (and according to my tests, it works very well!)

Thanks for your help,
Catvert.

Most helpful comment

The non-exhaustive patterns error is a bug in winit caused by an accidental breaking change in wayland-client. You can workaround it by adding this to the [dependencies] section of your Cargo.toml file.

[dependencies] # In this section, add:
wayland-client = "=0.21.7"

It should hopefully be fixed by tomorrow at which point the bad versions of wayland-client won't be available anymore.

All 5 comments

You should be able to access those things via https://docs.rs/ggez/0.5.0-rc.0/ggez/graphics/fn.gfx_objects.html . Is there something there that doesn't provide? If so we can add it.

The sub-context fields were made pub(crate) iirc because more of them are probably going to become trait objects in the future, so relying on them is going to be a less and less good idea. It's easy to undo but I would rather provide more abstract ways to get at the guts of ggez's implementation, for reasons exactly like this one. I'm open to suggestions though. :-)

Wow that's really great ! I didn't know there were functions like this one, it's very interesting! it solves my problem. I leave this ticket open for the other problem with the winit compilation. In any case, thank you for your help and your quick answer!

The non-exhaustive patterns error is a bug in winit caused by an accidental breaking change in wayland-client. You can workaround it by adding this to the [dependencies] section of your Cargo.toml file.

[dependencies] # In this section, add:
wayland-client = "=0.21.7"

It should hopefully be fixed by tomorrow at which point the bad versions of wayland-client won't be available anymore.

It's fixed!

Nice !
Thanks all ! :)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

t-veor picture t-veor  路  5Comments

TakWolf picture TakWolf  路  4Comments

ellipticaldoor picture ellipticaldoor  路  3Comments

eisterman picture eisterman  路  3Comments

icefoxen picture icefoxen  路  4Comments