romangg has quit [Quit: ZNC 1.8.2+deb1+bionic2 - https://znc.in]
snakedye has quit [Ping timeout: 252 seconds]
snakedye has joined #river
sjtio has quit [Ping timeout: 265 seconds]
anubhavkini has quit [Ping timeout: 265 seconds]
romangg has joined #river
sjtio has joined #river
anubhavkini has joined #river
waleee has quit [Ping timeout: 246 seconds]
snakedye has quit [Ping timeout: 245 seconds]
notzmv has quit [Ping timeout: 268 seconds]
novakane has joined #river
leon-p has joined #river
pkap has joined #river
notzmv has joined #river
dimaom has joined #river
pkap1 has joined #river
pkap has quit [Quit: Client closed]
pkap1 is now known as pkap
pkap has quit [Quit: Client closed]
snakedye has joined #river
pkap has joined #river
pkap has quit [Client Quit]
pkap has joined #river
dimaom has quit [Ping timeout: 265 seconds]
<bfiedler>
ifreund: do you have time to look at the discussion on #430 this week?
<ifreund>
hmm, if we give clients the ability to arbitrarily position windows and do that in a non-hacky, double-buffered way that integrates with the transaction system we could just move all of river's window management logic to clients
<ifreund>
picture this: a priviledged client written in lua or something else simple and fast that does all the actual busniess logic of window management
<ifreund>
the river binary then only concerns itself with rendering and atomic transactions
<ifreund>
and relaying things around between wayland clients
snakedye has quit [Ping timeout: 245 seconds]
<ifreund>
the main potential blocker I see would be the extra round trip of latency in situations like interactive resize
snakedye has joined #river
<bfiedler>
that would be pretty cool, however I think there are some additional steps between now and there, the first being that set-geometry and set-position implicitly set windows to floating (which makes sense imo)
<leon-p>
ifreund: you could get around the interactive resize rountrip by allowing clients to "hand-off" managing the position and size of that client during the interactive operation.
<ifreund>
leon-p: Yeah, we could essentially expose the concept of cursor grabs in the protocol and treat move/resize as grabs
<ifreund>
latency for e.g. tiling would be the same as it is now, we already have a round trip to the layout client
<ifreund>
bfiedler: That's fair, the kind of architectural change I just proposed would definitely take a while to design/implement and having something to support your use-case in the meantime wouldn't be bad
<leon-p>
I think the more important questions is, what would we gain from outsourcing more window management to clients? Unless we allow clients controls up to the point of what a window manager on X can do (which I don't think is practical), not very much.
<ifreund>
it think it could simplify the system greatly, instead of needing some way to coordinate atomic transactions between a bunch of different clients we only have one client that has total power
<ifreund>
it would also make river much easier for users to modify to their own desires, they'd just add/modify some code in the window manager client
<novakane>
the thing is IMO users would mainly want to use some shell script to use this, if you need to write a complicated Wayland client I don't think it would be that useful
<ifreund>
also stuff like https://github.com/ifreund/river/issues/357 would now be outside of river itself and up to the user to implement or use some default implementation as they choose
<leon-p>
that would mean completely abandoning the view stack and giving clients control over focusing
<leon-p>
oh, and keybinds
<ifreund>
yep
<ifreund>
river loses all window management code and becomes a generic but opinionated 2d wayland compositor with a window management protocol
<novakane>
so with like something sxhkd?
<ifreund>
not sure if this is the direction I want to go yet, but I think it's worth investigating
<leon-p>
I had that idea already, but abandoned it. Basically window manager and server need to communicate a lot, leading to a ton of roundtrips
<ifreund>
any specific example? everything I've worked through in my head so far has seemed fine
<leon-p>
for example a clients resizing their views need to communicate with the WM through the server.
<ifreund>
you mean client initiated interactive resize? That's just one round trip to the WM to allow/disallow and trigger a resize cursor grab
<leon-p>
how would that be handled? Client attaches buffer, server holds, asks window manager if new size is ok, window manager says yes, server continues and sends new configure event to client?
<ifreund>
oh you mean clients just attaching a buffer of the wrong size, I'd just handle that the same way river does now: display what the client decided to attach
<ifreund>
the WM would be responsible for telling river what size it wants the windows to be, not for enforcing that size
<ifreund>
this is one of the things I had in mind when I said "opinionated"
<leon-p>
and what about keybinds? we need a way for clients to register keybinds.
<ifreund>
not clients, I think we should restrict this to just a single WM client
<ifreund>
but yeah I think that's as simple as adding a request to recieve events from the compositor for certain key/modifier combinations instead of passing them along to the client with keyboard focus/dropping them
<ifreund>
once a keybind is registered the flow for e.g. zoom would look like this:
<ifreund>
river gets input event from hardware -> send keybind event to WM -> WM moves around views and focus -> WM makes an atomic commit of new state -> river starts a transaction and applies state
<ifreund>
which is just as efficient as what we have currently for zoom
<ifreund>
and is actually more efficient than our current solultion for sending layout specific commands
<ifreund>
er, nvm it's equally as efficent
<ifreund>
I think the trickiest part would be working out the cursor protocol
<ifreund>
also not sure what to do about multi seat support
<leon-p>
for cursor, just hand it all off to the server. Perhaps maybe with an event "user tried to move-resize this view via pointer" and the WM can eiither agree or deny it
<leon-p>
we are opinionated, after all
<ifreund>
what about cursor bindings
<leon-p>
the same way they are right now: allow to bind move and resize to buttons (optionally) with a modifier key. Keep it simple
<ifreund>
yeah sure those work out pretty much the same as the keyboard bindings
<ifreund>
focus follows cursor seems trickier
<ifreund>
like I'd rather have that implemented in the client as it's WM policy
<leon-p>
we could have events for when the cursor enters a new views area.
<ifreund>
and when it leaves... yeah that might work out
<leon-p>
I would like them to be optional though, to avoid the overhead when it's not needed
<ifreund>
not as flexible as sending all pointer events in normal mode along to the client though
<leon-p>
on X, a client can ask the server to only send specific events. I don't think it should be that fine grained, but a simple request to turn on/off pointer enter and leave might be enough
<leon-p>
ifreund: I see no real world use case for that
<ifreund>
I don't think there'd be any measurable performance difference
<ifreund>
leon-p: fair, yeah we should error on the side of simplicity/opinonatedness
<ifreund>
anyhow, this is something to think about, but I'm not going to start actually working towards it before I get 0.1.0 out the door
<leon-p>
the first step would be to map out a (smallest possible) set of events and requests necessary for window management (fitting both XDG, Xwayland and perhaps future shells). Edge cases like everything pointer related can be done later.
<ifreund>
yep, protocol would need to come first as always
ext0l has quit [Ping timeout: 246 seconds]
<novakane>
related to protocols, out of curiosity, do you want the next status/control... one to be part of river 0.1.0 or not necessarily?
<snakedye>
novakane: regarding shells scripts to interact with the views, this could also be left to the implementation of the client
<novakane>
snakedye: ah yeah you're right
<leon-p>
eh, shell scripting is overrated anyway in this context. Whenever I saw a script used for auxilliary window management it was always either because the WM was just lacking or simply because it could be done.
<snakedye>
leon-p: I don't think it's necessary to have the client handle keybindings. It doesn't really care what the keys are just what they mean so I prefer the way it is currently
<snakedye>
I agree with the take on shell script. It's a bad hack
<leon-p>
snakedye: the current way means clients must implement some form of parsing to understand the message. Letting clients register keybinds avoids this.
<novakane>
leon-p: well I'm not saying it's not overrated but it's still the best entry point for most users
<snakedye>
leon-p: I don't think that's a concern especifically with modern languages. Splitting a string at a whitespace is fairly easy even for layout generators like mine
<leon-p>
snakedye: but for languages using 0 terminated strings you either need to allocate for tokenizing or create complex string comparison code. And C is still pretty common.
<leon-p>
when you just receive an event that a specific modifier plus key combination has been pressed, you can simply skip all that
<ifreund>
novakane: this theoretical window management protocol would replace river-status/river-control/river-layout and no I don't plan to block 0.1.0 on any features only bug fixes
<snakedye>
But now how you get events which aren't from key presses
<leon-p>
snakedye: you don't. We are opinionated, remember?
<ifreund>
one pain point we'd need to resolve would be how best to integrate with status bars, a simple non-wayland protocol probably would make the most sense
<leon-p>
I'd probably just integrate a status bar into the WM
<ifreund>
that'd be fine too
<ifreund>
I would like to examine how we could get frame perfection for e.g. tags displayed by the status bar
<ifreund>
right now we don't have that
<leon-p>
if the status bar is rendered by the same client doing window management, we could block it's commit until the window management queue is comitted
<snakedye>
leon-p: I personally see this as a net downgrade to perhaps accommodate C. Now the client doesn't need to implement it's own ipc to receive all sorts of messages and can also handle events from key presses.
<leon-p>
snakedye: what events other than keypresses do you need?
<ifreund>
snakedye: imagine something much closer to awesomewm's architecture. Instead of a shell script you write a lua function in you config
<ifreund>
which is a lot more powerful
<snakedye>
Layouts, a layout switcher is more convenient than keypresses or the area of the layout I can get with slurp
<leon-p>
snakedye: a lot of that can simply be integrated into the WM
<ifreund>
yeah, river wouldn't know anything about layouts, that would all be part of the WM
<snakedye>
ifreund: which config? The client or river
<leon-p>
ifreund: in that example, the lua code would be the WM wayland client, right?
<snakedye>
So like kiwmi
<leon-p>
I don't think like kiwmi. That one integrates lua directly. We are talking about protocols here, so the lua code would always be another process
<ifreund>
leon-p: yes, I'm picturing a zig WM library handling the wayland wire protocol and extensible lua core using that library, or some other language
<leon-p>
I see.
<leon-p>
As long as lua will not become a part of river itself, I think that's a good idea
<ifreund>
river itself will stay pure zig
<leon-p>
I personally will probably just port stacktile to the WM protocol
<ifreund>
I'm not sure if I want to officially bless any config/scripting language for the WM
<ifreund>
we could have river-lua, river-scheme, river-python, etc repos
<ifreund>
lots of open questions here
<leon-p>
makes sense. I propose keeping rivertile as a simple pure zig WM then
<snakedye>
leon-p: I do agree that it could be integrated but along with just security concerns in general, I genuinely don't see a reason for the server to dump all key presses to the client. The current model is really good and I don't think changing it brings anything besides perhaps accommodating c. Perhaps because the additional work might be more tedious than just implementing a parser.
<leon-p>
snakedye: not all, oh no
<leon-p>
the client registers specific key binds and only receives events for that, nothing else
<ifreund>
snakedye: the reasoning for the changes I proposed above are motivated by increasing flexibility while reducing complexity
<leon-p>
snakedye: and nothing speaks against an additional way of getting events and data to the WM, this is just for improving keybinds
<ifreund>
for example, with this new model we could keep the same riverctl interface
<ifreund>
rivertile would be the WM client and create its own socket and expose it with a RIVER_SOCK env variable
<ifreund>
and riverctl would speak to rivertile directly over that socket
snakedye has quit [Ping timeout: 245 seconds]
snakedye has joined #river
<leon-p>
and the WM would then also do all the settings, like border colour. that's interesting
<snakedye>
I see, this can work
snakedye has quit [Read error: Connection reset by peer]
snakedye has joined #river
<novakane>
gonna need a river organisation for all of this :P
<ifreund>
yeah that's a good point, I should do that before 0.1.0 to avoid confusion in the future
<ifreund>
leon-p: yeah, we could allow the WM to place arbitrary surfaces wherever it likes without much complexity
<ifreund>
not sure if that is actually a good idea though
<leon-p>
ifreund: for the status panel the layer shell might make more sense
<leon-p>
although maybe we want to allow fancy window decorations, in which case it might make more sense
<leon-p>
I wonder if it makes sense to let the WM set the border colour individually for each view. Of course river still needs to know which of them is focused, but it allows the WM a bit more flexibility
waleee has joined #river
dimaom has joined #river
<dimaom>
many interesting ideas! For me it will make life easier with one tag set for all monitors :P
<dimaom>
and moving window to next monitor instead of same tag as it is now
<novakane>
interesting ideas are easy, time for it is not :P
<dimaom>
doubt it's easy to find a simple solution for most of the problems/issues
<dimaom>
simpleness and effectiveness are not so simple to achieve
<ifreund>
dagle: that looks like lua, what're you up to?
<dagle>
ifreund: It's lua (-jit) for river-layout.
<ifreund>
ah nice, are you just using the luajit ffi to use libwayland directly?
<dagle>
Nah, I'm doing the classic way.
<dagle>
Might switch over, but I have a lot of small stuff to figure out before that becomes of any importance.
<dimaom>
abouts the tags navigation and one tags set per all outputs - it will improve usability a lot, cause you can navigate to any tag on any viewport with one binding. From this perspective even sway's UX better, cause you can navigate straight to desired workspace with one binding. In river, currently, you will use two.
<msiedlaczekelsh4>
I like having separate tag navigation per output. would that be going away?
<leon-p>
dimaom: depends on how use your monitors. I tend to view them as atomic units and want as little overlap as possible
<leon-p>
msiedlaczekelsh4: maybe the WM plans happen before, than it depends on the WM you use
<ifreund>
yeah everyone's going to have different preferences, which is one of the main reasons I like the proposed WM split
<ifreund>
leon-p: I plan to seriously investigate the feasibility of the WM protocol after 0.1.0. If it seems like a good idea I'll just focus on that and forget about implementing the single tagset thing in river itself
<msiedlaczekelsh4>
leon-p: got it. yeah, I prefer how it is now
<leon-p>
ifreund: sounds good
<dimaom>
leon-p, you never needs to use something from other monitor? The way I am voting for not prevents you to use your screens separetely, but allows easy navigaion if needed. The way sway works - you have separate set of tags on each monitor. The issue with it - you can't move workspaces between screens easy way
<msiedlaczekelsh4>
I really only like working on one monitor at a time, and on the other I got some "side" stuff. like irc or whatever, and the other is work I'm currently doing.
<leon-p>
dimaom: I have one monitor in front of me where I keep my work, and another one for auxilliary tasks, like irc, music player, watching a video, documentation, etc. I really really do not want to mix them.
<ifreund>
^
<dimaom>
yep, similar scenario here. one usecase - screen #1: irc, movie, screen #2: coding, browsing. While watching movie - how to switch to irc on other screen?
<msiedlaczekelsh4>
I'm same as leon-p although I can understand your point dimaom ideally, you'd be able to chose how you want it to work I guess... not sure how viable that would be
<ifreund>
I happen to have different preferences but that doesn't make other's preferences invalid
<leon-p>
dimaom: If I wanted to, I'd focus the IRC tag and send it to the other monitor. But that is not a use case that comes up often for me, or ever actually, so I don't mind the little extra work
guest23_ has joined #river
<msiedlaczekelsh4>
I think dimaom's point is valid, and I would be okay with this type of workflow except it would mean I had fewer tags available. sure, I can create more, but then it's difficult to keep track and bindings
<msiedlaczekelsh4>
so I'd rather switch explicitly between monitors, and as leon-p says, it happens very rarely I want to switch something to use on another monitor, and if I do, then the extra work is not that much
<leon-p>
for an easy method of swapping tags/workspaces around outputs, I'd rather use a fancy UI than keyboards TBH. Like a menu listing all tags with the titles of views on them.
<leon-p>
s/keyboars/keybinds/
<Nulo>
I just managed to crash river with an integer overflow somehow
<Nulo>
I did a weird key combination accidentally and it just... crashed
<leon-p>
I think something is still a bit off about rivers rendering. When I watch a video that is a bit more taxing (both mpv and firefox), rivers framerate somehow drops massively. Sometimes it stays low even if the video is closed.
<leon-p>
Nulo: can you get a backtrack?
<Nulo>
leon-p, no clue how
<leon-p>
Nulo: `coredumptl debug`, then gdb should open. Use the `bt` command in it.
<leon-p>
*coredumpctl
<Nulo>
No coredumpctl, I'm on Alpine
<leon-p>
D:
<Nulo>
Sad!
<Nulo>
Any way to get something similar if I manage to trigger it again?
<leon-p>
Nulo: just the logs might be helpful
<Nulo>
I don't think I store river logs either :# What's a good way to do that?
<Nulo>
Although I didn't see anything interesting in the TTY, just a panic
<leon-p>
Nulo: so on alpine, when something segfaults, does the core not get dumped?
<Nulo>
I assume it does by default. I've changed some sysctls which disable that behaviour leon-p
<Nulo>
I should probably re-enable them :')
<leon-p>
you probably should. Makes debugging a bit hard :D
pkap has quit [Quit: Client closed]
dimaom has quit [Ping timeout: 265 seconds]
snakedye has quit [Read error: Connection reset by peer]
snakedye has joined #river
dimaom has joined #river
novakane has quit [Quit: WeeChat 3.3]
novakane has joined #river
waleee has quit [Quit: WeeChat 3.3]
waleee has joined #river
guest23_ has quit [Quit: Connection closed for inactivity]
dimaom has quit [Ping timeout: 245 seconds]
snakedye has quit [Ping timeout: 245 seconds]
snakedye has joined #river
leon-p has quit [Remote host closed the connection]
leon-p has joined #river
dimaom has joined #river
<dimaom>
found a way to crash river - warning: Error reading shared library list entry at 0x6f635f74696e6900. Failed to read a valid object file image from memory. Core was generated by `river -log-level error'.
<dimaom>
happens when trying to exit from full-screen mode with virt-viewer client