aboutsummaryrefslogtreecommitdiff
path: root/rivertile
AgeCommit message (Collapse)AuthorFilesLines
2021-04-27river-options: remove protocolIsaac Freund1-125/+35
This protocol involves far too much accidental complexity. The original motivating use-case was to provide a convenient way to send arbitrary data to layout clients at runtime in order to avoid layout clients needing to implement their own IPC and do this over a side-channel. Instead of implementing a quite complex but still rigid options protocol and storing this state in the compositor, instead we will simply add events to the layout protocol to support this use case. Consider the status quo event sequence: 1. send get_option_handle request (riverctl) 2. roundtrip waiting for first event (riverctl) 3. send set_foo_value request (riverctl) 4. receive set_foo_value request (river) 5. send foo_value event to all current handles (river) 6. receive foo_value event (rivertile) 7. send parameters_changed request (rivertile) 8. receive parameters_changed request (river) 9. send layout_demand (river) And compare with the event sequence after the proposed change: 1. send set_foo_value request (riverctl) 2. receive set_foo_value request (river) 3. send set_foo_value event (river) 4. send layout_demand (river) This requires *much* less back and forth between the server and clients and is clearly much simpler.
2021-04-20river-options: rework, bump to v2Isaac Freund1-238/+191
Options are now all global but may be overridden per-output. If an output local value is requested but none has been set, the global value is provided instead. This makes for much better ergonomics when configuring layout related options in particular.
2021-04-20river-layout: create and implement protocolLeon Henrik Plickat1-109/+373
Replace the current layout mechanism based on passing args to a child process and parsing it's stdout with a new wayland protocol. This much more robust and allows for more featureful layout generators. Co-authored-by: Isaac Freund <ifreund@ifreund.xyz>
2020-12-30command: s/master/main/g (breaking change)Isaac Freund1-28/+28
main is a better term to use here for several reasons: 1. It is more accurate: "master" implies that the designated views have some kind of control over the other views, which is not the case. "main" better expresses that the difference between the "main" view and others is one of importance/focus. 2. It is a shorter word. 2 whole characters saved! 3. It reduces the chance of future development time being lost to good-intentioned people complaining about usage of the word master as has recently happened with regards to the default git branch name.
2020-11-11meta: make copyright headers more maintainableIsaac Freund1-1/+1
- list all files as copyright "The River Developers" - add an AUTHORS file to acknowledge contributors
2020-06-19rivertile: fix underflow if views < mastersIsaac Freund1-1/+1
2020-06-16docs: add rivertile man pageIsaac Freund1-6/+20
2020-06-16rivertile: create default layout generatorIsaac Freund1-0/+128