river-status module #9

Closed
opened 1 year ago by hollmax · 3 comments
hollmax commented 1 year ago

Would be nice to have a module for river's tags and other info.
I've seen there has been some work done on this already, but I have found no mention in documentation, about how to set it up.

Would be nice to have a module for river's tags and other info. I've seen there has been some work done on this already, but I have found no mention in documentation, about how to set it up.
dnkl commented 1 year ago
Owner

I've deliberately chosen not to document the river module yet because I'm not sure the current implementation is how I'd like it to be.

That said, if you'd like to try it out (which I don't mind at all - the opposite; feedback is very welcome), perhaps this can get you started:

  left:
    - river:
        title: {string: { text: "{seat} - {title}" }}
        content:
          map:
            tag: occupied
            values:
              false: {empty: {}}
              true:
                string:
                  margin: 5
                  text: "{id}: {state}"

At work I have a more "normal" configuration that I can post later next week.

In short, the title particle is emitted once (currently after all river-tags), and has the two yambar tags you see in the example: seat and title. You are probably not interrested in seat since river doesn't (yet) support multi seat, and thus seat is always default.

content describes a template particle that is instantiated for each river tag. The currently available yambar tags are:

  • id (an integer)
  • visible (boolean)
  • focused (bolean)
  • occupied (boolean)
  • state (string, "focused", "unfocused" and "invisible")

visible is true is the tag is focused by at least one output (monitor). That output may not necessarily have keyboard focus however.

focused is true if the tag is focused by at least one output, and that output has keyboard focus.

occupied is true if the tag has views (i.e. it has windows).

state=focused means the tag is focused on at least one output that has seat (i.e. keyboard) focus.

state=unfocused means the tag is visible if at least one output has it focused, but that output does not have keyboard focus.

state=invisible means the tag is not visible on any output.

All of the above may change and this is why I haven't documented it yet.

I've deliberately chosen not to document the river module yet because I'm not sure the current implementation is how I'd like it to be. That said, if you'd like to try it out (which I don't mind at all - the opposite; feedback is very welcome), perhaps this can get you started: ```yaml left: - river: title: {string: { text: "{seat} - {title}" }} content: map: tag: occupied values: false: {empty: {}} true: string: margin: 5 text: "{id}: {state}" ``` At work I have a more "normal" configuration that I can post later next week. In short, the `title` particle is emitted once (currently **after** all river-tags), and has the two yambar tags you see in the example: `seat` and `title`. You are probably not interrested in `seat` since river doesn't (yet) support multi seat, and thus `seat` is always `default`. `content` describes a template particle that is instantiated for each river tag. The currently available yambar tags are: * id (an integer) * visible (boolean) * focused (bolean) * occupied (boolean) * state (string, "focused", "unfocused" and "invisible") `visible` is `true` is the tag is focused by at least one output (monitor). That output may not necessarily have keyboard focus however. `focused` is `true` if the tag is focused by at least one output, **and** that output has keyboard focus. `occupied` is `true` if the tag has views (i.e. it has windows). `state=focused` means the tag is focused on at least one output that has seat (i.e. keyboard) focus. `state=unfocused `means the tag is visible if at least one output has it focused, but that output does not have keyboard focus. `state=invisible` means the tag is not visible on any output. All of the above may change and this is why I haven't documented it yet.
dnkl commented 1 year ago
Owner

Here's what I'm currently using at work:

left:
  - river:
      anchors:
        - base: &river_base
            margin: 5
            tag: id
            default: {string: {text: , font: *awesome}}
            values:
              1: {string: {text: , font: *awesome}}
              2: {string: {text: , font: *awesome_brands}}

      content:
        map:
          tag: state
          values:
            focused:
              map:
                <<: *river_base
                deco: {stack: [background: {color: ffa0a04c}, underline: {size: 2, color: ff0000ff}]}
            unfocused: {map: {<<: *river_base}}
            invisible:
              map:
                tag: occupied
                values:
                  false: {empty: {}}
                  true: {map: {<<: *river_base, foreground: ffffff4c}}
      title:
        map:
          tag: title
          default: {string: {text: "{title}", left-margin: 10}}
          values: {"": {empty: {}}}
Here's what I'm currently using at work: ```yaml left: - river: anchors: - base: &river_base margin: 5 tag: id default: {string: {text: , font: *awesome}} values: 1: {string: {text: , font: *awesome}} 2: {string: {text: , font: *awesome_brands}} content: map: tag: state values: focused: map: <<: *river_base deco: {stack: [background: {color: ffa0a04c}, underline: {size: 2, color: ff0000ff}]} unfocused: {map: {<<: *river_base}} invisible: map: tag: occupied values: false: {empty: {}} true: {map: {<<: *river_base, foreground: ffffff4c}} title: map: tag: title default: {string: {text: "{title}", left-margin: 10}} values: {"": {empty: {}}} ```
dnkl added the
doc
label 1 year ago
dnkl commented 1 year ago
Owner

The river module was released as an experimental module in 1.5. I haven't seen any reasons to change the behavior of the river module since, and I intend to document the current behavior, making it an officially supported module.

Note that since river itself, and its status protocol, still changes. This means the yambar river module may (have to) change as well. I.e. even though it now becomes officially supported, there is no guarantee that the tags it exposes stays the same.

The river module was released as an _experimental_ module in 1.5. I haven't seen any reasons to change the behavior of the river module since, and I intend to document the current behavior, making it an officially supported module. Note that since river itself, and its status protocol, still changes. This means the yambar river module may (have to) change as well. I.e. even though it now becomes officially supported, there is no guarantee that the tags it exposes stays the same.
dnkl closed this issue 1 year ago
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.