-
Notifications
You must be signed in to change notification settings - Fork 904
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
RFC: Window
redesign to allow for other surface roles
#3928
Comments
Window
redesignWindow
redesign to allow for other surface roles
I'd add that the suggested design was iterated multiple times and kind of how it'll be with 0.31(though thanks for writing rough idea of it down), but there's still a long way to go. The main issue as of now, is not how to structure, but how event routing should work, which is not entirely clear and re-using Anyway, this is all actionable after the split is done, since all of the ID/monitor types are not general enough. I'm also not sure whether to keep this open given that it's a meta issue based on other issues we have around, but I guess I keep for now. |
And I'll add that what you define as "surface" here is closer to a "widget" in other UI frameworks (for example So I'd probably prefer that name. |
Wayland and Vulkan use "surface" in that sense, so that's where I took the name from. A widget, to me, implies a rectangular area within a window, managed by the UI framework and not the window manager. |
I also don't like One could also use the word |
The simplest solution would just be to pass each event to the relevant |
yeah, some do bubling, like macOS. |
Edited the proposal to account for this. We can simply disable it on MacOS/X11 where it is supported; those platforms could eventually have this re-enabled on a platform basis. |
I started a draft PR on the initial part of this redesign (splitting |
This PR splits some methods of Window into a new supertrait Surface, laying groundwork for the implementation of rust-windowing#3928. As stated there, this split is needed because popups and subsurfaces may not necessarily allow the same operations as windows.
Description
This proposal addresses #159, #343, and #3506.
Definitions
The below model of surfaces, windows, etc. is heavily inspired by Wayland; though it maps well to other platforms.
Window manager
For the purpose of this design proposal, the window manager (abbreviated WM) is software that handles the positioning, compositing, and display of surfaces. This is equivalent to X11 server and window manager on X11 and the compositor on Wayland.
Surface
A surface is a rectangular buffer owned by the window manager that can be drawn to, and is usually displayed on screen in some fashion. Not all surfaces can be positioned programmatically; for some window managers this is purely by design (i.e. Wayland). Functions and properties common to most surfaces include:
Generally, window managers support different roles for surfaces, which govern their lifetime and purpose. Most window managers can define the roles of window, popup, and subview.
Platform equivalents:
HWND
NSView
?XID
wl_surface
Window
A window is a long-lived surface that can be positioned by the user. They can also be stacked or tiled as the window manager deems appropriate. Functions and properties unique to windows include:
Platform equivalents:
WS_OVERLAPPEDWINDOW
NSWindow
xdg_toplevel
Popup
A popup is a short-lived surface bound to a window that disappears when unfocused. They are generally used to implement context menus and tooltips. Functions and properties unique to popups include:
the ability to be repositioned
the ability to steal focus from its parent window
Windows:
WS_POPUPWINDOW
MacOS:
NSWindow
, with additional settings:[window setDecorated:NO]; [window setExcludedFromWindowsMenu:YES]; [window setLevel:NSPopUpMenuWindowLevel];
X11: override-redirect/save-under window, no decorations
Wayland:
xdg_popup
Subview
A subview is a long-lived surface bound to some other surface, be it a window, popup, or even another subview. They are generally clipped to their parent surface. Functions and properties unique to subviews include:
Platform equivalents:
WS_CHILD
NSView
wl_subsurface
, usewp_viewporter
protocol to clip outputStructure
The existing
Window
trait should be split into two separate traits:Surface
representing the common functionality, andWindow
representing functionality specific to top-level windows. This opens up room for traits likePopup
orSubview
. The existingWindowId
class would be renamed toSurfaceId
for consistency, though it could exist as a deprecated alias during a transition period.The trait hierarchy would look something like this:
Ideally, the
Surface::as_surface
/Surface::as_surface_mut
are obsoleted once trait upcasting is stabilized.Event handling
Changelog
Relevant platforms
Windows, macOS, Wayland, X11
The text was updated successfully, but these errors were encountered: