04:19 <ahmadraniri1994[> hello, is it possible to make "scrollable tiling" layout on river? like cardboardwm, thanks.

06:16 <novakane> ahmadraniri1994[: not with rivertile, and I don't think it would be possible to make with an other layout generator too

07:31 <NickH> Think it would be a very simple generator to implement that.

07:32 <NickH> I've been meaning to have a go a writing a generator.

07:33 <NickH> Unless I misunderstand the desired behaviour.

07:52 <nor[m]> On Cardboard you scroll windows sideways out of the output, similar to the Gnome shell extension paperwm. https://github.com/paperwm/PaperWM#scrollable-window-tiling seems very different from river, where the output edge is also the border for moving windows.

07:54 <NickH> I think implementation would be very similar to the standard rivertile.

07:55 <NickH> The big differnce is that only windows in the main area are rendered.

07:55 <NickH> then you just shift the location of each window in the stack to scroll.

07:56 <NickH> I'm going to have a try at writing it.

07:58 <NickH> Or are layout generators not able to change the position of the view within the list of views?

08:02 <nor[m]> No idea, I'm new to both river and coding :D But what you described sounds interesting.

08:02 <NickH> Ohh, ok.

08:10 <novakane> it sounds like a monocle layout, view taking the full usable area, you can't have view on the left or right outside the ouput and slide them

08:34 <NickH> The non-visible views aren't really on the left and/or right, but the way that they come into view sort of implies that they were.

09:02 <novakane> yeah but that implies animation wich it's not something you could do with the layout protocol

09:04 <NickH> No animation that's for sure.

09:05 <NickH> The implication that they are moving comes from the fact that the other views on the display shifted position.

09:06 <NickH> For example you have [A][B][C] shown on your display, then you hit the scroll left binding and you suddenly have [B][C][D] showing.

09:11 <novakane> ah yeah then it should be possible,tough I think you still need to set a position for all views so like your A view will still be there behind

09:12 <NickH> Hmm... so views an just not be rendered?

09:12 <NickH> s/an/can't

09:14 <NickH> I'm not familiar with monocle view. Is there one implemented for river?

09:16 <NickH> s/view/layout

09:16 <ifreund> Shinyzenith[m]: that suggests you added a listener for the new output event but didn't initialize it

09:16 <NickH> LOL it seems novakane has implemented one!

09:18 <ifreund> I don't think river supports the "scrollable tiling" use case well yet. The layout protocol can probably approximate the same logical window management but it won't integrate with trackpad gestures or the mouse scroll wheel.

09:18 <novakane> NickH: yeah the view take the full output, the others are behind

09:18 <ifreund> Currently the path of least resistence would be to use/contribute to cardboardwm

10:04 <ahmadraniri1994[> thanks for the respond, the closest I get is newm, but latest newm is unusable on my machine.

10:05 <ahmadraniri1994[> <novakane> "it sounds like a monocle layout,..." <- no, it's not always full monocle.

11:20 <nor[m]> It has not bothered me to much so far, but thought I might ask. When I open ungoogled-chromium, it is invisible. I can focus it (indicated by all other views being unfocused), but I can't see it before I resize it. (This does not happen with rivertile, which I don't use). It is not terrible, I know what to do after launching it to make it accessible, but a little bit annoying. Any tips on how to change this?

11:22 <ifreund> nor[m]: hmm, are you not using any layout generator?

11:23 <ifreund> and is it running through xwayland or not?

11:25 <nor[m]> No, i can't friends with dynamic tiling. However tags are more important to me than (manual) tiling, which let me choose river over Sway. How do I check for Xwayland?

11:26 <nor[m]> *become friends

11:27 <leon-p> there are a few conditions that can lead to windows spawning outside the constraints of the output. Try moving it via keybinds, it should be snapped back into the visible area if this is the case

11:30 <leon-p> RE scrollable tiling: I would really love to try that out some time, but I don't think river will support that. AFAICS it won't work well with the scene graph API when you have multiple outputs side by side, because the scene graph would just put windows that are scrolled out of one output right on the one beside it (if I understand how it functions correctly).

11:31 <nor[m]> It does not seem to be outside of the output just invisible (size 0?). Moving does not make it visible, but resizing does, both with keyboard and mouse.

11:31 <leon-p> ah, that sounds like a client bug

11:34 <nor[m]> Also after resizing, it does not show up in the middle (like anything else), but in the top left, with just the window border (I set it to 2 pixels) outside of the output.

11:36 <leon-p> we should probably add position and dimensions to the debug logs, at some point.

11:38 <nor[m]> Seems to be on XWayland, btw. but not all xwayland apps do this.

11:44 <Shinyzenith[m]> <ifreund> "Shinyzenith: that suggests you..." <- I was using the following notation taken from tinywl source code:

11:44 <Shinyzenith[m]> ` new_output: wl.Listener(*wlr.Output) = wl.Listener(*wlr.Output).init(newOutput),`

11:44 <Shinyzenith[m]> Looked at river source, removed everything after the = and ran setNotify on it which fixed it

11:44 <Shinyzenith[m]> so I did initialize it

11:51 <ifreund> Shinyzenith[m]: in zig default values of struct fields are only ever set when using `foo = .{}` syntax to initialize the struct

11:54 <ifreund> I have no idea how cardboard or paperwm handle multiple outputs, but I'd be surprised if the scene graph wasn't flexible enough to make things work there.

11:55 <ifreund> if it isn't flexible enough for that then a wlroots patch improving things would be in order IMO

11:56 <leon-p> you'd need a per-output scene graph instead of a global one. Then it would work

11:57 <leon-p> no idea how cardboard does multiple outputs either, but papwerwm simply does not at all, at least when I tried it ~2 years ago, likely doe to limitations in gnome shell

12:14 <Shinyzenith[m]> <ifreund> "Shinyzenith: in zig default..." <- Oh yes I forgot that, thank you issac.

16:16 <uncomfyhalomacr4> Shinyzenith:

16:43 <Shinyzenith[m]> ?

18:30 <ghostbuster> can someone give me an example of how they use tagging in their workflow? i feel like i've been using river for a few months but i still use it as if it's sway/i3 and don't take advantage of the dynamic feature

18:37 <leon-p> ghostbuster: there is one in the github wiki

18:37 <leon-p> I myself also don't use the special feature set of tags very often either though

18:53 <tiosgz`> ifreund: (re scene & outputs) ha, finally a better use case for {,not} rendering {only,} a particular subtree of the scene than my overlapping outputs example :D

22:01 <lordmzte> hey! does river work on nvidia? because it doesnt seem to for me :P neither from a tty nor in X

22:03 <lordmzte> on tty its telling me it found 0 GPUs, and on X im getting `Failed to query DRI3 DRM FD`. im using the proprietary nvidia drivers.

22:30 <leon-p> lordmzte: proprietary drivers are not supported. There have been reports of river working when they are used, but the drivers are *slightly* wonky

22:30 <leon-p> in general the recommendation is to either a) use nouveau, or b) use built-in graphics

22:33 <lordmzte> alright, thats unfortunate. doesnt seem like theres a good way to switch between nouveau and nvidia without uninstalling one of them either :/