1 files changed, 29 insertions(+), 11 deletions(-)

M 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.