<Guest87>
waleee That one, or river, or river-bin. All require llvm13, but I can't even get llvm13 to build. Just wondering if someone managed to get it going and had a similar experience.
<waleee>
Guest87: I'd go with a static zig from https://ziglang.org/download/ in the meantime, and just do a local build
<Guest87>
I can't seem to install static zig, presumably due to lack of experience/knowledge. Thanks for the suggestion, I'll try to figure out what I'm doing wrong.
<waleee>
Guest87: it essentially boils down to untar, ln -s $HOME/Downloads/zig.../zig $HOME/.local/bin (or whatever is on your PATH)
<Guest87>
Oh, I was over complicating it. Thanks!
<waleee>
it is _extremly_ static
<Guest87>
You weren't kidding, haha. Thanks!
<waleee>
Guest87: there's a zig pip-package now for when you need to compile c/c++ code for your python application
<waleee>
(just because of said extreme static-ness)
<waleee>
* and portability
<Guest87>
zig-static in the AUR seems to have solved the problem for me. Thanks for leading me in the right direction!
Guest87 has quit [Quit: Client closed]
waleee has quit [Quit: WeeChat 3.3]
Guest5896 has joined #river
Guest5896 has quit [Client Quit]
inclement has quit [*.net *.split]
inclement has joined #river
dnkl has quit [*.net *.split]
wrl has quit [*.net *.split]
wrl has joined #river
dnkl has joined #river
omni has quit [Ping timeout: 256 seconds]
omni has joined #river
ecocode__ has quit [Ping timeout: 265 seconds]
ecocode__ has joined #river
duncaen has joined #river
duncaen has quit [Ping timeout: 250 seconds]
duncaen has joined #river
leon-p has joined #river
ecocode__ has quit [Ping timeout: 264 seconds]
ecocode__ has joined #river
masoudd has joined #river
<ifreund>
leon-p: RE direction actions, I ended up at another concert yesterday evening so I haven't had a chance to give it a proper look yet
<ifreund>
it's one of those features that I'd personally never use, so I'm not sure how I feel about merging it
<ifreund>
from the LoC count it looks like the code complexity isn't too bad though
<ifreund>
really, I just want to make river flexible enough so that people can implement stuff like this themselves
<leon-p>
agreed, but that will probably take a lot of time
<masoudd>
Hello, I'm trying to see if I can switch from dwm to river. I've got the basics working. Having trouble with waybar. river/tags makes waybar crash. Also how can I show window titles in the middle? like sway/window does?
<leon-p>
anyway, even if the directional view stuff will not get merged, I still think it is a good idea to deduplicate swap and focus-view
<ifreund>
masoudd: you need waybar master currently as the most recent release unfortunately has a bug in the river/tags module
<masoudd>
Thanks
<ifreund>
it's possible to show the current window title in status bars, but nobody's implemented it in way bar yet
<ifreund>
perhaps with ristate you could script something though for waybar?
<ifreund>
leon-p: yeah, I'm hoping I can make some good progress over the holidays, but it will still probably take months
<ifreund>
I'm open to merging it, just need to take a good look at the code
<ifreund>
I also need to come up with a plan of what river looks like post window management protocol
<masoudd>
I'm still trying to learn about wayland protocols. I'll see if I can put something like that together
<leon-p>
FWIW I will probably use the Vector type from that PR to refactor my cursor resize PR as well
<leon-p>
ifreund: basically the main question I have is whether we gradually extend the current layout protocol or start from scratch?
<ifreund>
I've been planning on re-implementing the current riverctl API as a wm client for people who prefer the current state of things
<ifreund>
leon-p: I've been planning to start from scratch and do a highly breaking release protocol wise
<leon-p>
sounds good
<ifreund>
I think the biggest design question is whether we should attempt to have a standardized way for WMs to communicate status information or not
<ifreund>
a WM specific socket and simple line based protocol would be totally sufficient
<leon-p>
ifreund: I have thought about that as well. It would massively simplify status bars, but I think it would also enforce a certain way of doing things
<ifreund>
I'm currently leaning towards the WM specific way of doing things yeah
<leon-p>
as a reference, we already have an example protocol that tried to do it all, the workspace protocol proposal. Not sure if we really want to go in the same direction
<ifreund>
depending on how far we go with this, we could end up with a really nice way for people to port X11 WMs to wayland without touching any of the hard parts of wayland
<leon-p>
that would be cool
<ifreund>
yep, i'm not a huge fan of the workspace protocol proposal
<ifreund>
mostly because you'll still have to configure your status bar in a compositor specific way
<leon-p>
what I would personally like if a WM can do /just/ Wayland. Having a secondary socket for WM status is a bit complicated IMO
<ifreund>
what makes sense for the way river would hypothetically use workspaces doesn't match the way sway or kwin would
<ifreund>
leon-p: a secondary socket for status would be write only for most WMs I believe
<leon-p>
however there needs to be a way to communicate workspace/tag/whatever state from the WM to other clients, otherwise WMs would need to implement status bars themselves
<ifreund>
which is really quite simple from the WM's side, simpler than wayland infact
<leon-p>
should river also manage that socket?
<ifreund>
no, river should have no idea that it exists
<leon-p>
I agre
<leon-p>
e
<leon-p>
but I think this problem is secondary to the design of the core of such a WM protocol itself, so solving it can wait until we have working example clients to experiment with
<leon-p>
another important question is whether we keep the "only one output per view" rule. Allowing a view to be displayed on multiple outputs is necessary for features such as dragging a view from one output to another. Is this something we want to allow WMs to do?
<leon-p>
If yes, we probably can't use per-output coordinates and need to use output layout coords
<ifreund>
yep, my plan was to drop that limitation as well
<leon-p>
makes sense
<ifreund>
in sync with moving to the wlroots scene graph API
<leon-p>
which coords does the scene graph use?
<ifreund>
output layout coords
<leon-p>
nice, that makes our job easier
<ifreund>
they are ints currently, though I think there is an open issue to make them doubles..
<leon-p>
have you thought about window decorations yes? Some WMs may want to do more than a monochrome border
<ifreund>
leon-p: one way to do that would be to let the WMs place arbitrary buffers in the scene
<ifreund>
and probably implement the current monochrome borders as colored rectangles at arbitrary places in the scene
<leon-p>
why buffers and not surfaces? Surfaces would give us pointer handling for free and some WMs may want to have buttons in titlebars
<ifreund>
basically, if we go all the way with this, we expose an atomic, async, scene-graph based window management API
<ifreund>
yeah surfaces would probably make much more sense there
<ifreund>
this is a non trivial project though,
<ifreund>
rendering arbitrary surfaces comes dowen the line
<ifreund>
actually though, I think it would be better keep things flat and not encode the scene graph tree in the protocol
<ifreund>
more complex clients can easily implement that structure themselves, and simple ones don't need it
<ifreund>
we should only expose primitives, not necessarily abstractions
pkap has joined #river
<pkap>
Can I have a nested river session with a second "virtual" monitor?
<leon-p>
pkap: There is an env var that makes wlroots spawn more than one wayland backend output
<ifreund>
WLR_WL_OUTPUTS=foo
<pkap>
Awesome! Thanks leon-p and ifreund!
elshize has quit [Quit: WeeChat 3.3]
pkap has quit [Quit: Client closed]
pkap has joined #river
michal has joined #river
michal is now known as elshize
masoudd has quit [Quit: Leaving]
waleee has joined #river
pkap has quit [Ping timeout: 256 seconds]
pkap has joined #river
snakedye has quit [Ping timeout: 256 seconds]
snakedye has joined #river
SmarmyWalrus has joined #river
<SmarmyWalrus>
So dumb question. What's the best practice for setting the resolution with River? I ahevn't found anything about it in either the example init, the man pages for river, riverctl, etc. Nor can I dig it up in the dotfiles of other river configs I've found.
<leon-p>
SmarmyWalrus: for one-time non-persistent output configuration, there is wlr-randr. For persistent, automatic output configuration, use kanshi
<SmarmyWalrus>
Ah thanks. Do those send requests to wlroots?
<SmarmyWalrus>
I'm still learning to understand the wayland stack/ecosystem
<leon-p>
they use a specialized protocol extension to communicate output configuration with the server
<leon-p>
the server is river, wlroots is the part of river that handles the low-level bits of the server-side communication
<chipps>
a stupid question, but how exactly are we supposed to install river globally?
<leon-p>
chipps: move the executable to a directory that is in the $PATH of all users?
chipps has quit [Quit: WeeChat 3.3]
<waleee>
leon-p: slightly evil if chipps didn't move the riverctl (and a layout generator) too
<leon-p>
oh, yeah, that should be done as well ^^
adelaide has joined #river
<pkap>
I wanted to try some zig, so I implemented a function to focus a specific output by name. Is this something considered to be added?
<pkap>
Use case: I want to click the waybar tags of an unfocused output.
<leon-p>
I am not against it, although it should be noted that all these kinds of features will be made obsolete by the window management plans
<leon-p>
so it kinda lives in a similar domain as my cursor resize and directional focus PRs
<pkap>
I see. I'll do a PR nontheless.
SmarmyWalrus has quit [Remote host closed the connection]
pkap has quit [Quit: Client closed]
pkap has joined #river
<ifreund>
hmm, I feel like clicking the waybar tags of an unfocused output should just work
SmarmyWalrus has joined #river
<pkap>
It works but it changes the tags on the current output and not the clicked output.
<leon-p>
ifreund: I think not. If you click on a different output and hit a view, river will try to focus the view, find the output is not focused and then focuses the output first. But waybar does not get focus. Same for clicking on an empty background
<leon-p>
oh, so apparently it does?
<ifreund>
pkap: ah, yeah I see the issue there
<leon-p>
IIRC I was the one who implemented cross output view focusing via pointer and I am pretty sure I only touched view focus code
<ifreund>
riverctl doesn't expose a way to target the output/view of any operations currently, it always just uses the focused output/view
<ifreund>
leon-p: layer surface, not view in this case
<ifreund>
if the layer surface has set keyboard interactive river will focus that output first
<leon-p>
does waybar have keyboard interactivity?
<ifreund>
waybar doesn't though, it just uses the pointer events which river sends along even if waybar doesn't have keyboard focus
<leon-p>
so I just tested with a layer surface without keyboard interactivity and it does not focus the output, so clicking on a waybar on a different output should not focus it either
<ifreund>
it doesn't need keyboard focus to recieve pointer events
<ifreund>
what keyboard interactive layer surface are you testing with?
<leon-p>
true, but wasn't the issue about focusing outputs?
<leon-p>
ifreund: none, I tested with a not keyboard interactive surface (wlclock)
<ifreund>
no, the issue is that the riverctl set-focused-tags command acts on the currently focused output
<leon-p>
ah, ok. I misunderstood then
<ifreund>
leon-p: ah, I misread
<leon-p>
lavalauncher has keyboard-interactivity, but I did not get it out of its box to test it
<ifreund>
fuzzel would be a good one to test with
<leon-p>
let's find out
<leon-p>
yes, when fuzzel is on a not focused output and you click it, the output gets focused
<ifreund>
nice :)
<leon-p>
still, I think clicking on things that do not have keyboard interactivity probably should also focus the output
<pkap>
I didn
<ifreund>
leon-p: yeah, I wouldn't mind that
<tiosgz_>
leon-p: but doesn't that conflict with focus-follows-mouse? or wait, it's *click*. that makes more sense
<ifreund>
still banging my head against this pointer drag code currently though
<leon-p>
ifreund: don't be to sure that it is in the transaction code. It is totally possible that my math is off somewhere
<tiosgz_>
but for me pointer focus is strongly distinct from keyboard focus. maybe it's due to my usage of my compositor
<leon-p>
tiosgz_: right, pointer focus will always be assigned to the surface under the pointer, while keyboard focus must be moved by click / keybind / focus-follow-cursor
<ifreund>
leon-p: ah, I'm not talking about your move/resize PR, rather about the regression caused by my latest "bug fix" commit
<pkap>
I didn't know about these things so I wanted to make waybar explicitly call `focus-output-name` when waybar tags is clicked.
<ifreund>
to reproduce drag a tab from one firefox instance to another, then without leaving the firefox window with the cursor try to select some text or scroll or whatever
<ifreund>
though actually, I should find another test client to make sure this isn't a firefox bug I just uncovered
<leon-p>
isn't dnd a special cursor mode? maybe the fix is just a call to Cursor.passthrough when DnD mode is left?
<ifreund>
not really, dnd happens in the passthrough cursor mode
<leon-p>
I see
<tiosgz_>
leon-p: in my case the click and focus-follows-cursor options don't apply. well, but i won't mess into river since it does have the click option unconditionally
norkki has quit [*.net *.split]
norkki has joined #river
<ifreund>
found a gtk demo that reproduces the dnd issue, guess it is my fault then
SmarmyWalrus_ has joined #river
SmarmyWalrus has quit [Ping timeout: 245 seconds]
pkap has quit [Quit: Client closed]
SmarmyWalrus_ has quit [Ping timeout: 260 seconds]
waleee has quit [Ping timeout: 245 seconds]
waleee has joined #river
SmarmyWalrus has joined #river
SmarmyWalrus has quit [Ping timeout: 245 seconds]
tiosgz_ has quit [Quit: Reconnecting]
tiosgz_ has joined #river
* ifreund
remebers that firefox is gtk based, and now suspects a gtk bug
<ifreund>
I found a workaround though that isn't too bad
<novakane>
a gtk bug, no way :P
snakedye has quit [Ping timeout: 264 seconds]
snakedye has joined #river
<ifreund>
actually, I think this is a wlroots API awkwardness issue/borderline bug
<elshize>
ifreund: I also have awkwardness issue, let me know if you find a fix #puns
<elshize>
Whiskeyjack: hmm, can you try `riverctl map normal Mod4+Shift D spawn foot`?
<Whiskeyjack>
Ah, that worked.
<Whiskeyjack>
Thanks elshize !
<elshize>
Whiskeyjack: I think maybe your init doesn't correctly run? and your $mod isn't set?
<elshize>
what do you get with `echo $mod`?
Whiskeyjack has quit [Quit: Client closed]
Whiskeyjack has joined #river
<Whiskeyjack>
elshize Woops, lost my chat there. You're right, something is wrong. $mod is empty. But I'm not sure how that makes any sense, as the config is working fine otherwise (specifically keybindings using $mod)
<dnkl>
Whiskeyjack: are you running that specific map command from within the config? Or from the command line?
<dnkl>
$mod is only defined/set inside the init script...
<Whiskeyjack>
@dnkl I, uh, yep, I suppose that would explain it, eh? I guess I assumed whatever was done with riverctl would respect those variables. Thanks for the help!
<elshize>
Whiskeyjack: dnkl is right, scratch what i said... the variable isn't exported beyond the script, my bad. if you want to use it like that from your terminal, just define in shell
<elshize>
bashrc or whatever you're using
<dnkl>
Whiskeyjack: $mod is just a regular, unexported bash variable (assuming the example init script, which is a bash script)