<leon-p>
the resize PR is ready for a second round of review
<leon-p>
ifreund: ^
leon-p has quit [Quit: leaving]
ext0l has joined #river
<ext0l>
hmm. i appear to have discovered a couple crashes: one i can trigger by sleeping my laptop and unplugging/plugging in the usb dock (which has a monitor), and one that happend when you quit a fullscreen application under certain circumstances. going to see if i can find a consistent minimal replication
Guest4 has joined #river
<Guest4>
Why does firefox show a titlebar in river shouldn't decorations be hidden?
<Guest4>
if i use it under xwayland it doesn't but in wayland it does.
<Guest4>
Also sometimes dialogs are tiled is this a known bug?
blackCauldron7 has joined #river
Guest4 has quit [Quit: Client closed]
blackCauldron7 has quit [Client Quit]
blackCauldron7 has joined #river
snakedye has joined #river
kennylevinsen has quit [Remote host closed the connection]
kennylevinsen has joined #river
kennylevinsen has quit [Remote host closed the connection]
kennylevinsen has joined #river
xd1le has quit [Quit: xd1le]
<ifreund>
ext0l: please do open an issue for any crashes you can reproduces, fixing crashes is pretty much the highest priority thing to get done
<blackCauldron7>
Are dialogs supposed to be tiled or is it a bug?
<ifreund>
blackCauldron7: depends on the dialog, river can't always know that it's a dialog
<ifreund>
is there a specific program you're having issues with?
<blackCauldron7>
Its lutris starting dialog
<ifreund>
is lutris running through xwayland?
<blackCauldron7>
How to check? probably not though as other gtk stuff uses wayland
<ifreund>
xeyes is the most fun way to check
<ifreund>
if the eyes can track your cursor over the program, then it's running through xwayland
<blackCauldron7>
Lol i run xeyes in a wayland terminal? Would work?
<ifreund>
assuming xeyes is in your path and DISPLAY is set properly yes
<ifreund>
which should be the case if you haven't done anything weird
<blackCauldron7>
No it cant track it
<blackCauldron7>
And why does xwayland firefox doesnt have window decoration but wayland does it so ugly lol
<ifreund>
blackCauldron7: cause gtk doesn't implement the xdg-decoration protocol...
<ifreund>
you can disable it for firefox though in some preferences menu
<ifreund>
customize toolbar -> title bar checkbox
<blackCauldron7>
Thanks for the tip
<blackCauldron7>
And some QT windows are also cutoff if they are less than 50% width like keepassxc
<blackCauldron7>
Its not under xwayland keepassxc or QT
<ifreund>
blackCauldron7: keepassxc seems to work fine for me, what exactly do you mean by cutoff?
<ifreund>
keepassxc seems to request a rather large minimum size, which river respects
<blackCauldron7>
Oh so is it just me or does it cutoff for you too?
<blackCauldron7>
And do stuff like autotype don't work under wayland for security reasons or something?
<ifreund>
again, define cutoff. River (correctly) respects the minimum size that keepassxc requests, which may cause it to extend past it's expected size in tiled layouts
<blackCauldron7>
Probably a keepmenu bug then it can only autotype in xwayland windows for some reason
<ifreund>
it's probably using some x11 specific hack to do so
yyp has quit [Ping timeout: 252 seconds]
<blackCauldron7>
We have a matrix channel?
<ifreund>
blackCauldron7: you can join this IRC channel over the matrix bridge if you like
<ifreund>
but no, this is the only official channel
yyp has joined #river
yyp has quit [Remote host closed the connection]
yyp has joined #river
blackCauldron7[m has joined #river
<blackCauldron7[m>
Lol bridges are cool
blackCauldron7[m has left #river [#river]
<bfiedler>
window-titles is also ready for a second review :)
Guest32 has quit [Quit: Client closed]
<ifreund>
bfiedler: thanks for the quick response!
<ifreund>
second review is up
zxtx has joined #river
<bfiedler>
ifreund: thanks for the quick review! ready for the third review. I've squashed the changes and amended the commit message - it should be good to go from my end
<bfiedler>
Regarding the error messages: since the init script is a shell script users get pretty good context when using `set -x`, so I don't think we have to change anything there
leon-p has joined #river
<ifreund>
bfiedler: Yeah I agree, the new commit message looks great
<ifreund>
I posted a final round of review with some small style tweaks, hope you don't mind
bfiedler has quit [Remote host closed the connection]
bfiedler has joined #river
bfiedler has quit [Remote host closed the connection]
bfiedler has joined #river
leon-p has quit [Ping timeout: 240 seconds]
bfiedler has quit [Remote host closed the connection]
bfiedler has joined #river
leon-p has joined #river
bfiedler has quit [Remote host closed the connection]
bfiedler has joined #river
bfiedler has quit [Remote host closed the connection]
bfiedler has joined #river
bfiedler has quit [Remote host closed the connection]
bfiedler has joined #river
<leon-p>
ifreund: I don't think we can make it a protocol error when invalid edges are requested: XDG Toplevel does not define protocol errors, so I can't use postError() on it.
<leon-p>
Alternatively we could just ignore the request.
bfiedler has quit [Remote host closed the connection]
bfiedler has joined #river
bfiedler has quit [Remote host closed the connection]
bfiedler has joined #river
<bfiedler>
ifreund: I don't mind at all, thanks a lot for taking the time :)
blackCauldron7 has quit [Quit: Quit]
<ifreund>
leon-p: sure, ignoring it is fine. Even with my stricter interpretation of the protocol "none" would be a valid value for the client to request :D
<ifreund>
bfiedler: no problem, thanks for the contributions!
<leon-p>
I think our CI is dead again
<bfiedler>
"fitler" is an unlucky typo
<bfiedler>
leon-p: +1
<bfiedler>
what's the difference between a "toplevel" and a "view". I'm currently trying to figure out what to pass into "mayApplyCsd()`
<leon-p>
bfiedler: a view roughly equates to what is commonly called "logical window" on other windowing systems. toplevel is a term from the XDG shell for the same thing. In river, a view is an abstraction over multiple possible backends, one of which being an xdg toplevel.
<leon-p>
"toplevel" because it is at the top of the window tree. surfaces like popups have parents and are therefore not toplevels.
blackCauldron7 has joined #river
<bfiedler>
leon-p: thanks!
<ifreund>
however, xdg_toplevels can also have other xdg_toplevels as their parent :/
<bfiedler>
oof
<leon-p>
yeah, xdg popups aren't actually the kind of pop-ups you think. They are used for stuff like menus. A bit like subsurfaces.
<ifreund>
some examples, in firefox the right click menu is an xdg-popup
<leon-p>
What is commonly called a pop-up, like "open file" dialogs, are just xdg toplevels with a parent. It's a bit of a mess
<ifreund>
and that was the other example I was going to give ^
<leon-p>
ifreund: adressed all your reviews, btw. Made the type of the offsets i32, which got rid of a few intcasts and also should no longer crash when the pointer isn't actually above the surface (which could happen with toplevel resize requests)
<ifreund>
nice, I'll have another look in a bit
<bfiedler>
Extending title filtering to CSDs is not as straightforward as I thought. I've posted some remarks/questions on my current draft: https://github.com/ifreund/river/pull/424. Let me know what you think
<snakedye>
bfiedler: Wait a minute, i recognize from the eww issue 😅
<bfiedler>
snakedye: :wave:
<snakedye>
🙋🏾♂️
waleee has joined #river
ext0l has quit [Read error: Connection reset by peer]
ext0l has joined #river
<ifreund>
urgh, why does void suck so much for CI
<ifreund>
Maybe I'll just switch to alpine and figure out that github actions checkout nonsense myself
blackCauldron7 has quit [Ping timeout: 245 seconds]
blackCauldron7 has joined #river
<blackCauldron7>
Is this gonna make so we can use window classes or titles to set tiled fullscreen and other things?
<bfiedler>
correct
<bfiedler>
ah wait not fullscreen
<bfiedler>
you can apply floating status and csd on app-ids (classes) or window titles
<bfiedler>
floating is already merged
blackCauldron7 has quit [Ping timeout: 250 seconds]
blackCauldron7 has joined #river
blackCauldron7 has quit [Read error: Connection reset by peer]
blackCauldron7 has joined #river
<blackCauldron7>
Are there any examples of the command to do so?
<blackCauldron7>
Currently all x11 apps open in floating for me would like to force some to tile for eg sxiv
<bfiedler>
All X11 apps float? did you configure that to happen?
tdeo has quit [Ping timeout: 252 seconds]
tdeo has joined #river
novakane has joined #river
<blackCauldron7>
Nope
<blackCauldron7>
Maybe its not all x11 then only sxiv don't really have many x11 apps left now to test
<blackCauldron7>
Is there a wayland alternative to sxiv?
<blackCauldron7>
Yeah but it doesn't have a thumbnai gallery kind of mode its just too minimal
<bfiedler>
having all x11 windows opening as floating sounds like a bug then, they should be tiled by default
<blackCauldron7>
Maybe its not all x11 only sxiv I can't remember others rn as i replaced almost everything with a wayland alternative
<ifreund>
blackCauldron, bfiedler: river uses some simple heuristics to determine whether a window should be floating by default in an effort to catch most popup dialog things
<ifreund>
for xwayland clients, we look at the size hints the client has set and see if they have set their maximum and minimum size to be the same, essentially telling river that they have a fixed size
<ifreund>
if sxiv is doing that but can actually be resized, that's an sxiv bug IMO
<ifreund>
see the handleMap() function in XwaylandView.zig
<blackCauldron7>
Well np I guess once rules are implemented I can just make a rule for sxiv
<bfiedler>
ifreund: good to know, thanks
<bfiedler>
blackCauldron7: There's only positive logic (i.e. "x should float"), the reverse is not possible if I am not mistaken
<blackCauldron7>
It could be implemented maybe?
<blackCauldron7>
x should be tiled?
<ifreund>
it's certainly planned, but probably won't happen until I have more free time (read: sometime in october)
<blackCauldron7>
Is this wayland thing difficult do I have to be very good with 2d math and shit to contribute?
<bfiedler>
ifreund: is that part of the filter-daemon rework?
<ifreund>
bfiedler: it's a lot more than a filter-daemon that I want to make possible, though that is part of it. Basically I want to get rid of the current crappy river-control protocol and replace it with something much more featureful
<ifreund>
the tricky part will be syncing things up so that we don't lose frame perfection
<ifreund>
I have lots of ideas but too little time at the momement (exams, work, music festival...)
<blackCauldron7>
Are we aiming for parity with all bspwm config options?
<ifreund>
not at all
<ifreund>
river is it's own thing, we add features because we think they make sense not because some X11 window manager has them
<bfiedler>
ifreund: sounds good. I'll also have some free time in october and would like to start contributing some if possible
<ifreund>
I think you already started :P
<blackCauldron7>
Yeah I respect that its just all bspwm config makes sense too atleast too me especially their rules part
<bfiedler>
hopefully I can keep it up :D
Guest32 has joined #river
Guest32 has quit [Client Quit]
<novakane>
ifreund: 10 days of holidays, I'm back and see all this email for reviews in river but not for input_method, very disapointed :P
<ifreund>
I thought it was still a draft? You have a button to mark it ready for review :P
<ifreund>
hope you had a good vacation :)
<novakane>
ah damn you got me :P, for real though I don't need a full review but if you have some time to look at the relay creation and relation with Seat, not the input_mmethod text_input implementation
<novakane>
yep very relaxing, it feels good, it's been a long time :D
blackCauldron7 has quit [Quit: Quit]
elshize has quit [Ping timeout: 245 seconds]
leon-p has quit [Ping timeout: 245 seconds]
elshize has joined #river
leon-p has joined #river
snakedye has quit [Read error: Connection reset by peer]
snakedye has joined #river
novakane has quit [Ping timeout: 240 seconds]
novakane has joined #river
<waleee>
bfiedler: qimgv
<waleee>
* qimgv's gallery view can be slimmed down to sxiv's level (will use more system resources though)
<bfiedler>
waleee: I'm happy with imv, thanks :)
blackCauldron7 has joined #river
<waleee>
bfiedler: oops, it was blackCauldron7 that asked for sxiv alternatives, sorry
<bfiedler>
np, they just returned :D
<blackCauldron7>
is there a way to make games launch fullscreen? I know why this ain't probably default maybe coz of xwayland
<ifreund>
blackCauldron7: river doesn't listen for xwayland fullscreen requests currently, this would be trivial to add if someone were interested
<blackCauldron7>
You mean somewhere were interested for the feature or to implement it?
<ifreund>
if someone was interested in implementing it
<blackCauldron7>
someone*
<blackCauldron7>
Could you point me to some docs?
<ifreund>
blackCauldron7: you're looking for wlr.XwaylandSurface.event.request_fullscreen
<ifreund>
and all you should need to touch is XwaylandView.zig
<blackCauldron7>
Thanks Ill try to make a PR if it turns out to be trivial
<ifreund>
you can look at the code in XdgToplevel.zig handling request_fullscreen for an example
<blackCauldron7>
Feels like I am missing something? Do I really have to only add a listener and no logic at all?
<ifreund>
see handleRequestFullscreen() in XdgToplevel.zig
<leon-p>
ifreund: any other feedback for the resize PR? I think it's pretty much done.
<leon-p>
(just asking because I have a lot of time right now to change things if necessary)
<blackCauldron7>
How do you guys test a wm during development? Nested session?
<leon-p>
blackCauldron7: I just use a different TTY
<blackCauldron7>
And is there something for zig that watches the src and recompiles stuff?
<leon-p>
what's wrong with just running zig build before you want to test something?
<blackCauldron7>
Nothing was just curious
<ifreund>
not currently, there almost certainly will be eventually though
<ifreund>
currently you are using a compiler that is still partially implemented in C++ and is really slow/wasteful of memory
<ifreund>
the self hosted zig compiler is well underway and will support incremental compilation for debug builds
<ifreund>
leon-p: I'll have another look
<leon-p>
ifreund: thanks!
<blackCauldron7>
Just out of curiosity why choose zig for this project?
<ifreund>
cause it's the the only thing I've found that I actually find better than C for systems programming
<blackCauldron7>
Actually i think zig-wlroots doesnt make request_fullscreen public for some reason
<ifreund>
it does
<ifreund>
leon-p: got you another round of review, looks like theres a bug on outputs not at 0,0
<blackCauldron7>
Tried accesimg it didnt work for me
<ifreund>
example of accessing the events struct
<blackCauldron7>
Got it thanks
<bfiedler>
Is there something I can help with wrt CI?
<ifreund>
bfiedler: I'm open to pretty much anything wrt CI if I don't have to do it. You should be able to test whatever github actions config you want by opening a PR with your changes
<ifreund>
maybe we should just switch to debian, I don't know what you're familiar with
<ifreund>
we already build wlroots from source so it's mostly just a recent enough libwayland version we'd need to worry about
<bfiedler>
I am most familiar with that :D but unfortunately it's big pain in the butt to get zig to run on Debian
<ifreund>
how so? can't we just grab a static tarball from ziglang.org?
<bfiedler>
probably
<bfiedler>
I remember trying getting river to run on testing and it was pretty painful
<ifreund>
maybe debian's not the way then
<bfiedler>
I think I tried compiling the compiler though, now that I think of it
<ifreund>
a static tarball from ziglang.org should be foolproof
<bfiedler>
I have a test machine that I can try this on
<ifreund>
the only potential blocker I know of is recent enough dependencies for wlroots
<bfiedler>
If we use unstable as base then it should be fine
<ifreund>
alpine edge would probably work great, but apparently githubs checkout action step thing is totally broken on musl systems
<bfiedler>
that said, Debian unstable only has 0.13
<ifreund>
maybe we can use an older version of that or just roll our own checkout thing
<bfiedler>
I think that was the final nail in the coffin why I gave up running it on Debian
<ifreund>
we're already building wlroots from source currently for the CI
<bfiedler>
alpine is first class citizen over on sr.ht
<ifreund>
leon-p mentioned that we could use his sr.ht account for river CI if someone sets it up
<ifreund>
it would be pretty cool to have freebsd CI
<bfiedler>
I also have an account there, I can also have a look
<bfiedler>
> When setting up a new GitHub task on dispatch.sr.ht, your GitHub repositories will be shown for selection. This list only contains repositories for which you are the owner.
<blackCauldron7>
Yes made it work brilliant lol thanks for the help
<bfiedler>
The documentation speaks the truth
<bfiedler>
I can't even see forks lol
<ifreund>
bfiedler: hrm, I haven't been able to log in to my sourcehut account since they did the contributor/maintainer account split, I should probably send drew an email or something
<bfiedler>
probably
<ifreund>
that kinda makes it sound like I would need to have a maintainer sourcehut account to hook up the CI to github though
<bfiedler>
nah the sr.ht account doesn't matter
<bfiedler>
you need to own the github repo though
<bfiedler>
oh sorry I misread
<bfiedler>
yeah that sounds right
<bfiedler>
stupid question but why not build everything from the versions tagged in the submodules?
<ifreund>
not quite sure what you mean?
<bfiedler>
are the deps in `/deps` not sufficient to build river?
<ifreund>
nope, those are just zig bindings to C libraries
<ifreund>
the actual C libraries are required as well
<bfiedler>
oh, that's where my mistake was
<ifreund>
anyhow, I think the lowest friction way to get things working in the short term would be to switch the CI back to arch linux
<bfiedler>
can confirm works well
<ifreund>
iirc I switched it to void because I was tired of waiting for arch to update wlroots or something
<ifreund>
but now we build that from source
<bfiedler>
"tired of waiting for arch to update x" that's like lightning fast IMO :D
<ifreund>
it depends, the arch update process is out of my control
<ifreund>
while I maintain the wlroots package for void and can just patch the compositors and push the update as soon as I feel like it
elshize has quit [Remote host closed the connection]
<bfiedler>
it looks to me that the issue is not river-dependent but some void stuff related to xbps
blackCauldron7 has quit [Quit: Quit]
<ifreund>
yeah, it's just void being stupid
elshize has joined #river
novakane has quit [Quit: WeeChat 3.2]
ext0l has quit [Quit: WeeChat 3.2]
snakedye has quit [Read error: Connection reset by peer]
dbuckley has quit [Read error: Connection reset by peer]
dbuckley has joined #river
ext0l has joined #river
<ext0l>
ifreund: hmm. after updating river, the method that i had to repro the crashes. so maybe this was one of the use-after-frees you fixed recently
<ext0l>
will definitely file a bug if i can get it to happen again ofc
notzmv has quit [Read error: Connection reset by peer]