<leon-p>
I wonder if instead of having rivertile have four layouts per output for the four differet main positions we should make that a default option of outputs as well…
leon-p has quit [Quit: leaving]
waleee-cl has quit [Quit: Connection closed for inactivity]
gspe has joined #river
leon-p has joined #river
gspe has quit [Quit: gspe]
gspe has joined #river
waleee-cl has joined #river
<leon-p>
should be perhaps documentation of the default options into river.1 instead of riverctl.1 ?
<leon-p>
And I am still not sure if we should rather have a main_direction options instead of having four distinct layouts per output in rivertile
<ifreund>
hmm, I guess that would be more logical, though a dedicated river-options page might be better
<ifreund>
I think the idea to make orientation an option is a good one
<leon-p>
well, other than that I just finished porting rivertile
<ifreund>
though the fact that we don't have enum options makes that annyoing :/
<leon-p>
did some minor testing and it appears to work without errors, to my surprise, but if anyone wants to test, go ahead
<ifreund>
I'll certainly be testing it when I have a minute :)
<leon-p>
ifreund: We could do it like I have done it for the main_factor option: allow the user to set all options, but in the clients just ignore nonesense and fall back to some sane default.
<ifreund>
that would be fine. State that the values "top" "bottom" "left" and "right" have meaning and anything else is Undefined Behavior
<leon-p>
Or something like "common clients expect 'top' ... 'bottom'".
<ifreund>
though it does make me want to figure out a better way to do enums
<ifreund>
oh we could totally just use a uint as the value and define an enum in the protocol
<leon-p>
In the documentation for main_factor I explicitly did not call it UB or "wrong", because who knows what users want to do with their custom layouts
<ifreund>
though that's not extensible obviously
<ifreund>
true, though UB isn't necessarily wrong
<leon-p>
we could have enums for a few common things, like direction.
<ifreund>
yeah I think having a few generally applicable enums would be a good idea
<ifreund>
the question then becomes whethere we need a new request/event for each enum type or if they should all just use uint
<leon-p>
if we reuse the uint value event, clients will do something wrong. if we add a new event, it will quickly get cluttered
<leon-p>
although if we only have a few enums, it may be ok
<leon-p>
what else do we need other than direction? I can't think of anything rn
ikskuh has left #river ["Leaving"]
gspe has quit [Quit: gspe]
<leon-p>
anyway, I think adding enums to river-options is a separate thing. for now we could finish the river-layout PR and add the enums later, would be more atomic wrt git history
gspe has joined #river
<ifreund>
yeah totally
<leon-p>
I'll open an issue so that we do not forget
<ifreund>
cool
<leon-p>
in that case, I think I am done. Only things left to do are transactions and figuring out default keybindings, which requires some way of querying for the currently focused output name
<leon-p>
only took about 4 months :P
<ifreund>
don't we have a focused_output event in river_status?
<leon-p>
We do, but users have no way of using other than writing a dedicated wayland client.
<ifreund>
what's the use-case exactly?
<leon-p>
do you want separate keybinds per output for things like changing the layout or main amount?
<leon-p>
if not, than we need a way to change the option of the currently focused output
<ifreund>
I think riverctl needs a nice way to target the focused output when setting options
<ifreund>
-focused-output instead of -output foo
<leon-p>
that seems like the better solution
<ifreund>
I'll go implement it in a minute then
<ifreund>
hmm, I wonder why I made an unfocused_output event
<ifreund>
I guess because there can be 0 outputs
<ifreund>
I knew I would need boolean flags in the riverctl arg parser :)
<ifreund>
leon-p: -focused-output flag is implemented
<ifreund>
I hit a zig compiler crash in my arg parser thing so it took a little longer than expected :/
<leon-p>
nice, than I'll quickly add some keybinds to the example init
<ifreund>
note that you can't bind get-option/set-option like other commands yet, you need to bind riverctl get-option/set-option
<ifreund>
Once I rewrite river-control this may change
<leon-p>
yeah I noticed. Won't be a problem I think, although it does waste a few cycles.
gspe has quit [Quit: gspe]
<Edd[m]1>
Hi all - thanks to ifreund for the fantastic talk yesterday at FOSDEM! Super cool to see this project shape up, as it seems to be built partially in response to limitations found in other Wayland wms - something that I've experienced as well.
<Edd[m]1>
Just wanted to drop by to chat about why you're going with a Wayland protocol extension for layouts as opposed to other options (other IPC mechanisms, static linking of layout code, etc.), and find out a bit more about the project to find out how closely river aligns with my wm ideas 🙂
<Edd[m]1>
After the talk, I ended up asking some a question about the old/new tiling mechanism that river uses. I've been thinking about creating a minimalistic wm for a while that provides a simple abstraction for user-defined layouts, and a plugin system for custom behaviour.
<ifreund>
linking user code into the compositor is a very bad user experience when the user's buggy code crashes and dumps them to a tty
<ifreund>
(we did consider it though)
<ifreund>
as for wayland vs other IPC, I don't see any significant to be gained by using something else. Wayland is a capable IPC mechanism designed for low-latency async stuff
<ifreund>
also we already use wayland obviously, so it keeps things simpler
<Edd[m]1>
Makes total sense that you don't want end user's code in the compositor itself.
<Edd[m]1>
It's a slightly different scope to river, but I've been thinking through the creation of a window manager library that implements just the simplest feature set for a compositor in an extensible way. The idea is that it's just the features that are generic enough to power other wms. Layouts and plugins would be linked into the code.
<Edd[m]1>
I think under this architecture, you can get the nice IPC user experience by creating a "Wayland protocol extension layout" that gets linked into the code, but implements the "get layout information" method through IPC calls to other programs.
<Edd[m]1>
Perhaps the "Wayland protocol extension layout" could use the same protocol that you guys have been defining already - because I agree that if you're doing IPC you might as well use Wayland
<ifreund>
did you see kiwmi?
<Edd[m]1>
No, I haven't
<ifreund>
wayfire is also extreemely extensible
<ifreund>
river doesn't aim to be as flexible as those though, It's always going to be a dynamic tiling compositor despite its customizability
<ifreund>
I'm trying to land in the sweet spot between flexibility and too much complexity
<ifreund>
sticking to pure wayland is part of that
<Edd[m]1>
Thanks, I'll check out kiwmi
<ifreund>
I do expect people to implement layout client libraries, someone just posted one on reddit the other day in fact even though it's pretty limited as it still uses the current layout mechanism instead of the river-layout protocol
<Edd[m]1>
I too would like to see a wm land in that sweet spot :)
<Edd[m]1>
I like how river uses a system of tags especially - it's a nice abstraction for the creation of "workspaces" and more
<Edd[m]1>
Do you think there's value in a library (or minimal wm) that provides abstractions like workspaces, tags, and hooks on top of wlroots, but leaves other details like layout and other behaviour up to linked code? Looking at kiwmi, it's extensible via its Lua system, but then the core compositor has to interpret Lua...
<anthony25>
<ifreund> river doesn't aim to be as flexible as those though, It's always going to be a dynamic tiling compositor despite its customizability << which seems perfect to me
<anthony25>
and really lacking in the wayland environment right now
<Edd[m]1>
Yeah for sure, I'm very excited about where river seems to be going
<Edd[m]1>
Just wondering if a lot of the same principles that seem to be behind river can't be abstracted into a more generic project, that doesn't assume dynamic tiling
<ifreund>
the more flexible you try to be, the wider the scope of the project grows and the more complexity, accidental or otherwise, shows up
<ifreund>
dynamic tiling is what I want to use, therefore river is dynamic tiling :D
<ifreund>
I'm making this primarily for myself, though it is cool that other people also find it useful
<Edd[m]1>
Makes sense :)
<Edd[m]1>
btw you mentioned that there is (at least) one other project using zig-wlroots out there - can I get a link?
<Edd[m]1>
I've not really dived too deep into zig before, but it seems like a really neat language for a wm
<ifreund>
zig is a lovely language IMO, if you're ok with occasional bugs and breaking changes I'd definitely recommend it
<ifreund>
if you don't use zig, just use C
<Edd[m]1>
It was awesome to see the first class types come to life in the war against the dreaded void pointer
<Edd[m]1>
That alone made me quite happy to see!
gspe has joined #river
<ifreund>
yeah, it's a great step up over C in that regard
<ifreund>
the finely-grained pointer types also help a lot in preventing bugs and improving clarity
snakedye has joined #river
<leon-p>
Edd[m]1: the layout protocol can only reasonably be used for dynamic tiling. Or to be more specific, it is desiged to allow clients just to send a list of coordinates and dimensions, generated based on primarily a single value: the amount of windows.
<leon-p>
it works for window listss
<leon-p>
if you want to lay out windows based on other data structures, like trees or whatever, complexicity will increase massively
<leon-p>
for such complex layouts, layout engine and window management should stay close togeter, which either means keepin the layout server internal, or outsourcing window management completely.
<leon-p>
(the second approach is what X does)
<snakedye>
Would it possible to have some form of tabbing functionality with titlebar (like in sway)?
<snakedye>
if for example 2 or more window have the same geometry
<snakedye>
and maybe have an option to enable or disable this behaviour
<leon-p>
the titlebar would require drawing those in the compositor, which means drawing to a texture (relatively easy with pixman and wlr_texture) and doing fonts (hell on earth).
<ifreund>
if you want the compositor to render fonts, I recommend a fork :P
<leon-p>
With fonts you have two options: 1) use pango and depend on glib, or 2) do it manually. Both are bad solutions.
<leon-p>
maybe you can do the window titles with external clients and river-option.
<leon-p>
views can have the same position and dimension and act as if they were stacked/tabbed, just without the titlebar
<ifreund>
you know, it would probably be possible to implement that suckless tab thing in wayland
<ifreund>
it would work similarly to my xdg to layer shell hacks, but probably be easier due to sticking to the same shell
<ifreund>
CSDs would be ugly though
<snakedye>
the titlebar is to differentiate the tabbed window from the other and also see the active window
<snakedye>
i don't think fonts are necessary to achieve that but it would be great
<snakedye>
currently if I have a 10 windows tabbed, I don't where I am in the stack and I can't tell at glance how much windows there are
<leon-p>
In the future it will probably be possible to display such information on external clients, such as bars.
<ifreund>
yeah I think a bar is a perfect place to put that info
<leon-p>
with that all you do is move the complexity from the layout to the compositor
<Edd[m]1>
I don't see what you mean: from the perspective of the compi
<Edd[m]1>
sorry, mispressed return
<Edd[m]1>
* I don't see what you mean: from the perspective of the compositor, the layout just exposes an interface to add/remove windows, get window positions, and then optionally some commands to manipulate the internal state
<leon-p>
well, instead of having the layout engine generate one layout for one list, you have the compositor split all windows into multiple lists, spawning multiple layout engine processes, and later stitching it all back together.
<snakedye>
I already implemented nested layouts on my tiling layout generator but having an internal state or more information in general regarding on the windows would really helpful
<leon-p>
snakedye: with river-layout you'll have the app-id of all windows as well as the option to have any arbitrary value as live-changeable layout parameter
<leon-p>
but if you nest layouts in the layout engine, it does not change the fact that windows are still a list
<Edd[m]1>
leon-p: It's not correct that the compositor has to do more work, or keep track of more data structures. From the perspective of the compositor, it simply talks to a single layout, and presents it with a list of windows. The compositor doesn't care about what the layout does with this information. And the layout can lay out the windows however it likes, including according to its internal data structure.
<Edd[m]1>
And you're right that this would involve multiple processes under IPC: that's why this approach requires that the basic layouts are linked into the compositor
<leon-p>
if the compositor does not do that work, than you have all windows in a single plain list, like it is now. In that case, complex layouts are nonesense, because all you can do with a window list is "focus next" and "focus previous".
<Edd[m]1>
But the advantage is this clean separation between compositor and layout, where the compositor only cares to tell the layout which windows it should manage, and the layout handles the rest by itself
<leon-p>
it's just like I said: layouts can do whatever the hell they want with windows, tile them, stack them, hide them behind others, spiral them, whatever. But the compositor sees nothing but a list.
<leon-p>
and since you are interacting with windows through the compositor, you are interacting with the list, not with the data structure on which your layout is based
<ifreund>
^^^
<Edd[m]1>
From the perspective of the compositor, it's correct that the windows are just a list. Indeed, the compositor doesn't care about the layout's internal state.
<Edd[m]1>
But the key here is that layouts should be able to define their own custom methods that manipulate the internal state, and that input events can be bound to. So the tree layout can implement "swap nodes of the tree" methods or whatever, and the user can bind their keyboard shortcuts to these methods.
<Edd[m]1>
So the end user cares about the internal data structure when defining their keyboard shortcuts, but otherwise the compositor doesn't care or gain any complexity.
<Edd[m]1>
* From the perspective of the compositor, it's correct that the windows are just a list. Indeed, the compositor doesn't care about the layout's internal state.
<Edd[m]1>
But the key here is that layouts should be able to define their own custom methods that manipulate the internal state, and that input events can be bound to them. So the tree layout can implement "swap nodes of the tree" methods or whatever, and the user can bind their keyboard shortcuts to these methods.
<Edd[m]1>
So the end user cares about the internal data structure when defining their keyboard shortcuts, but otherwise the compositor doesn't care or gain any complexity.
<leon-p>
you want a full window manager like in X
<leon-p>
that is explicitly not what we are doing with external layouts in river
<ifreund>
you want wayfire
<leon-p>
our use case is "hey, I am a compositor, I have a few windows, please lay them out for me, thanks. I'll handle the rest, goodbye"
<leon-p>
note that when writing the layour protocol I considered instead writing a window management protocol, but it is non-trivial.
<snakedye>
I think the river-layouts is already extremely permissive as it is, the only thing that's harder to implement is manual tiling but even then you could still accomplish if you're willing to play a bit with river-options
<ifreund>
yeah you can hack a lot onto it, but with increasing friction the farther you get from dynamic tiling
<leon-p>
I think river-options shines with simple things. F.E. I am going to use it in my personal layout to configure the height of the first window of the non-main stack.
<Edd[m]1>
Just to be clear, I'm not coming here to try and tell you how to do things, or try and expand the feature set of river beyond what you want!
<Edd[m]1>
That said, I don't see why having layouts being able to define their own methods that the compositor can call by name goes against your current "I'll handle the rest" aim. As I say, the compositor itself doesn't have to care about these methods, but it gives layout implementers so much more flexibility.
<Edd[m]1>
Thanks for being willing to debate this through with me :)
<leon-p>
because that would require way more than is possible sanely through a wayland protocol extension
<snakedye>
Layouts can already do that, if you're willing to put the effort
<ifreund>
yeah, that sounds like dbus level complexity
<ifreund>
and I *hate* dbus
<Edd[m]1>
Would it? Maybe there's something I'm missing, but I'm imagining that the message in the protocol would be something like "call method by name x on arguments in y data structure"
<leon-p>
possible? sure. But annoying. and requires tons of string parsing.
<snakedye>
leon-p Can I take a look at your personal layout 👀
<ifreund>
that would mean implementing a higher-level IPC protocol on top of wayland
<ifreund>
which is something I have no intention of doing
<leon-p>
note that it still for the old layout mechanism
<leon-p>
haven't had time to port it yet
<leon-p>
Edd[m]1: I am also not sure why you actually would want to do it like that. Seems like a massive hassle.
<leon-p>
If you want window management to be more user scriptable, why not just have your compositor run a LISP repl or something
<ifreund>
write your compositor in janet :D
<snakedye>
lmao
<ifreund>
janet's got pretty great C interop, it would be doable
<ifreund>
though you'd probably want to write the core in C or Zig for preformance
<ifreund>
Someday when my TODO list runs dry I'll write a janet wayland scanner and write my layout generators in janet
<leon-p>
considering we're working with lists, a lisp is a pretty good fit actually :D
<Edd[m]1>
leon-p: I want to do it like this for two main reasons:
<Edd[m]1>
I think that the nested layouts are neat because you can re-use basic layout engines to create new layouts
<Edd[m]1>
This approach allows for arbitrary layout algorithms with zero added complexity in the compositor
<ifreund>
janet has tables too :P
<snakedye>
leon-p I might be missing something but I don't see how you would be able to increase the size of X window. Maybe because it's old
<leon-p>
snakedye: not of any arbitrary window, rather of a window at position n. Or in my case, the window named "secondary area"
<Edd[m]1>
Regarding user scripting, the neat thing is that you can implement a layout that contains a REPL, loads a script file, and delegates the actual laying out of windows to the script
<Edd[m]1>
So the idea is compatible with every possible version of user scripting that you could care to package into a layout interfac
<Edd[m]1>
* So the idea is compatible with every possible version of user scripting that you could care to package into a layout interface
<leon-p>
like, you can already nest layouts, because as I said layouts can do whatever they want, but I don't think it'll work out like you imagine it to
<snakedye>
Edd[m]1 shameless plug, you should take a look at my layout generator https://gitlab.com/snakedye/river-layouts/-/tree/main/sr. For example, I can create the master and stack layout like this `riverctl layout rivertiler vertical horizontal horizontal`. The horizontal split layout exists within a frame of the vertical layout.
<leon-p>
also being compatible with "every possible way to do X" is overrated. good software is opinionated
<ifreund>
+1
<leon-p>
snakedye: with river-options you could set those config string live
<Edd[m]1>
Maybe one particular scripting layout would prevail in the end, but I've never heard of somebody calling a general purpose library too generic
<Edd[m]1>
Which is essentially what my idea is: the very unopinionated core of a wm
<Edd[m]1>
snakedye: thanks for the link! I'll take a look :)
<leon-p>
Edd[m]1: I'll invite you to go ahead and try to write a window management protocol. And then implement it (maybe fork river).
<leon-p>
or, better yet, write a river layout
<leon-p>
something really complex with lots of nested sub-layouts
<leon-p>
and then you'll see why it's not practical
<snakedye>
leon-p do you mean "vertical horizontal horizontal"?
<leon-p>
snakedye: you mean in my own layout? it is basically like the default tiled layout, just that the stack area only has two windows and the rest is stacked like a deck of cards
<leon-p>
I found that I rarely use more than three windows in real world tasks, so I optimised my layout for that
* ifreund
is still just using rivertile left as he doesn't have time to play with custom layouts
<Edd[m]1>
I do intend to have a crack at this, but it's a bit of a matter of free time at the moment - I've already sat on this idea for over a year now!
<Edd[m]1>
And the window management protocol only needs one additional method call, as we discussed - something that might be a good start if/when I embark on this
<Edd[m]1>
Just to clarify: I don't think most people would care for deeply nested sub-layouts, myself included. I don't care for having them too deep - that's not the main point. The main point is that the layouts can do non-dynamic-tiling without increasing compositor complexity, at the cost of a slight protocol extension/linking of layout code
<ifreund>
also no point before river-layout is merged
<Edd[m]1>
Thanks for the boilerplate link :)
<snakedye>
leon-p I meant the config option for my layout I could set with river-options. Were "vertical horizontal horizontal" the config option you were referring to too? I also have a something similar layout (windows stack like cards).
<snakedye>
does anyone actually uses rivertile top and bottom?
<Edd[m]1>
Also ifreund thanks for the reference to look at wayfire - it has many similar ideas to what I'm thinking of. I'll keep looking, but it's not quite as elegant as river in some ways: for example, doesn't use a tagging system, instead using a rather ugly cross-workspace window-mirroring bodge
<ifreund>
ammen99 could tell you more (he's the author) but I don't think wayfire enforces *any* particular window management system
gspe has quit [Quit: gspe]
<Edd[m]1>
That would be super handy if he could! Perhaps I got the wrong end of the stick
<leon-p>
snakedye: yes, that is what I meant. those can now be set at runtime
<leon-p>
and rivertile top and bottom are intented for example for people who use vertical monitors.
<ifreund>
I turned my monitor verticle for couple days and used river tile bottom, it was neat
<snakedye>
I always forget about vertical monitors
<ifreund>
you can fit a lot more code on the screen
<ifreund>
mine's just a normal montior with a flexible stand :)
<ifreund>
the stand has a second arm too, I just haven't gotten around to tracking down another decent and cheap monitor for it on ebay kleinanzeige
<snakedye>
That sounds cool. Hopefully I can set this up for myself
<leon-p>
ifreund: I found that the best source for monitors is waiting for some university departement to upgrade their workstations
<leon-p>
I got some sweet modern 4:3 displays that way
<snakedye>
that's a galaxy brain move
<ifreund>
very nice :)
<snakedye>
how can you get theses monitors? Do you just ask?
<leon-p>
more or less. Universities, at least in germany, have money but poor management, which means even working stuff gets replaced, which means frustrated administrators often either just through it all out, place it in front of the container if they are nice, or hang out a sign or something. Basically you'll have to know the inofficial blackboards, because stuff like that can't be official
<leon-p>
s/blackboards/bulletinboards/g
<leon-p>
but you'll have to be fast. many students want that stuff to re-sell it on ebay
<Edd[m]1>
The maintenance department of my uni used to do this with their old tech. Shame the only monitor I got out of it was a CRT!
<Edd[m]1>
Then again, I did find a pretty sweet 50 port gigabit switch, which probably made up for it :P
<leon-p>
well, a CRT and a doom port is all you need for a night of fun
<Edd[m]1>
Yes indeed
<Edd[m]1>
My plan was to hook it up to a VGA driver on an FPGA for a real old-skool CPU experience
<leon-p>
considering all the layout talk today, maybe I should extend the description part of the protocol to some sort of "layout manifesto". Because I have a feeling these all will become FAQs.