~novakane/rivercarro

d31d2dda5d6ad6ac05ba5d0dab9c2d6865319d24 — Hugo Machet 1 year, 9 months ago 33b1c35
Add river layout protoco in the repo
3 files changed, 186 insertions(+), 13 deletions(-)

M README.md
M build.zig
A protocol/river-layout-v3.xml
M README.md => README.md +4 -7
@@ 27,12 27,6 @@ Build, `e.g.`

    zig build --prefix ~/.local

Note that _rivercarro_ use pkgconfig for the `river-layout-v3`
protocol so if you did not installed _river_ system wide you need to
set `PKG_CONFIG_PATH` in your shell rc, e.g.

    export PKG_CONFIG_PATH="$HOME/.local/share/pkgconfig"

## Usage

Works exactly as _rivertile_, you can just replace _rivertile_ name by


@@ 113,11 107,14 @@ Thanks to [Isaac Freund] and [Leon Henrik Plickat] for river obviously, for
rivertile, most of rivercarro code comes from them, and for always answering
my many questions!


## License

rivercarro is licensed under the [GNU General Public License v3.0 or later]

Files in `protocol/` directory are released under various licenses by
various parties. You should refer to the copyright block of each files for
the licensing information.

[river]: https://github.com/ifreund/river
[stacktile]: https://sr.ht/~leon_plickat/stacktile/
[kile]: https://gitlab.com/snakedye/kile

M build.zig => build.zig +1 -6
@@ 36,12 36,7 @@ pub fn build(b: *Builder) !void {
    };

    const scanner = ScanProtocolsStep.create(b);

    const protocol_path = mem.trim(u8, try b.exec(
        &[_][]const u8{ "pkg-config", "--variable=pkgdatadir", "river-protocols" },
    ), &std.ascii.spaces);
    const layout_protocol = try std.fs.path.join(b.allocator, &[_][]const u8{ protocol_path, "river-layout-v3.xml" });
    scanner.addProtocolPath(layout_protocol);
    scanner.addProtocolPath("protocol/river-layout-v3.xml");

    const exe = b.addExecutable("rivercarro", "src/main.zig");
    exe.setTarget(target);

A protocol/river-layout-v3.xml => protocol/river-layout-v3.xml +181 -0
@@ 0,0 1,181 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="river_layout_v3">
  <copyright>
    Copyright 2020-2021 The River Developers

    Permission to use, copy, modify, and/or distribute this software for any
    purpose with or without fee is hereby granted, provided that the above
    copyright notice and this permission notice appear in all copies.

    THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
    WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
    MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
    ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
    WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
    ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
    OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  </copyright>

  <description summary="let clients propose view positions and dimensions">
    This protocol specifies a way for clients to propose arbitrary positions
    and dimensions for a set of views on a specific output of a compositor
    through the river_layout_v3 object.

    Layouts are a strictly linear list of views, the position and dimensions
    of which are supplied by the client. Any complex underlying data structure
    a client may use when generating the layout is lost in transmission. This
    is an intentional limitation.

    Additionally, this protocol allows the compositor to deliver arbitrary
    user-provided commands associated with a layout to clients. A client
    may use these commands to implement runtime configuration/control, or
    may ignore them entirely. How the user provides these commands to the
    compositor is not specified by this protocol and left to compositor policy.

    Warning! The protocol described in this file is currently in the
    testing phase. Backward compatible changes may be added together with
    the corresponding interface version bump. Backward incompatible changes
    can only be done by creating a new major version of the extension.
  </description>

  <interface name="river_layout_manager_v3" version="1">
    <description summary="manage river layout objects">
      A global factory for river_layout_v3 objects.
    </description>

    <request name="destroy" type="destructor">
      <description summary="destroy the river_layout_manager object">
        This request indicates that the client will not use the
        river_layout_manager object any more. Objects that have been created
        through this instance are not affected.
      </description>
    </request>

    <request name="get_layout">
      <description summary="create a river_layout_v3 object">
        This creates a new river_layout_v3 object for the given wl_output.

        All layout related communication is done through this interface.

        The namespace is used by the compositor to decide which river_layout_v3
        object will receive layout demands for the output.

        The namespace is required to be be unique per-output. Furthermore,
        two separate clients may not share a namespace on separate outputs. If
        these conditions are not upheld, the the namespace_in_use event will
        be sent directly after creation of the river_layout_v3 object.
      </description>
      <arg name="id" type="new_id" interface="river_layout_v3"/>
      <arg name="output" type="object" interface="wl_output"/>
      <arg name="namespace" type="string" summary="namespace of the layout object"/>
    </request>
  </interface>

  <interface name="river_layout_v3" version="1">
    <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
      dimensions of individual views.
    </description>

    <enum name="error">
      <entry name="count_mismatch" value="0" summary="number of
        proposed dimensions does not match number of views in layout"/>
      <entry name="already_committed" value="1" summary="the layout demand with
        the provided serial was already committed"/>
    </enum>

    <request name="destroy" type="destructor">
      <description summary="destroy the river_layout_v3 object">
        This request indicates that the client will not use the river_layout_v3
        object any more.
      </description>
    </request>

    <event name="namespace_in_use">
      <description summary="the requested namespace is already in use">
        After this event is sent, all requests aside from the destroy event
        will be ignored by the server. If the client wishes to try again with
        a different namespace they must create a new river_layout_v3 object.
      </description>
    </event>

    <event name="layout_demand">
      <description summary="the compositor requires a layout">
        The compositor sends this event to inform the client that it requires a
        layout for a set of views.

        The usable width and height indicate the space in which the client
        can safely position views without interfering with desktop widgets
        such as panels.

        The serial of this event is used to identify subsequent requests as
        belonging to this layout demand. Beware that the client might need
        to handle multiple layout demands at the same time.

        The server will ignore responses to all but the most recent layout
        demand. Thus, clients are only required to respond to the most recent
        layout_demand received. If a newer layout_demand is received before
        the client has finished responding to an old demand, the client should
        abort work on the old demand as any further work would be wasted.
      </description>
      <arg name="view_count" type="uint" summary="number of views in the layout"/>
      <arg name="usable_width" type="uint" summary="width of the usable area"/>
      <arg name="usable_height" type="uint" summary="height of the usable area"/>
      <arg name="tags" type="uint" summary="tags of the output, 32-bit bitfield"/>
      <arg name="serial" type="uint" summary="serial of the layout demand"/>
    </event>

    <request name="push_view_dimensions">
      <description summary="propose dimensions of the next view">
        This request proposes a size and position for a view in the layout demand
        with matching serial.

        A client must send this request for every view that is part of the
        layout demand. The number of views in the layout is given by the
        view_count argument of the layout_demand event. Pushing too many or
        too few view dimensions is a protocol error.

        The x and y coordinates are relative to the usable area of the output,
        with (0,0) as the top left corner.
      </description>
      <arg name="x" type="int" summary="x coordinate of view"/>
      <arg name="y" type="int" summary="y coordinate of view"/>
      <arg name="width" type="uint" summary="width of view"/>
      <arg name="height" type="uint" summary="height of view"/>
      <arg name="serial" type="uint" summary="serial of layout demand"/>
    </request>

    <request name="commit">
      <description summary="commit a layout">
        This request indicates that the client is done pushing dimensions
        and the compositor may apply the layout. This completes the layout
        demand with matching serial, any other requests sent with the serial
        are a protocol error.

        The layout_name argument is a user-facing name or short description
        of the layout that is being committed. The compositor may for example
        display this on a status bar, though what exactly is done with it is
        left to the compositor's discretion.

        The compositor is free to use this proposed layout however it chooses,
        including ignoring it.
      </description>
      <arg name="layout_name" type="string" summary="name of committed layout"/>
      <arg name="serial" type="uint" summary="serial of layout demand"/>
    </request>

    <event name="user_command">
      <description summary="a command sent by the user">
        This event informs the client of a command sent to it by the user.

        The semantic meaning of the command is left for the client to
        decide. It is also free to ignore it entirely if it so chooses.

        A layout_demand will be sent after this event if the compositor is
        currently using this layout object to arrange the output.
      </description>
      <arg name="command" type="string"/>
    </event>
  </interface>
</protocol>