Welcome to tomaka/glutin, the official gitter channel for Glutin and Winit! - Github: https://github.com/rust-windowing/glutin, https://github.com/rust-windowing/winit - Crates.io: https://crates.io/crates/glutin, https://crates.io/crates/winit - Docs: https://docs.rs/glutin/0.21.0/glutin, https://docs.rs/winit/0.20.0/winit/
but the app is still waiting in the terminal
so you're saying the program never stops running?
yeah exactly! The window seems to close properly and event handling stops, but the program never exits
can you reproduce this with winit's examples?
hmmm the control_flow example seems to work and i see that it is different in many ways, but i'm not really sure which change is the culprit
though one thing that sticks out is that the last three events are:
MainEventsCleared
RedrawEventsCleared
LoopDestroyed
though one thing that sticks out is that the last three events are:
MainEventsCleared
RedrawEventsCleared
LoopDestroyed
Is it possible that if I exit the loop without clearing the events the program just freezes? I never saw any mention of this before but i am pretty new to winit
no, you don't have to do any work in order to drain events from the platform's queue
winit does that for you
did you check out
v0.25.0 or did you just use master?
it seems to give the same result
i can type into the terminal but it doesn't stop until i kill it with ctrl + c
i guess it was a wgpu issue then
1 reply
maroider: idk how winit works wrt reviewing, is there any chance of rust-windowing/winit#2025 getting in before the 0.26 release?
1 reply
👋 I'm trying to build the wgpu "just open a window" example from here: https://sotrh.github.io/learn-wgpu/beginner/tutorial1-window/
But when I run it, no window actually appears. It doesn't crash, and I do see it in the list of applications running. Just no window
3 replies
I suspect this is because I'm using Wayland via EGLStreams (thanks NVIDIA), and I understand Wayland is enabled by default for winit. Can I force winit to use X11 (and thus go via XWayland) somehow to see if that helps matters?
1 reply
but the PR seems fairly simple, so it shouldn't be too hard to get it merged in practice
no, it's not wrong per se
if proceeding to the next part of the tutorial doesn't work, then you can assume something is wrong
All this does is create a window, and keep it open until user closes it, or presses escape. Next tutorial we'll actually start using wgpu!
I mean, is this part wrong?
cwfitzgerald: I'll see if I can't take a look at it in the next couple of days. I have IRL stuff that urgently needs doing, but I think I can put aside enough time for this.
1 reply
No real urgency on this, just would like to get it on for 0.26 as using grab is currently broken without it
And it also looks like GNOME Screenshot spares you winit's beautiful CSD
IIRC, winit is going to lose its built-in CSD in the next release, so I suppose the screenshot accurately represents the near future for GNOME users
1 reply
any built-in CSD support has been removed, and I don't know if or when libdecor support might be added
1 reply
winit's current Wayland maintainer doesn't seem to want to work around GNOME being "special" and not supporting server-side decorations, and idk how prioritized the issue is upstream (ie. in
smithay-client-toolkit, which is where winit used to get the CSD from).
1 reply
Also, libdecor support is pretty high on the toto-list of SCTK. However, it is a hobby project done by a single person, so the bottleneck is time that can be allocated to it.
it's a bug that winit is emitting LoopDestroyed Events at the end of each call to run_return on macOS, right