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
* Fix incorrect keycodes when using a non-US keyboard layout.
This commit fixes the issue described in #752, and uses the advised
method to fix it.
* Style fixes
Co-Authored-By: Toqozz <toqoz@hotmail.com>
* Refactoring of macOS `virtualkeycode` fix (#752)
* Applies requested changes as per pull request discussion (#755).
* match unix common API to evl 2.0
* wayland: eventloop2.0
* make EventLoopProxy require T: 'static
* Fix linux build and tests
* wayland: update sctk & small fixes
* Rename EventsLoop and associated types to EventLoop
* Rename WindowEvent::Refresh to WindowEvent::Redraw
* Remove second thread from win32 backend
* Update run_forever to hijack thread
* Replace windows Mutex with parking_lot Mutex
* Implement new ControlFlow and associated events
* Add StartCause::Init support, timer example
* Add ability to send custom user events
* Fully invert windows control flow so win32 calls into winit's callback
* Add request_redraw
* Rename platform to platform_impl
* Rename os to platform, add Ext trait postfixes
* Add platform::desktop module with EventLoopExt::run_return
* Re-organize into module structure
* Improve documentation
* Small changes to examples
* Improve docs for run and run_return
* Change instances of "events_loop" to "event_loop"
* Rename MonitorId to MonitorHandle
* Add CHANGELOG entry
* Improve WaitUntil timer precision
* When SendEvent is called during event closure, buffer events
* Fix resize lag when waiting in some situations
* Update send test and errors that broke some examples/APIs
* Improve clarity/fix typos in docs
* Fix unreachable panic after setting ControlFlow to Poll during some RedrawRequested events.
* Fix crash when running in release mode
* Remove crossbeam dependency and make drop events work again
* Remove serde implementations from ControlFlow
* Fix 1.24.1 build
* Fix freeze when setting decorations
* Replace &EventLoop in callback with &EventLoopWindowTarget
* Document and implement Debug for EventLoopWindowTarget
* Fix some deadlocks that could occur when changing window state
* Fix thread executor not executing closure when called from non-loop thread
* Fix buffered events not getting dispatched
* Fix crash with runner refcell not getting dropped
* Address review feedback
* Fix CHANGELOG typo
* Catch panics in user callback
* Add support for generating dummy DeviceIDs and WindowIDs
* Fix linux
* Improve docs and move dummy to unsafe
* Strengthen guarantees a bit
* Add backticks to CHANGELOG.md
Co-Authored-By: Xaeroxe <xaeroxe@amethyst-engine.org>
* feat: add macos simple fullscreen
* move impl to WindowExt
* feedback: remove warning, unused file and rename param
* feedback: combine fullscreen examples into one example
* fix: ensure decorations and maximize do not toggle while in fullscreen
* fix: prevent warning on non-macos platforms
* feedback: make changelog more explicit
* fix: prevent unconditional construction of NSRect
* fix: don't try to set_simple_fullscreen if already using native fullscreen
* fix: ensure set_simple_fullscreen plays nicely with set_fullscreen
* fix: do not enter native fullscreen if simple fullscreen is active
This commit restricts an Xfwm4-specific DPI-preserving hack to Xfwm4
only. The hack saves and restores the DPI-adjusted size until the actual
size matches. On tiling WMs like i3 this fails, since the size is
constrained by the layout. This in turn causes a never-ending
XResizeWindow vs. XConfigureWindow fight between the WM and the client,
making the WM, winit client, and Xorg consume all CPU cycles available.
* Fix resize border appearing in some cases after leaving fullscreen.
* On fullscreen, save client rect instead of window rect
* Add CHANGELOG entry
* Revert test changes to fullscreen example
* Update panic message when unable to get client area
* Move the event managent to the closure
In preparation of more events not relating to the SeatManager being
captured.
* Handle wl_output remove events
In some cases, wl_outputs can be removed without the compositor
notifying the surfaces using leave/enter events. This breaks the DPI and
resize stuff since the windows' list of monitors were not updated.
Now, wl_output removals are handled and windows are updated accordingly.
* Add changelog entry for disappearing wl_outputs
* Clearer changelog message for wl_output removal changes
* Fix panic when dragging text onto a window on Windws (#697)
* Changed `panic` to `debug` (log) when unknow error occurs in `GetData` while processing a drag-drop / hover event. Plus added appropriate cursor effect if hovered item can not be processed.
* Improved code clarity.
* Add documentation to clarify behaviour of `DroppedFile`, `HoveredFile`, and `HoveredFileCancelled`
* Add period at the end of sentences in documentation.
Motivation:
This allows VirtualKeyCode variants to be stored in a BTreeSet.
Unlike HashSets, BTreeSets implement Ord and Hash, allowing them to be
keys in a {Hash|BTree}Maps. This is nice, e.g. when implementing
keyboard shortcuts functionality, which maps a set of pressed keys to
some action.
