1 files changed, 32 insertions(+), 0 deletions(-)

M design/notes

@@ 119,3 119,35 @@ colon, and renderers are initialized with an argument like x/y,
 a wrapper library's main() should match on either of these, and if
 neither are applicable, delegate to some user code. this may be useful
 for CLI configuration options.
+
+the system: scheme is reserved for things baked into the WM. it's
+probably best if this *is* handled by an external program. it should be
+immutable at runtime. we want WM consumers to be able to change the
+look, but the user to not be able to disable the fuckin settings app.
+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.
+
+wayland://launch/...?args=... will execute the target executable with
+the given args. it will map to the first window created by the launched
+application. this is intended to allow non-tabbde integrated apps to be
+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.
+
+xorg://launch/...?args=... is functionally the same as the wayland
+equivalent.