From e531354742643d45820d0264c76816bc6248d3eb Mon Sep 17 00:00:00 2001 From: aleteoryx Date: Mon, 7 Oct 2024 16:52:37 -0400 Subject: [PATCH] more notes --- design/notes | 40 +++++++++++++++++++++++++++++----------- 1 file changed, 29 insertions(+), 11 deletions(-) diff --git a/design/notes b/design/notes index 12b8690..9b26b81 100644 --- a/design/notes +++ b/design/notes @@ -1,6 +1,13 @@ overall, this design should give no preference to any form of software or protocol. +tabs == surfaces outside of debug schemes. the WM should not reap +surfaces when a tab is advanced or closed. this is so that a history +buffer can reuse surfaces, in the same way that chromium keeps some +tab data resident in ram after advancing tabs. perhaps a mechanism for +a client to set a limit on how far back in the history it should be +before being reaped? + all dispatch should be handled within the WM, via a custom wayland protocol. @@ -129,13 +136,22 @@ maybe set it in config? the wayland: scheme is reserved for any wayland windows that aren't registered with the custom extensions. this will only work for windows that allow compositor decorations, because a launcher app should just- -work. - -wayland://by-id/... should reference an internal ID. when all tabs -mapping to a given id are closed, the corresponding protocol window -will be closed. if multiple tabs are opened with the same wayland path, -only the focused one will be rendered. this type of window is -ephemeral, and will be forgotten on reboot. +work. this should be entirely internal to the compositor, because duh. + +wayland://xdg/toplevel/... will reference an xdg_shell toplevel +surface. it should use an internaly-assigned ID. these should be opened +by default for any surface which requests server-side decorations, or +doesn't seem to provide client-side decorations. detecting this is +gonna suck. the WM should treat closing all wayland: tabs that +reference a surface as closing that window. multiple tabs should be +handled transparently to the application, and only the most recently +focused tab will be rendered. changing tabs should send a configure +event and wait for ack to actually render the new tab. + +wayland://surface/... will reference an arbitrary surface. this is +intended as a debugging facility. clients should in no way be informed +that this path is in use. the contents of the surface, if any, should +be rendered scaled within the tab. wayland://launch/...?args=... will execute the target executable with the given args. it will map to the first window created by the launched @@ -144,10 +160,12 @@ resumed on reboot. further windows created by the application are given by-id URIs. there should be a UI in place to cycle which window maps to this path. -the xorg: scheme is reserved for any xorg windows which allow WM -decorations. - -xorg://by-id/... is functionally the same as the wayland equivalent. +the xorg: scheme is reserved for any xorg windows. specific handling of +this should mirror the wayland: scheme, but this is pending on the +author's understanding of xorg. xorg://launch/...?args=... is functionally the same as the wayland equivalent. + +i need to read up on xorg more before i decide how other interfaces +should work. -- 2.45.2