Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I needed multiple windows support for simulating my embedded-graphics project, and this was the cleanest way I could think of to make it work without changing the current API. Basically, the SDL context is created once in Lazy cell from
once_cell
, which is then stored in a thread-local static RefCell, from where it can be used by the windows as required. Previously it was created when aWindow
was made and stored in theWindow
, which panics if done twice.From the user's point of view, nothing is different with a single
Window
, but now instead of a panic if you create a secondWindow
, it just works and is created as expected.Most of the change is around event handling: because all events are shared by all windows, it doesn't make a difference which
Window
you poll for events. The underlying SDL events have a "window ID" which you can match against an SDL window ID to know where they came from, but the current embedded-graphics-simulator API doesn't expose this. Instead, I have all keyboard events appear no matter whichWindow
you poll, and only mouse events related to theWindow
being polled are returned. This means mouse events on anotherWindow
are completely lost, and the end-user's code should pick a singleWindow
to poll.This seemed like a good trade-off but it does mean you can't handle multiple windows where both of them need mouse-like events -- I think that would need a slightly different API or something cleverer under-the-hood to poll SDL events and distribute them out to each
Window
. Still, for projects where zero or only one window needs mouse events, at least with these changes it's easy to have two windows.I'm more or less submitting this just where I got to with it, but i'm happy to add some more documentation or changelog entries if you'd like!