river-layout: add user_command_tags event

It is not guaranteed that the next layout_demand event after a user_command
event has the same active tags (for example when there are no views visible).
As an example, a user could trigger a user_command while no views are visible,
then switch to a different tag set which has active views. The active tags of
the previous layout_demand may also be different.

Therefore it is impossible to correctly implement a layout generator which has
user commands apply only to the currently active tag set, which is solved by
this patch.

4 files changed, 22 insertions, 3 deletions

diff --git a/build.zig b/build.zig
index a0909b4..659d93d 100644
--- a/build.zig
+++ b/build.zig
@@ -111,7 +111,7 @@ pub fn build(b: *zbs.Builder) !void {
 
     scanner.generate("zriver_control_v1", 1);
     scanner.generate("zriver_status_manager_v1", 3);
-    scanner.generate("river_layout_manager_v3", 1);
+    scanner.generate("river_layout_manager_v3", 2);
 
     scanner.generate("zwlr_layer_shell_v1", 4);
     scanner.generate("zwlr_output_power_manager_v1", 1);
diff --git a/protocol/river-layout-v3.xml b/protocol/river-layout-v3.xml
index c9822eb..8a1bdce 100644
--- a/protocol/river-layout-v3.xml
+++ b/protocol/river-layout-v3.xml
@@ -38,7 +38,7 @@
     can only be done by creating a new major version of the extension.
   </description>
 
-  <interface name="river_layout_manager_v3" version="1">
+  <interface name="river_layout_manager_v3" version="2">
     <description summary="manage river layout objects">
       A global factory for river_layout_v3 objects.
     </description>
@@ -71,7 +71,7 @@
     </request>
   </interface>
 
-  <interface name="river_layout_v3" version="1">
+  <interface name="river_layout_v3" version="2">
     <description summary="receive and respond to layout demands">
       This interface allows clients to receive layout demands from the
       compositor for a specific output and subsequently propose positions and
@@ -174,8 +174,23 @@
 
         A layout_demand will be sent after this event if the compositor is
         currently using this layout object to arrange the output.
+
+        If version 2 or higher of the river_layout_v3 object is bound, the
+        user_command_tags event is guaranteed to be sent directly before the
+        user_command event.
       </description>
       <arg name="command" type="string"/>
     </event>
+
+    <event name="user_command_tags" since="2">
+      <description summary="a command sent by the user">
+        If version 2 or higher of the river_layout_v3 object is bound, this
+        event will be sent directly before every user_command event. This allows
+        layout generators to be aware of the active tags when a user command is
+        sent. This is necessary for generators wanting to keep settings on a
+        per-tag basis.
+      </description>
+      <arg name="tags" type="uint" summary="tags of the output, 32-bit bitfield"/>
+    </event>
   </interface>
 </protocol>
diff --git a/river/command/layout.zig b/river/command/layout.zig
index fc7c7a5..4ba4f19 100644
--- a/river/command/layout.zig
+++ b/river/command/layout.zig
@@ -76,6 +76,9 @@ pub fn sendLayoutCmd(
         if (mem.eql(u8, layout.namespace, target_namespace)) break layout;
     } else return;
 
+    if (layout.layout.getVersion() >= 2) {
+        layout.layout.sendUserCommandTags(output.pending.tags);
+    }
     layout.layout.sendUserCommand(args[2]);
     if (layout == output.current.layout) output.arrangeViews();
 }
diff --git a/rivertile/main.zig b/rivertile/main.zig
index 0e9276b..bf28bf7 100644
--- a/rivertile/main.zig
+++ b/rivertile/main.zig
@@ -298,6 +298,7 @@ const Output = struct {
                     .bottom => layout.commit("rivertile - bottom", ev.serial),
                 }
             },
+            .user_command_tags => {},
         }
     }
 };