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>
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?
<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
<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