00:13 <mekss> river with nouveau works fine, but opengl stuff (alacritty and chromium) are flickering as hell. Maybe i can fix that

00:19 <elshize> mekss: fwiw I do use proprietary though on fedora; and not running the newest river either because of some annoying deps I'm waiting fedora to update

00:20 <elshize> but at the same time, not the greatest experience, got some flickering here and there. but nouveau didn't work at all, so I'm stuck with that

00:30 <mekss> elshize, I get flickering only in x11. in river everything pretty smooth

08:18 <kraem> hi, `riverctl toggle-fullscreen` makes chromium go into presentation mode for me (without the tab+address bar). my google-fu isn't helping me find any settings / flags to disable this behaviour and keep the tab+address bar visible in fullscreen. did anyone encounter this?

09:06 <monaaraj> Yep! Happens in firefox too, only I did find a method to disable it in firefox, though I don't think that can help there. It's not particularly a bug, it's an intended feature in most mainstream browsers I've seen

09:32 <kraem> thanks. yeah i was able to disable it in firefox with browser.fullscreen.autohide - can't find the equivalent for chromium on linux though. on macos people seem to be able to go to fullscreen / presentation mode by adding shift to cmd+f

09:39 <kraem> i can't seem to alter the padding of rivertile in runtime with `riverctl send-layout-cmd rivertile "{-,}{outer,view}-padding 0"`. is that not supported or am i doing something wrong?

09:41 <ifreund> kraem: that's right, rivertile doesn't support setting the padding at runtime currently

09:46 <kraem> thanks :)

09:52 <novakane> oh, that's a good thing to add to rivercarro

09:56 <novakane> ifreund: doing this I saw https://github.com/riverwm/river/blob/master/rivertile/main.zig#L173 we could use saturating arithmetic now no?

10:01 <novakane> `output.main_count +| @intCast(u32, arg)` should works if I correctly followed the changelog

10:57 <novakane> huh why I have a parse error here, that's literally the same thing that `main-count`

10:58 <novakane> ah nvm I'm dumb

11:00 <novakane> hmm or not... I thought I forgot to change something in the parse command for the cli flag but there is no need

11:01 <ifreund> novakane: yes for sure! I knew there was some place I wanted to use the new saturating operators but couldn't remember where

11:01 <ifreund> patches welcome :)

11:01 <ifreund> there's probably other places we could use them as well

11:02 <novakane> ifreund: sure, I'll finish this on rivercarro and I'll change it here and look around if I found some other places

11:03 <ifreund> thanks!

11:03 <novakane> any idea why I have this parse error above?

11:03 <novakane> with '+/-' before the value

11:04 <ifreund> could you post the error?

11:04 <novakane> failed to parse argument: error.InvalidCharacter

11:05 <ifreund> from the zig compiler? or rivertile?

11:06 <novakane> changing it with `riverctl send-layout-cmd rivercarro "outer-padding +10"` throw this

11:06 <novakane> though it works for all others command so I don't get it why

11:07 <ifreund> not sure, must be a new bug somewhere

11:07 <ifreund> I gotta run though, cya later o7

11:08 <novakane> o7

11:09 <novakane> in case you come back before I can fix this, here the whole code

11:09 <novakane> ~  riverctl send-layout-cmd rivercarro "outer-padding +10"

11:09 <novakane> ~  riverctl send-layout-cmd rivercarro "outer-padding +10"

11:09 <novakane> ~  riverctl send-layout-cmd rivercarro "outer-padding +10"

11:09 <novakane> ~ 

11:09 <novakane> ~ 

11:09 <novakane> ~  riverctl send-layout-cmd rivercarro "outer-padding +10"

11:09 <novakane> ~  riverctl send-layout-cmd rivercarro "outer-padding 10"

11:10 <novakane> whoops wrong copy paste

11:10 <novakane> https://git.sr.ht/~novakane/rivercarro/tree/gaps-runtime/item/src/main.zig#L167

11:34 <ifreund> novakane: the error is probably coming from fmt.parseInt()

11:49 <novakane> ifreund: yeah but why though? It does works for main-count

12:20 <novakane> hmm it works now and I didn't change anything lol

13:02 <novakane> allright changing gaps size at runtime should now works in rivercarro

17:32 <kraem> quick question: is `riverctl default-layout $LAYOUT` suppose to call the binary (rivertile/rivercarro) or just a "namespace"?

17:47 <leon-p> kraem: the namespace

17:47 <kraem> oh it seemd all riverctl cmds just wanted a namespace

17:47 <leon-p> although in practice namespace and name of the executable are usually identical

17:47 <kraem> s/seemd/seemed/

17:48 <leon-p> yes, all layout related commands need a namespace.

17:50 <kraem> it seems they are not equal in this case? riverctl wants just the namespace as my init-script doesn't have rivercarro in its PATH and only works when i provide it the namespace, not the full path to rivercarro (except the last exec statement)

17:50 <leon-p> kraem: the full path to the executable is not it's (base-)name

17:51 <leon-p> so yes, of course the namespace is not equal to the full path (although you could write a layout gen that does that, it would not make much sense though)

17:54 <kraem> so when river is "bootstrapped" it takes the path to the executable so it later can call it when called with only the namespace?

17:56 <leon-p> no

17:56 <leon-p> the namespace is something the layout generator sets itself when it connects to river

17:56 <leon-p> river does not care about the path to the layout gen executable. It may not even launch it directly.

17:58 <kraem> oh alright. i think i need to read up on the details hehe. thanks!

17:58 <leon-p> kraem: as it so happens, i wrote a blog post on river layouts :P

17:58 <leon-p> https://leon_plickat.srht.site/blog/explaining-river-window-layouts/article.html

18:00 <leon-p> although the namespace thing really is quite simple. The layout gen connect say, says "hi, I have layout for outputs X, y and Z, all with the namespaces foo". Then river checks if the namespace is valid. If not the layout generator is asked to disconnect. If it is valid, river checks if the namespaces matches what the user configured for the output. If it does match, the layout demand process is initiated.

18:02 <kraem> nice, thanks!

18:23 <kraem> leon-p: curious. the ssl cert of your site didn't work on ios but it works fine on my laptop

18:26 <kraem> novakane: just tried your patch with {inner,outer}-gaps at runtime. works perfectly :) thanks

18:35 <leon-p> kraem: interesting indeed. But the cert is managed by sourcehut, not much I can do about it (or want to, managing a site is more annoyance than I have energy for)

18:48 <angry_vincent> what is passthrough mode?

18:52 <alebastr> elshize: "because of some annoying deps I'm waiting fedora to update" - is it about wlroots 0.15?

19:10 <novakane> kraem: nice, glad you like, don't know why I didn't add this before tbh

19:13 <novakane> angry_vincent: a mode where river doesn't detect the keybinds, useful to use river in a nested session of river for example

19:14 <angry_vincent> ah, ok

19:20 <mekss> why would river crash after I apply kanshi configuration? It only crashes if I do >50 fps on my monitor

19:20 <mekss> sway does not crash

19:25 <angry_vincent> can i hide application, so that it is invisible but can be brought up if needed, similar to sway's scratchpad?

19:27 <kraem> novakane: do you mind if i submit a rivercarro package to nixpkgs?

19:33 <ifreund> mekss: I suppose you're probably hitting this: https://github.com/riverwm/river/issues/508

19:33 <ifreund> angry_vincent: send it to a tag you can't see

19:34 <ifreund> angry_vincent: https://github.com/riverwm/river/wiki/Scratchpad

19:36 <ifreund> mekss: any chance you could get debug logs of the crash happening? Ideally build river in debug mode and run with `-log-level debug`

19:36 <ifreund> the easiest way to get logs is to run from a tty and redirect stderr to a file

19:36 <mekss> will do

19:37 <ifreund> for example, `river 2> out.log`

19:37 <ifreund> thanks!

19:40 <angry_vincent> ifreund: oh, nice, this is good, how do i put something to tag 13, for example? so that it is recognized as 13 an not 1 and 3?

19:41 <ifreund> $(( 1 << 13 )) ?

19:41 <ifreund> aka 8192

19:41 <ifreund> 2 to the power of 13

19:42 <angry_vincent> not sure i understood what is the key combination for this

19:43 <ifreund> angry_vincent: the example on that wiki page uses P

19:43 <ifreund> you can use whatever you like though of course

19:44 <novakane> kraem: no feel free to do so :)

19:46 <kraem> novakane: :)

20:28 <Grawp> Is there a possibility to focus an output by a mouse if there is no view displayed on it?

20:30 <leon-p> unfortunately no

20:30 <leon-p> but it would be a simple addition, if you'd like to tackle it

20:42 <ifreund> Grawp: I'm pretty sure that works if you click somewhere on the emtpy background of the output

20:43 <ifreund> well, since 0.1.1 at least

20:45 <Grawp> ifreund oops, I'm on 0.1.0, I'll have to update. (Clicking on an empty background does nothing in 0.1.0).

20:52 <Grawp> Thanks for the info.

20:58 <kraem> i just realised after having used river for one day the performance is amazing. the fans of my mbp 2012 doesn't ramp up to max level while watching hd video. i'm wondering if the optimisation is not running a separate compositor like in xorg (even though i only ran picom to get rid of screen tearing, no extra effects other than that) or if it's at the protocol level (wayland vs x). anyway, thanks

20:58 <kraem> for a great project!

21:07 <elshize> alebastr: I mean yes, wlroots 0.15 not in fedora, but when I try to compile it I think there's another wayland-related package that's outdated; so I just figured I'd wait unless until that one is resolved, can't be bothered currently to go into the dependency rabbit whole ;)

21:15 <alebastr> elshize: ah, yes. it needs wayland-server 1.20. Well, that won't be ever updated in f35 official repos, as our policy forbids breaking updates in stable releases.

21:15 <ifreund> kraem: The architecture of wayland cetainly makes things possible that aren't possible on X. I can't take too much credit for river's performance though, most of that work happens in the parts of wlroots I don't really touch :D

21:16 <ifreund> alebastr: it's not breaking though?

21:17 <alebastr> elshize: I have copr builds for latest river & wlroots 0.15. alebastr/river and alebastr/sway-testing

21:17 <ifreund> I guess it might break the build of things like SDL or firefox that want to dlopen wayland

21:17 <alebastr> ifreund: wl_output v4. and overall our wayland maint team doesn't take unnecessary risks

21:17 <ifreund> wl_output v4 isn't breaking

21:18 <ifreund> many clients have bugs though

21:18 <ifreund> a well written client won't be broken

21:18 <alebastr> it surely broke a few apps that weren't binding the protocol correctly. including everything based on chromium

21:18 <ifreund> really this is a severe shortcoming of libwayland's API

21:19 <ifreund> it shouldn't be easier to do the wrong thing that the right thing

21:23 <novakane> this wl_output v4 release really has been a great learning lesson for wayland programmer huh :P

21:27 <alebastr> yep. too bad that gnome still haven't started using v4 it in mutter. that would break^Wencourage people to fix more applications

21:34 <elshize> alebastr: I might give those packages a try over the weekend if I find some time. thanks for the tip!

21:48 <leon-p> alebastr: pretty sure I read somewhere that mutter won't update interface versions if nothing in the GNOME stack uses the new events/requests. That's why the input interface versions are effectively frozen in GNOME land

22:18 <mekss> how do i build river in debug mode?

22:22 <leon-p> mekss: zig builds in debug mode by default

22:22 <leon-p> so just do `zig build`

22:26 <n8_> hello. I am trying to configure river/wayland to only output to an external monitor when my laptop is docked with the lid shut. Any ideas?

22:31 <n8_> To give some more detail, I have the Thinkpad T480 with a USB-C dock. The laptop screen turns off when the lid is shut, but river will still let me move programs onto the laptop's integrated display. I just checked Gnome's behavior, and it acts as if the external display is the only monitor (which is desired).

22:34 <chipps_> n8_: kanshi probably solves your problem

22:36 <n8_> chipps_: thanks for letting me know

22:48 <n8_> chipps_: have you tried this with river? i don't think I'm able to disable the output. However, I'm not certain that I am invoking kanshi correctly or that I have the correct name for the display

22:51 <n8_> ah. just adding `kanshi &` to the top of my river init was sufficient. Launching kanshi after river had started was not. Thanks again