You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 15, 2024. It is now read-only.
Symptom: the shello example runs fine, but hangs on exit.
Apparent cause: the X11 backend destroys a window before user state (handler) gets destroyed. This is potentially a problem because that user state may include stuff which depends on the window. At least, I appear to be hitting this issue:
We rely on user applications to handle destruction in the correct order, despite this being a cross-platform API and the requirement only being present on one platform (X11)
The alternative would be to keep the X11 window alive until after user state (handler) has been destroyed. This can't simply be done from backend::x11::window::Window::destroy since self.handler is borrowed when this method is called so further redesign would be needed (e.g. ensure the user state is destroyed immediately after handle_destroy_notify is called).
There is a further complication in that user state may hold a copy of a WindowHandle, which contains a Weak reference to the window object. I wonder whether further design changes are sensible:
Pass handle: &WindowHandle into all methods of WinHandler, remove Clone impl
Application::clipboard returns a temporary (non-Clone) object Clipboard<'_>
The text was updated successfully, but these errors were encountered:
Symptom: the
shello
example runs fine, but hangs on exit.Apparent cause: the X11 backend destroys a window before user state (
handler
) gets destroyed. This is potentially a problem because that user state may include stuff which depends on the window. At least, I appear to be hitting this issue:So to fix this, naively, we need to destroy the
RenderSurface
before the window, like this:... but there are two problems here:
Surface
is the only part which is window-specific)The alternative would be to keep the X11 window alive until after user state (
handler
) has been destroyed. This can't simply be done frombackend::x11::window::Window::destroy
sinceself.handler
is borrowed when this method is called so further redesign would be needed (e.g. ensure the user state is destroyed immediately afterhandle_destroy_notify
is called).There is a further complication in that user state may hold a copy of a
WindowHandle
, which contains aWeak
reference to the window object. I wonder whether further design changes are sensible:handle: &WindowHandle
into all methods ofWinHandler
, removeClone
implApplication::clipboard
returns a temporary (non-Clone) objectClipboard<'_>
The text was updated successfully, but these errors were encountered: