This decorelates the window management from the actual user content,
meaning:
- the created window no longer needs the user to draw something to
start existing
- it reduces our need to do roundtrips during initialization to
avoid protocol errors
None of the platforms that use it are supported right now, so it seems
silly to fail builds for other platforms when these ones can't possibly
succeed.
This should be reverted in stages as the platforms regain support.
* Support listing available video modes for a monitor
* Use derivative for Windows `MonitorHandle`
* Update FEATURES.md
* Fix multiline if statement
* Add documentation for `VideoMode` type
The cursor visibility docs were still outdated from the rename and
talking about setting the invisibility, rather than visibility.
The platform-specific docs are unchanged since those should be fine and
the rest has been adapted using similar docs.
* Fix request_redraw with Poll and WaitUntil(time_in_the_past) on Windows
`Window::request_redraw` now fires a `RedrawRequested` event when
called from an `Event::EventsCleared` callback while the control
flow is set to `Poll`. A control flow of `WaitUntil(resume_time)`,
will now also fire the `RedrawRequested` event when `resume_time`
is in the past.
* Prevent panic on x11 when WaitUntil(resume_time) is in the past
* Prevent panic on wayland when WaitUntil(resume_time) is in the past
* First name consistency pass. More to come!
* Remove multitouch variable (hopefully this compiles!)
* Remove CreationError::NotSupported
* Add new error handling types
* Remove `get_` prefix from getters.
This is as per the Rust naming conventions recommended in
https://rust-lang-nursery.github.io/api-guidelines/naming.html#getter-names-follow-rust-convention-c-getter
* Make changes to Window position and size function signatures
* Remove CreationError in favor of OsError
* Begin updating iOS backend
* Change MonitorHandle::outer_position to just position
* Fix build on Windows and Linux
* Add Display and Error implementations to Error types
* Attempt to fix iOS build.
I can't actually check that this works since I can't cross-compile to
iOS on a Windows machine (thanks apple :/) but this should be one of
several commits to get it working.
* Attempt to fix iOS errors, and muck up Travis to make debugging easier
* More iOS fixins
* Add Debug and Display impls to OsError
* Fix Display impl
* Fix unused code warnings and travis
* Rename set_ime_spot to set_ime_position
* Add CHANGELOG entry
* Rename set_cursor to set_cursor_icon and MouseCursor to CursorIcon
* Organize Window functions into multiple, categorized impls
* Improve clarity of function ordering and docs in EventLoop
* port ios winit el2.0 implementation to the new rust-windowing repo
* unimplemented! => unreachable
trailing comma in CFRunLoopTimerCallback
* implement get_fullscreen
* add iOS specific platform documentation. Add a TODO about how to possibly extend the iOS backend to work have methods callable from more than just the main thread
* assert that window is only dropped from the main thread
* assert_main_thread called from fewer places
The previous attempt to update parking_lot missed the windows platform.
The parking_lot dependency is now no longer specified twice to help
prevent that mistake from happening again.
This includes de-listing @francesca64 from the table, as I suggested. I
realize that this is a controversial decision, and it's not a decision I
make lightly, but I believe I have justification for doing so:
I contacted @francesca64 last month asking her about her inactivity as a
maintainer on this project. She replied on March 26th as follows. For the
sake of her privacy, I've removed removed certain sections of her response,
as it contains some personal details that I'm not comfortable sharing with
the world at large without her explicit permission.
> Hello! Thanks for reaching out!❤
> In short, I've moved on. <removed> ...in November, I was hired by a
> company that recently started using Rust. I'm very happily building
> infrastructure there!
> I'm simply not interested in spending more than 8 hours a day
> programming. You couldn't even pay me to do it! My time is best spent
> going on adventures with my beloved.
> I'll still be active in the Rust ecosystem, but only insofar as the
> company I work for is. We use winit on iOS, Android, and (to a limited
> extent) macOS, so I'll work on those backends as needed.
> Thank you for taking care of winit. I hope you're taking care of
> yourself too; <removed>.
I don't begrudge her for her decision, and others shouldn't either - I
firmly believe that, as this is unpaid, volunteer work, everybody should
have the right to move on when they decide they no longer have the time
or will to contribute.
The exact impliciation of this in regards to her status as maintainer
is open to interpretation. I would argue that this means, should she in
her work stumble upon an issue in any of her listed backends, she would be
willing to submit PRs addressing those issues. However, it also means
that she is not able to put in the time to be active as a maintainer on
those platforms, or review PRs and issues for those platforms.
On March 28th I responded to her email as follows:
> Hey, thanks for responding.
> <removed, personal details>
> In the meanwhile, there are still a few loose ends from your time as
> maintainer that I'd like to get cleaned up. It's okay if you aren't
> going to be spending much time on Winit, but there's still a broad
> assumption that you're able to review PRs for them and that doesn't seem
> to be the case. Would you be able to do a couple things to ease the
> transition to whoever next takes over the macOS, X11, and Android
> backends?
> 1) Submit a PR downgrading yourself from maintainer for macOS, X11, and
> Android, so somebody else can more actively take them over.
> 2) Post your WIP macOS backend for EL2.0 as well as the issues it
> currently has, so whoever next maintains macOS can finish it.
> Going forward, I'd like to reach out to the broader Rust community and
> find more active maintainers so Winit can get to 1.0 and I can mostly
> move on from it.
I recieved no response to that email. On April 4th, I followed up on
that email:
> If you aren't able to act as a maintainer for Winit, and aren't able to
> submit a PR updating your official status as maintainer to reflect
> reality, would you mind if I submitted a PR removing you as maintainer?
> That's not something I want to do since it's a bad image for me, a bad
> image for Winit, and sets an extremely uncomfortable precedent, but I'd
> like to start more aggressive outreach to ensure each backend is less
> dependent on one specific person and I don't want to see new
> contributors pinging you for help when you're unable to provide it.
> If you don't reply by the 11th that's the path I'm going to take, but I
> consider it the nuclear option and I want to avoid invoking it if at all
> possible.
Up to this date (April 13th), I have recieved no response. Given the
amount of time I've given her to respond, as well as her lack of
response, I believe we have the justification to remove her from the
table. Should she show back up again, any clarifications on her status
would be welcome, and she is welcome to submit a PR re-listing herself
on the table with a more accurate description of her current contributor
status. However, once we begin the contributor marketing push discussed
in #830, I don't want new contributors to attempt to ask her questions
on the macOS, X11, or Android backends when she isn't able to give a
response.
-----------------------------------------------------------------------
This PR also introduces HALL_OF_CHAMPIONS.md, which commends the efforts
of former maintainers that have contributed greatly to the Winit project.
This wasn't discussed previously, but I think it's important to recognize
the people that brought us to where we are today. It currently lists
@tomaka and @francesca64, as they are the two individuals I'm aware of
that both deserve such recognition and no longer actively contribute to
Winit, but if there's anybody I missed feel free to suggest them and a
blurb describing their work.
* Add initial draft of SCOPE document
* Rephrase/rename feature tiers
* Rename to FEATURES and add a few annotations
* Fix API Reworks table
* Add more annotations
* Some phrasing
* Split compat matrix into seperate section, to be moved into wiki
* Mention compatibility in CONTRIBUTING
* Remove some discuss annotations
* Apply review changes and rename child windows feature to popup windows
* Update based on discussion
* Add issue for Android HiDPI
* Update FEATURES.md
* Update FEATURES.md
* Update PULL_REQUEST_TEMPLATE.md
* Update PULL_REQUEST_TEMPLATE.md
* Reformat FEATURES.MD
* Remove comments
* Improve formatting and add guide for extending #Features
* Prevent the event loop from pausing after entering modal loop
After clicking the window title bar or border (for a drag or resize),
the event loop pauses until the mouse is moved. This change relays
the WM_NCLBUTTONDOWN message to the dummy window where it queues
a redraw and consumes the message. This effectively jumpstarts
the modal loop and it continues to fire draw requests.
* Handle WM_NCLBUTTONDOWN in public_window_callback instead of relaying.
Relaying the WM_NCLBUTTONDOWN message to the modal window turned out
to be unnecessary.
* Add additional numpad key mappings
Since some platforms have already used the existing `Add`, `Subtract`
and `Divide` codes to map numpad keys, the X11 and Wayland platform has
been updated to achieve parity between platforms. On macOS only the
`Subtract` numpad key had to be added.
Since the numpad key is different from the normal keys, an alternative
option would be to add new `NumpadAdd`, `NumpadSubtract` and
`NumpadDivide` actions, however I think in this case it should be fine
to map them to the same virtual key code.
* Add Numpad PageUp/Down, Home and End on Wayland
* Use `XRRGetScreenResourcesCurrent` when avail.
Signed-off-by: Hal Gentz <zegentzy@protonmail.com>
* Changelog
Signed-off-by: Hal Gentz <zegentzy@protonmail.com>
XNextEvent will block for input while holding the global Xlib mutex.
This will cause a deadlock in even the most trivial multi-threaded
application because OpenGL functions will need to hold the Xlib mutex
too.
Add EventsLoop::poll_one_event and EventsLoop::wait_for_input to provide
thread-safe functions to poll and wait events from the X11 event queue
using unix select(2) and XCheckIfEvent.
This is a somewhat ugly workaround to an ugly problem.
Fixes#779
