-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WindowDescriptor added through a startup_system command always uses default WindowDescriptor from default #278
Comments
I checked and saw this on Windows 10 as well. It's also worth noting that I needed to add a ..Default::default() line after the "vsync: true" line to get it to compile. |
WindowDescriptor was updated there: #149 — hence the need for ..Default::default(). |
Try using |
If I do that it works, yes. The point was that I was trying to setup a startup resource in a startup system. If I have to initialize things outside the App builder section, what is the point of them? It's an obvious problem. I'm not looking for a way to work around the problem (though, thank you for that and it's good to note), but pointing out the issue with the current default behaviour. It seems like a case of "let's make it easy for the tutorial at the cost of functionality" since all that is needed is to not add a default window when the default plugins are added. |
Then I think you have to:
|
That fails with a panic when the render plugin tries to do a swap chain event without a window.
Which is also an issue, but a different one. This is a usability nightmare. Moving the building of a component like this shouldn't cause this many issues. |
Yeah re-registering all of the default plugins shouldn't be required for something like this. Currently the WindowDescriptor resource is just used as a "configuration item" that determines the default primary window configuration. I agree that we need more control over window settings at runtime. Right now its very "static". What this looks like (dynamically adapting to |
Well, my suggestion off the top of my head is not to create a default window. If someone doesn't want a window, they don't want a window. This should be distinctly different than 'headless' mode. A 'headless' mode means I want to pretend I've got a window...but not actually do any drawing. This is very useful in some contexts. The tutorial should definitely cover adding a primary window (and likely should cover adding a second window, perhaps to send diagnostics or use as a dual windowed program). Further, if not creating a window crashes the render system, then the render system depends on the window. This is important! We either make the render window independent of the windowing system or make it explicit how one plugin/system depends on another. Reordering the default plugin's inclusion shouldn't cause a panic. disabling any of those plugins shouldn't cause a panic. Setting them with valid options shouldn't cause a panic. |
Another bug caused by #1255. |
it's no longer possible to add |
The code below demonstrates the bug. This should create a window with the title of 'test' but instead will create one with the title of 'bevy', at least on Linux. I haven't tested this on any other platform.
The text was updated successfully, but these errors were encountered: