Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 11:29

    kchibisov on master

    fix changelog entry for release (compare)

  • 11:29
    kchibisov closed #1380
  • 11:29
    kchibisov opened #1380
  • 11:14

    kchibisov on v0.28.0

    (compare)

  • 11:11

    kchibisov on master

    Glutin version v0.28.0 (compare)

  • 11:11
    kchibisov closed #1377
  • 10:49
    kchibisov synchronize #1377
  • 10:36
    kchibisov commented #1379
  • Dec 01 23:31
    chrisduerr commented #1379
  • Dec 01 23:29
    maroider commented #1379
  • Dec 01 23:27
    maroider opened #1379
  • Dec 01 23:26

    maroider on update-contact-links

    Update contact links (compare)

  • Dec 01 12:35

    kchibisov on master

    Update winit dependency to v0.2… (compare)

  • Dec 01 12:34
    kchibisov closed #1378
  • Dec 01 12:27
    kchibisov synchronize #1378
  • Dec 01 12:19
    kchibisov opened #1378
  • Dec 01 12:14
    kchibisov synchronize #1377
  • Dec 01 12:06
    kchibisov opened #1377
  • Dec 01 00:44
    RpxdYTX commented #913
  • Dec 01 00:43
    RpxdYTX commented #913
maroider
@maroider:matrix.org
[m]
so am I
having permanently open browser tabs for these services like I've done until now just invites distraction, as I'll compulsively check them
josh
@joshyrobot:matrix.org
[m]
how would i go about debugging winit? currently it doesnt spawn any window (with x11 or wayland backend) and the event loop is a constant stream of redraw requests
2 replies
arturkovacs
@arturkovacs:matrix.org
[m]
You could clone the winit repo to get the source, then you should git checkout v0.25.0 or whichever version you are using. Then you should change the dependency in your project from winit = "0.25" to winit = { path = "/path/to/winit"}.
Now you can add printlns or use your preferred debugging tools on your local winit see what the code does
0x6C697370
@michaelmmacleod:matrix.org
[m]

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

2 replies
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
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...