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.
This commit is contained in:
parent
416fdc8d06
commit
844ffce037
@ -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);
|
||||
|
@ -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>
|
||||
|
@ -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();
|
||||
}
|
||||
|
@ -298,6 +298,7 @@ const Output = struct {
|
||||
.bottom => layout.commit("rivertile - bottom", ev.serial),
|
||||
}
|
||||
},
|
||||
.user_command_tags => {},
|
||||
}
|
||||
}
|
||||
};
|
||||
|
Loading…
Reference in New Issue
Block a user