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

x11: Destroy dropped windows; handle WM_DELETE_WINDOW #416

Merged
merged 2 commits into from
Mar 23, 2018

Commits on Mar 15, 2018

  1. x11: Destroy dropped windows; handle WM_DELETE_WINDOW

    Fixes rust-windowing#79 rust-windowing#414
    
    This changes the implementation of Drop for Window to send a WM_DELETE_WINDOW ClientMessage,
    offloading all the cleanup and window destruction to the event loop. Unsurprisingly, this
    entails that the event loop now handles WM_DELETE_WINDOW using the behavior that was
    previously contained in Window's Drop implementation, along with destroying the Window.
    Not only does this mean that dropped windows are closed, but also that clicking the × button
    on the window actually closes it now.
    
    The previous implemention of Drop was also broken, as the event loop would be (seemingly
    permenanently) frozen after its invocation. That was caused specifically by the mutex
    locking, and is no longer an issue now that the locking is done in the event loop.
    
    While I don't have full confidence that it makes sense for the Drop implementation to behave
    this way, this is nonetheless a significant improvement. The previous behavior led to
    inconsistent state, panics, and event loop breakage, along with not actually destroying the
    window.
    
    This additionally makes the assumption that users don't need Focused or CursorLeft events
    for the destroyed window, as Closed is adequate to indicate unfocus, and users may not
    expect to receive events for closed/dropped windows. In my testing, those specific events
    were sent immediately after the window was destroyed, though this sort of behavior could be
    WM-specific. I've opted to explicitly suppress those events in the case of the window no
    longer existing.
    francesca64 committed Mar 15, 2018
    Configuration menu
    Copy the full SHA
    8ef30cd View commit details
    Browse the repository at this point in the history

Commits on Mar 23, 2018

  1. Configuration menu
    Copy the full SHA
    8fa9cf5 View commit details
    Browse the repository at this point in the history