Skip to content
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

Add headless feature #784

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Conversation

fenjalien
Copy link

@fenjalien fenjalien commented Aug 8, 2021

Allows nannou to run apps without having to use winit to create a window. It Builds off of @dzil123 's proof of concept branch (https://github.com/dzil123/nannou/tree/headless) and provides a similar API to non-headless.

Theres still a few methods missing from the struct counterparts as I've only made whats been necessary to get things working. This is because I believe theres a more rusty way to do this. We could do this two ways:

  • Create a feature "headless".
    It would be a non-default feature that when set, the structs change to not include winit types. Methods that can't work without winit could be left in but only run the unimplemented!()macro. Also this feature could remove other modules that won't be necessarily used (like audio)
  • Use traits.

@dzil123
Copy link
Contributor

dzil123 commented Aug 10, 2021

This is a good start! I would look into the idea of merging headless::App and normal App, so that sketches can run headless without having to change the App type in function signatures. This would also help with deduplicating the Builder and Fn types.

My suggestion is to change window:Id to be an enum over winit::window::WindowId and some marker for a "headless" window (probably a usize because that's essentially what a winit WindowId is). This would also pave the way for headless windows to coexist with regular windows.

@fenjalien
Copy link
Author

I've started implementing your suggestion @dzil123 but run into a bit of a roadblock. What should the id be a key to?

I've tried using it as a key to App's window hashmap attribute but that requires a second enum over the two types of windows. To me that would be annoying to pattern match against a type I'm not even using. Having separate hashmaps still runs into the same issue due to App's window method.
A solution would be to use separate methods for each type but that would remove the idea of the id to begin with.

Any ideas on this? I think we should try to find as many options as possible.

Also what should non-headless windows be called in the enum?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants