Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Nov 17 02:42
    dannymcgee commented #1294
  • Nov 04 10:02
    mingxingren opened #1375
  • Oct 31 19:50

    kchibisov on master

    Fix context sharing EGL/GLX mis… (compare)

  • Oct 31 19:50
    kchibisov closed #1353
  • Oct 31 13:17
    maroider labeled #1374
  • Oct 31 13:17
    maroider labeled #1374
  • Oct 31 13:17
    maroider labeled #1374
  • Oct 31 13:15
    mijalk0 opened #1374
  • Oct 31 08:58

    maroider on master

    Fix crates.io badge (#1366) (compare)

  • Oct 31 08:58
    maroider closed #1366
  • Oct 28 18:34
    maroider commented #1373
  • Oct 28 18:33
    maroider labeled #1373
  • Oct 28 18:33
    maroider labeled #1373
  • Oct 28 13:38
    Prollz edited #1373
  • Oct 28 13:37
    Prollz opened #1373
  • Oct 26 10:50
    Syntaxxor commented #575
  • Oct 10 20:12
    unlimitedbacon opened #1372
  • Oct 05 16:41
    Rami-Slicer commented #1034
  • Sep 30 07:23
    maroider labeled #1371
  • Sep 30 07:02
    tronical opened #1371
Github
@_neb_github:matrix.org
[m]
rust-windowing/winit#4 : Make it compile on Linux
rust-windowing/winit#3 : PRs that need to be merged into winit
rust-windowing/winit#2 : Purge OpenGL from cocoa
rust-windowing/winit#4 : Make it compile on Linux
Github
@_neb_github:matrix.org
[m]
rust-windowing/winit#3 : PRs that need to be merged into winit
rust-windowing/winit#2 : Purge OpenGL from cocoa
rust-windowing/winit#4 : Make it compile on Linux
0x6C697370
@michaelmmacleod:matrix.org
[m]

:point_up: Edit: edit: resolved (see below)

Question about window resize events & scale factors:

I create a window that is 800x600 on a monitor with scale factor 1.0. I then click, drag, and drop the window to a different monitor with scale factor 1.5. Here's the (somewhat filtered) events in the order they get consumed by my event loop:

  1. Resized(size: 800x600) // makes sense, a resize request is sent when a window is shown for the first time
  2. ScaleFactorChanged(factor: 1.5, size: 1200x900) // makes sense, since I moved the window to a different monitor, the scale factor changes
  3. Resized(size: 800x600) // ???
  4. Resized(size: 1200x900) // makes sense, the scale factor changed which resized the window.

Why is event #3 emitted? I haven't changed the window size in the code after event #2. It seems strange to me that both #3 and #4 are sent---shouldn't only #4 be sent?

winit v0.25, Linux/x11

Github
@_neb_github:matrix.org
[m]
rust-windowing/winit#3 : PRs that need to be merged into winit
rust-windowing/winit#2 : Purge OpenGL from cocoa
rust-windowing/winit#4 : Make it compile on Linux
1 reply
arturkovacs
@arturkovacs:matrix.org
[m]
0x6C697370 referred to events in their example using hashmark followed by the event sequence number. The github bot thought these were references to gihub PRs/issues
maroider
@maroider:matrix.org
[m]
although I'm not that familiar with how ScaleFactorChanged works
AidanConnelly
@AidanConnelly
Is it supposed to be obvious how to run futures (core::future::Future, from the futures API) from within the winit event loop? Been bashing my head against this and I can't seem to figure out a way to do it
0x6C697370
@michaelmmacleod:matrix.org
[m]
@AidanConnelly: As far as I know there's no functionality for executing futures in the standard library. You've got to use an executor, like one from the futures crate. block_on is fairly easy to use: https://docs.rs/futures/0.3.17/futures/executor/fn.block_on.html, and there's more complex things there too if you need more control.
Ralith
@ralith:ralith.com
[m]
maroider: repeated emails to gentz have failed to elicit a response; might be time to abandon this room and make a new one, and get matrix.org staff to nuke the alias
maroider
@maroider:matrix.org
[m]
well, that's unfortunate
maroider
@maroider:matrix.org
[m]
if this room gets nuked, then I'd like to have a copy of the chat history available if possible
Ralith
@ralith:ralith.com
[m]
rooms proper can't be nuked, just forgotten by their participants
idk if matrix.org has a policy for room admin recovery, seems unlikely though
Lukas Bombach
@lukasbombach:matrix.org
[m]

Since I joined this room there have been some discussions which revolved around the constraints the event loop imposes on one's own implementation. I now completely get that this is how OSes work and winit is really just wrapping this in safe cross platform rust code, but I still find this unpleasant to work with (by the OSes, not by winit). Anyhow, I just found this GIST on Tokio's Gitter, which I found to be a clean enough route to deal with this

https://gist.github.com/FredrikNoren/7c3535b11e99e8fcd8dd3d55f9a934a2

I am just sharing this if anyone here finds this interesting and maybe it will be useful for the next person who needs an idea for moving control to their own code

^ this instantiates a tokio event loop that spawns a thread and goes on from there and then has winit forward all events to tokio. I'd probably select the events I would want to forward, but this seems "kind of" clean to me
But maybe I am just too much of a novice
Ralith
@ralith:ralith.com
[m]
you don't need multiple threads to accomplish that as written, fwiw, you can just move your Gpu structure into the event loop closure
Lukas Bombach
@lukasbombach:matrix.org
[m]
That is just one example. I am integrating the V8 runtime via deno in an app. V8 has its own event loop, but the main thread will be completely blocked by winit, so I need to put it in a thread there
madsmtm
@madsmtm:matrix.org
[m]
Re https://github.com/rust-windowing/winit/pull/2023#issuecomment-918497408 and others, I could consider becoming a winit maintainer at some point, but I feel I need to get my (yet private) fork of objc to a proper level first, and need to get my studies in order. Maybe in a few months
*MacOS maintainer
yuri6037
@yuri6037:matrix.org
[m]
Hi, I have some questions about winit: is this rust library able to create a window in both Win7+, Linux (Ubuntu minimum - Xorg + Waylan) and Mac?
yuri6037
@yuri6037:matrix.org
[m]
well nevermind I can't use this lib anyway: I require layout agnostic key codes. If I press Q on a AZERTY layout I want Q not A. If I press Q on any keyboard layout then I want the program to report Q not whatever key based on the QWERTY layout
maroider
@maroider:matrix.org
[m]
well, that happened
Ralith
@ralith:ralith.com
[m]
very classic
madsmtm
@madsmtm:matrix.org
[m]
And is it even true? I mean, couldn't @yuri6037 have used ReceivedCharacter(char)?
maroider
@maroider:matrix.org
[m]
they effectively wanted what we'd get once the keyboard event rework lands
madsmtm
@madsmtm:matrix.org
[m]
Yeah, fair enough
maroider
@maroider:matrix.org
[m]
I'm not sure how relevant this is for you madsmtm, but I saw some discussion in the comments on reddit about macOS/iOS bindings
madsmtm
@madsmtm:matrix.org
[m]
Thanks for the link, I'll probably talk to those people when I get some more time!
DoM
@dom__:matrix.org
[m]

Hey! I have a question about exiting the EventLoop:
I am following a tutorial on wgpu (https://sotrh.github.io/learn-wgpu/) and it uses winit 0.25
I got to the end of the Surface part (https://sotrh.github.io/learn-wgpu/beginner/tutorial2-surface/#challenge)
but when I get to *control_flow = ControlFlow::Exit the window closes but the app is still waiting in the terminal. I was unable to find the proper way to exit a winit app as anything I put after event_loop.run() is unreachable code, returning after setting the control_flow also doesn't seem to do any difference. The example code does the same, but there seems to be no explanation in the tutorial for this. Do you know what my issue may be or what i am missing?

ps I am using Linux/X11

maroider
@maroider:matrix.org
[m]

but the app is still waiting in the terminal

so you're saying the program never stops running?

DoM
DoM
@dom__:matrix.org
[m]
yeah exactly! The window seems to close properly and event handling stops, but the program never exits
maroider
@maroider:matrix.org
[m]
strange...
can you reproduce this with winit's examples?
DoM
@dom__:matrix.org
[m]
i will check, one sec...
DoM
@dom__:matrix.org
[m]
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
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
maroider
@maroider:matrix.org
[m]
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?
DoM
@dom__:matrix.org
[m]
i just used master, I'll see what v0.25.0 does
it seems to give the same result