ifreund changed the topic of #river to: river - a dynamic tiling wayland compositor - https://github.com/ifreund/river - channel logs: https://freenode.irclog.whitequark.org/river/
leon-p has quit [Quit: leaving]
waleee-cl has quit [Quit: Connection closed for inactivity]
_whitelogger has joined #river
<novakane[m]> leon-p: lswt detecting outputs work great now 👍️
yyp has joined #river
yyp has quit [Client Quit]
yyp has joined #river
<ifreund> man I hate how !strcmp(argv[i], "-j") reads
<ifreund> lswt looks nice though
<dnkl> ifreund: I never use '!' with strcmp...
<yyp> strcmp(...) != 0 :)
<yyp> yet I still use if(strcmp(...)) sometimes...
<ifreund> dnkl: agree that == 0 would be prefereable, but the fact remains that !strcmp() is vaild and correct C
<ifreund> (to be clear C is probably my second favorite language despite stuff like this)
<emersion> as always, you just need to write clear C, and it's all good :P
<ifreund> of course :)
<yyp> ^
<ifreund> better language and library design can eliminate tons of things like this though
<emersion> yeah
<emersion> no shotguns = more happy
<yyp> Some people in the wild think that footguns are useful
yyp has quit [Quit: disconnected]
yyp has joined #river
<dnkl> I have yet to see a language where you can't write unreadable code... but C might offer more ways do that than others, for sure
<ifreund> yep, it's certainly not black or white
<ifreund> for me Zig has been a significant improvement over C though, only downside is the immautrity
<emersion> i rarely find unreadable Go code. but not really the same problem space as C
<ifreund> Yeah, I don't mind Go but it also doesn't really fit for any of the things I'm currently interested in working on
<yyp> Maybe, but Go doesn't solve all problems. You can still find code that is quite hard to read and understand what it does (I've worked on such a codebase)
<emersion> yeah, i'm mostly comparing to other languages
<emersion> not having any kind of generics and macro system helps a lot in preventing people from abusing these features
<yyp> Then yeah, I find most Go code much more readable then Rust or C
<emersion> i don't think it's possible to have a language where it completely impossible to write bad code ;)
<yyp> Agree, people will always find a way to write bad code
<ifreund> well, Go is adding generics soon iirc, and for good reason IMO
<ifreund> zig's comptime solves the use-cases of both generics and macros with one relatively simple feature
<yyp> ifreund: how does it help with generics? I thought it was only a simpler macros thing
<ifreund> yyp: you can pass types as first class values at comptime
<ifreund> so generics are nothing more than functions taking arbitrary parameters and returning a type
<yyp> Can you give a code example?
inclement has quit [*.net *.split]
dnkl has quit [*.net *.split]
mmurd has quit [*.net *.split]
dnkl has joined #river
mmurd has joined #river
inclement has joined #river
<ifreund> that's a greatly simplified version of the growable array available from the standard library
<ifreund> compare to rust's Vec
<yyp> Thanks!
leon-p has joined #river
snakedye has joined #river
<leon-p> novakane[m]: glad it works for you
<leon-p> ifreund: you're right about !strcmp, it's a bad habit :D
<leon-p> (fixed it)
<ifreund> ^^
<novakane[m]> ifreund_ would you be interested in a PR for zsh completion for riverctl ?
<ifreund> sure
<novakane[m]> Ok cool I'm gonna share it then
<yyp> That would be actually quite useful, looking forward to it
<ifreund> If you don't want to mess with the zig build system feel free to just open the PR, I can do that part
<yyp> .addInstallFile?
<novakane[m]> ifreund_: Ok, in which folder do you want me to put it?
<yyp> novakane[m]: contrib/ is the best place
<ifreund> novakane[m]: completions/zsh/
<novakane[m]> alright that's what I thought
<novakane[m]> done, didn't change the zig build system since I'm learning zig since like one week and didn't already look into build
<novakane[m]> probably better if I don't touch it
<ifreund> thanks, I'll get it integrated and merged when I have a minute
snakedye has quit [Ping timeout: 240 seconds]
<novakane[m]> no problem
<leon-p> I'll be working on bash completions then
<leon-p> by the way, we are clearly missing an option to focus an output directly by its name.
<ifreund> I plan on solving that in river-control-v2
<leon-p> submitted a PR for riverctl bash completions.
<leon-p> if we had commands for things like list all modes we could certainly improve the completions. but thats just sugar, i guess.
<novakane[m]> the perfect thing would be to have like completion for app-id and tags
<leon-p> that is possible
<leon-p> app-ids at least
<leon-p> to get all app-ids: `lswt -t | cut -f2`
<leon-p> I am just not sure it is a goot idea to add a non-standard tool into the completion script
<novakane[m]> Yeah I thought about doing it like that but yes an external tool is not really a great idea
<ifreund> I don't want the default one we ship doing a bunch of work
<ifreund> it might be cool to write a client that acts as a super smart river-specific shell
<leon-p> would make sense as a layer shell thing. Press Super+colon to get a river-prompt, like in any terminal editor
<ifreund> yeah, that's the direction I was thinking in
<ifreund> and that would be a purpose build wayland client, so it could keep track of river's state for smart completions
<dnkl> ifreund: btw, looking forward to an explanation for https://github.com/ifreund/river/issues/235
<yyp> dnkl: Something related to foot/fnott/yambar I think (not river)
<leon-p> yeah that one is spooky. I initially suspected htop sets the term title and something receiving that does not like the title, but I dont think htop does, at least no on my machine™
<dnkl> htop doesn't set anything on my machine either. My *shell* sets it to 'htop', but htop doesn't change it
<yyp> ¯\_(ツ)_/¯
<dnkl> my guess is it's something in the interaction between foot's shutdown procedure and river's
<yyp> Maybe, log says "attempt to use null value" BEFORE foot terminates
<leon-p> I can't reproduce it, but I found a different issue: if river closes, foot hangs and does not respond to sigterm
<dnkl> foot will destroy lots of Wayland objects while shutting down. If river has already destroyed them, perhaps things blow up
<dnkl> foot uses the relatively new wl_output_release() API. Not sure how many other clients do (and thus how well tested it is on the compositor side)
<dnkl> leon-p: 1.6.4 or git HEAD?
waleee-cl has joined #river
<leon-p> let me check...
<leon-p> oh damn, I am on some ancient version
<dnkl> :)
<dnkl> 1.6.4 switched to a different signal handling model, compared to 1.6.3 and older. That introduced one (known) regression (ctrl+shift+n spawned sub-terminals don't exit when the client application terminates) that has been fixed in git, but hasn't been included in any release yet.
<dnkl> but if you're on something older than that, who knows :)
<leon-p> ah you moved away from signalfd, I see
<dnkl> yup
<leon-p> that thing is quite a let down. Promises abstracting the most painful thing of POSIX into a nice fd, and then it doesn't work half of the time and messes with the signal mask behind your back
<yyp> dnkl: I tried the same but it doesn't seem to crash river. Only foot blows up. Logs I guess: https://termbin.com/19620
<dnkl> yyp: foot crashes?
<yyp> (EE) failed to read Wayland events: Broken pipe
<dnkl> yyp: I don't see any logs from foot there...
<yyp> wait no
<yyp> my bad, it doesn't
<dnkl> that would be xwayland ;)
<yyp> (EE)-thing?
<dnkl> leon-p: yeah, using signalfd didn't solve anything at all really. Just made it _slightly_ more convinient to use in the select loop
<dnkl> yyp: yeah. Or something that logs things on the same format as X(wayland) does...
<leon-p> nice to see that line-height is now a thing, btw. That is the one main thing I was missing from other terminals
<dnkl> leon-p: out of curiosity; why/what do you need it for?
<leon-p> to have a bit of spacing between lines. I find that easier to read
<leon-p> and unlike alacritty, foot does not mess up line drawing chars with increased line-sizes, nice!
<dnkl> leon-p: starting with 1.7, foot renders line drawing chars by itself, rather than using font glyphs (like Alacritty does)
<dnkl> if you use font glyphs, there's no way to *not* mess them up when you override the font's line height...
<leon-p> yeah i figured
<dnkl> but, I think line-height (in foot) breaks if you zoom (increase the font size at run-time)...
* dnkl should go and verify that
<leon-p> yeah it does.
<leon-p> but at least it lools funny, so thats something
<leon-p> and I don't think any other terminal handles it that much better, soo...
<dnkl> hmm, line-height can be specified in either pixels or points (defaulting to points)... so no reason why we can't increase the line-height as well when zooming in/out
<dnkl> at least if it's in points
<yyp> Why does river steal swaybg when running a nested session?
<leon-p> do you have something like "killall swaybg && swaybg" in your river init?
<leon-p> dnkl: btw, dpi detection is a bit off a mess on my ultra wide screen. Is there any chance that could be improved? If yes, were would I have to look in the code?
<dnkl> it's mostly using the compositor-provided values though
<dnkl> and there's always the option to disable DPI awareness (dpi-aware=no|yes|auto)
<leon-p> i see, I'll have a look
<leon-p> yeah I have to turn of dpi right not, otherwise the font gets way to small
<dnkl> first step might be to just check foot's log output; is the display geometry correct?
<leon-p> it is
<dnkl> leon-p: are you using output scaling on that monitor?
<leon-p> nope
<leon-p> nfo: wayland.c:1179: HDMI-A-1: 2560x1080+0x0@60Hz LG ULTRAWIDE 34.22" scale=1 PPI=82x83 (physical) PPI=82x83 (logical), DPI=81.19
<leon-p> ^ foots output
<dnkl> ah, ok. Was going to say that the default behavior wrt scaled outputs changed in 1.6 (I think?)
<dnkl> fwiw, https://www.sven.de/dpi/ agrees with foot's calculations
<leon-p> hmm... must the monitors EDID
snakedye has joined #river
<leon-p> it does not contain the correct resolution, so I have to use a custom mode.
<leon-p> So likely it also does not contain the correct physical size...
<dnkl> is 34.22" wrong?
<leon-p> wait, I'll measure
<leon-p> its 74cm from corner to corner (diagonal), which according to qalc is 29.1 inches
<yyp> Re: do you have something like "killall swaybg && swaybg" in your river init? oh, forgot about it
<yyp> nevermind
<dnkl> leon-p: that would mean a DPI of 95-96. If you re-enable dpi-away=yes, and do "foot -f <font-name>:dpi=96", how does that look?
<leon-p> still too small
<dnkl> leon-p: (and of course, don't forget to configure the size too... "foot -f <font-name>:size=xx:dpi=96")
<leon-p> thats better
<leon-p> clashes with the line-height config though
<dnkl> leon-p: might have to increase line-height?
<dnkl> setting line-height should change the cell height only, but not affect the font size
<leon-p> ah yes, I had to double the line size
<dnkl> but, it completely overrides the font's line height, so you need to manually adjust
<dnkl> i.e. it's *not* line-spacing
<leon-p> but overriding the dpi isn't really a solution, because then it looks bad when I move the window to my laptop screen :D
<leon-p> so I guess I keep DPI off for now
<leon-p> I wonder if the EDID is flashable...
<dnkl> yeah, in that case fixing the reported physical size is the only option
<leon-p> anyway, thanks for the help
<dnkl> leon-p: no worries :)
<leon-p> ah, apparently there is a tool to override the EDID, but its windows only -_-
<dnkl> ifreund: leon-p: would it be possible to override display EDIDs on the compositor side? Or are there better ways to do it?
<snakedye> what exactly is namespace (layout protocol) and what is its purpose?
<leon-p> snakedye: it allows river to choose the active layout
<snakedye> does that mean the layout generator could handle multiple layouts at the same time?
<leon-p> so if you have multiple layout daemons, advertising multiple different layouts, they all have different namesapces (like f.e. "tiled", "fibonacci", "whatever").
<leon-p> yes
<leon-p> rivertile does that
<leon-p> for each main window direction there is a different layout
<leon-p> (arguable we should instead have a direction option, but it works nonetheless)
<snakedye> hmm i didn't see that that way so I've done all that stuff for selecting layout internally 😅, i though it was to differentiate 2 layouts on different outputs
<snakedye> also how do you get a request? is it with the registry listener? can i ask river to update the layout or do I always have to wait for a request
<leon-p> generally you wait for one. But you can inform river that the parameters on which your layout is based have changed, in which case river _might_ start a new layout demand.
<snakedye> what does the might mean?
<leon-p> currently if that layout is not the active one (meaning the one last used on this output) it gets ignored.
<leon-p> in the future there might be additional conditions
<leon-p> river makes no guarantees that anything a layout daemon sends it is respected
<leon-p> if you have anymore layout questions I can answer them in about 1h, but now I have to go shop some groceries, I am all out.
<ifreund> and you've only got 1:50 until netto is closed till monday!
<ifreund> I don't know anything about display EDIDs, if that's something the compositor is advertising over the wayland protocol I'm sure it would be possible to override though
<leon-p> its nothing the compositor advertises, its the data on a ROM chip in the monitor that contains stuff like the available modes and physical size
<ifreund> with regards to that crash, I was unable to reproduce it 3 days ago and haven't had time to try again yet.
<ifreund> hmm, I feel like the compositor shouldn't touch that then
<dnkl> ifreund: it's not advertising it directly; but it is advertising data _from_ it (like the display's physical size)
<dnkl> "override EDID" may not have been the best choice of words...
<dnkl> ifreund: the interesting pieces (in this case), are width/height in output_mode(), and physical_{width,height} in output_geometry()
<emersion> it's possible to override EDIDs on the KMS side
<emersion> either via a kernel param, or via… sysfs i think?
<emersion> the kernel also has a list of quirks, i don't know if fixing phys_width/height can be done there
<dnkl> emersion: thanks, I'll see if I can dig up some documentation on that. Would be useful to be able to redirect people to
<emersion> hm, drm.edid_firmware=HDMI-A-1:edid/override.edid
<emersion> not exactly the most sexy way to configure something
<dnkl> leon-p: ^
<dnkl> emersion: great, just knowing it's possible helps
<emersion> ah, you can do it at runtime via debugfs
<emersion> the debugfs entry is override_edid
<leon-p> ah nice, I'll keep that in mind
<snakedye> leon-p did you get your groceries?
<leon-p> yes, I got everything I need :)
<snakedye> Nice
<leon-p> in other words, all layout questions welcome :D
<snakedye> regarding listener, I've seen it appear in rivertile and rilay but I can't find it in the file generated from the rust scanner.
<snakedye> is it part of the layout protocol or am I looking in the wrong place?
<leon-p> the listener is just an abstraction
<leon-p> the wayland client library receives an event and then calls the function you registered for that purpose
<leon-p> I have no idea how the rust lib you are using abstracts over that though, if at all.
<leon-p> can you paste the code the scanner spits out somewhere? I don't know much rust, but perhaps something looks familiar
<snakedye> `self.layout.?.setListener(*Layout, layoutListener, self)` here it looks like `setListener` is a method from layout or the Layout object.
<snakedye> It's from rivertile btw
<leon-p> ugh, those are rust macros eh?
<leon-p> well, you see in the file were is says `LayoutDemand {`?
<leon-p> That is an event, meaning a message from the server to the client.
<leon-p> and that pub enum Event is probably what the rust version of a listener receives, if I had to guess
<snakedye> I see
<leon-p> do you have an example of that rust lib used somewhere?
<snakedye> I followed the instruction here to generate the code https://docs.rs/wayland-scanner/0.28.5/wayland_scanner/ and here is the crate I used for the scanner https://crates.io/crates/wayland-scanner
<leon-p> hmm, the docs on that aren't exactly stellar
<snakedye> when i search for wl_listener this is the best i can find https://smithay.github.io/wayland-rs/wayland_sys/server/struct.wl_listener.html
<snakedye> it doesn't really explain much and it seems to be server side
<leon-p> it explains the wayland-client crate
<leon-p> but I certainly hope the code their scanner outputs follows the same rules
<leon-p> apparently the lib has something called "Filters" instead of listeners
<leon-p> but they apparently also just call callback functions. so you just have to find out how to register those
<snakedye> `Filter` indeed looks like what I was looking for.
<snakedye> well thanks for that, I'll do more reading later
<snakedye> other question regarding tags and layouts per tags. does the layout protocol have an internal infrastructure for this or has it got to be implemented by the layout generator?
<leon-p> no, the layout protocol does not have that concept. youll have to use river status to listen for tag events and update the layout accordingly
yyp has quit [Quit: disconnected]
<snakedye> the "advertise_view" event seems to provide the current tag to the generator. why would I need river status?
<leon-p> does it? huh
<leon-p> well those are the tags of the view, not of the output
<snakedye> what does that mean?
<leon-p> views have tags and outputs have tags
<leon-p> with advertise_view, you only get the ones of the view
<leon-p> but that is not the current tag state of the output
<snakedye> is the tag of the view is meant to identify the order of the view in the internal list of window?
<leon-p> no
<leon-p> the view tags and th output tags are both responsible for deciding which view is currently visible
<leon-p> just like how an output can have multiple active tags, a view can have multiple tags as well
<snakedye> an output can have 10 tags if I'm not mistaken and then display multiple at the same time. what does it look like when you change the tag of a view? do they disappear?
<leon-p> an output has 32 tags
<leon-p> the view disappears if none of its tags matches one of the output tags
<snakedye> okay... i get it now
<snakedye> I think that's it for today
<snakedye> thanks for the help
snakedye has quit [Ping timeout: 240 seconds]