00:13 <leon-p> ecocode_: not yet

00:16 <ecocode_> hmmm

00:16 <ecocode_> well, I think I can live with this for now

07:57 <pete11> Can I somehow make the river tags in Waybar clickable. So that I can switch tags by click.

11:48 <bfiedler> Are triple-slash comments semantically different from double-slash comments? I see them used in the river code quite a bit

11:48 <leon-p> bfiedler: tripple-slash comments are doc-comments

11:49 <leon-p> so yes, they are different. And zig won't allow them in places where doc comments don't make sense.

11:49 <bfiedler> leon-p: thanks!

12:01 <bfiedler> Should a theoretical set-position x y be relative to the current output or absolute?

12:01 <leon-p> bfiedler: relative to the current output.

12:02 <leon-p> and also it must follow current convention by never moving a window outside an output

12:09 <bfiedler> leon-p: makes sense :)

12:34 <bfiedler> riverctl resize <direction> moves the output by effective_delta / 2 to make it a bit more natual

12:35 <bfiedler> Should a riverctl set-geometry command do that as well?

12:35 <leon-p> bfiedler: Good question. I think it should not.

12:35 <leon-p> The two commands have different use cases

12:36 <bfiedler> Me neither

12:36 <bfiedler> It makes it _much_ easier to use in conjunction with set-position

12:37 <leon-p> the resize by delta command is meant for interactive use. Moving the view so it appears like its center remains stationary is just good UX. However the set-geometry and set-position commands are meant for precise control and this feature would just be annoying here.

12:49 <bfiedler> is it guaranteed for a view that x_pos < effective_output_width - border_width >= 0?

12:49 <bfiedler> s/>= 0//g

12:53 <leon-p> bfiedler: no. Layout generators currently have no restrictions on where to place windows and therefore can position them outside the bounds of the output.

12:59 <bfiedler> what should happen when setting the geometry of an off-screen view?

12:59 <bfiedler> should we pull the view into focus

13:02 <leon-p> bfiedler: since it is set to floating, it should be pulled into the output bounds

13:02 <leon-p> going even further, I think these restrictions should apply to layout generators as well

13:04 <bfiedler> leon-p: that or let it be a protocol error

13:05 <leon-p> bfiedler: sounds reasonable. I'll open an issue about that

13:15 <bfiedler> The case that currently bugs me is the following: calling 'set-geometry w h' on a window that is placed at something like 2px from the lower-right corner. what should happen here?

13:16 <bfiedler> I want to move the position of the window as little as possible, however I have to move it since otherwise the box would be too small

13:19 <leon-p> I see two possible things to do: 1) keep the position and resize the view to min(possible_size, desired_size), or 2) move the view

13:22 <leon-p> and perhaps 3) print an error and abort the operation

13:22 <leon-p> which of these makes more sense depends on the use case I think

13:23 <bfiedler> I prefer 1), but this leads to cases where we might place parts of views outside of the output bounds

13:24 <bfiedler> 3) sounds good in this case

13:25 <leon-p> well, any part of the view being outside the output bounds is a complete no-go.

13:27 <leon-p> tbh I think there should be some unified View.moveResize() function that takes care of all the constraints, so we don't have to worry about it anymore in the future

13:30 <bfiedler> leon-p: +1 for moveResize, that's what I'm basically working on anyway ATM

13:31 <bfiedler> but then we have to decide what get's preference: the position or the geometry

13:31 <novakane> does view could be place between two outputs? since I don't have multiple monitors I don't know what's the current behavior

13:32 <bfiedler> I think it shouldn't be possible at the moment

13:35 <bfiedler> Is 2 * border_height < min(output.width, output.height) checked?

13:35 <bfiedler> that looks like it makes sense (maybe only with <= but nonetheless)

13:36 <leon-p> bfiedler: a view is constrained to an output even if there is another output next to it.

13:37 <leon-p> (not handling this case is one of the technological reasons for this restriction, btw.)

13:38 <leon-p> bfiedler: can't remember what's checked where, sorry

14:28 <bfiedler> resizing a window is actually resize-move

14:28 <leon-p> bfiedler: depends on the direction, but yes

14:29 <bfiedler> hmm

14:29 <bfiedler> I'm thinking of ways to unify the resizing handling, but it is not clear how to do it

14:30 <leon-p> yeah, it's a bit annoying. Be happy this is Wayland. On X it's not even possible to do that in a reliably frame-perfect way.

14:30 <bfiedler> riverctl resize would like a resize which can temporarily go outside of the view borders since it fixes itself by "centering" the move afterwards

14:30 <bfiedler> however set-geometry would like a resize which automatically clamps at the output bounds

14:31 <leon-p> bfiedler: it also allows to have a size bigger than the output dimensions and fixes itself afterwards AFAIK

14:31 <bfiedler> yeah if size > output_width then it gets clamped by the available width

14:34 <leon-p> what if you approch the problem from the POV of positioning two points on the output, the upper-left and lower-right corner, keeping both inside the bounds? Then both geometry or position overrule the other based on position. Perhaps that is abit more intuitive

14:34 <leon-p> bfiedler: ^

14:36 <leon-p> I used that method in my pointer resize PR and it works great there.

15:05 <bfiedler> sure, but the question is still: what if moveResize cannot handle it's arguments? should x/y positioning be retained and width/height truncated or should width/height be retained and x/y changed?

15:10 <leon-p> bfiedler: that's the point. My idea is to covert x,y,w,h into two sets of x,y and treat them individually.

15:11 <leon-p> whether dimensions or position is corrected then depends on which of the points moves outside of the bounds

15:13 <leon-p> that will ensure that the size of the view is exactly the size of the visible part of the view if it /could/ be moved outside the bounds, with the expection of the minimum view size

15:22 <bfiedler> what if minimum size comes into play?

15:23 <bfiedler> i.e. resizeMove (999, 999, 100, 100) on a 1000x1000 display

15:26 <leon-p> I think For min size the best way is to first calculate the new size and position, then if necessary correct the size and then if necessary correct position. Min size will usually never be encountered, so it's fine if it introduces a slight inconsistency IMO

15:27 <leon-p> same for the xdg toplevel min size

15:29 <leon-p> Or to explain it in simple words: "if you push the window into a border, the border eats that part of the window, until the window can get no smaller, then it bounces back"

15:30 <bfiedler> agree

15:30 <bfiedler> but then, this is unintuitive for move right

15:30 <leon-p> how so?

15:30 <bfiedler> It is nicer to have the window stop at the right border if I want to snap it right

15:31 <bfiedler> ah but then I could just have used snap

15:31 <leon-p> ah, that is what you mean. My proposal actually only applies to move-resize ops., not to pure move ops.

15:31 <bfiedler> ah, my bad

15:31 <leon-p> fore pure movement I don't think windows should be resized at all

15:31 <leon-p> should have pointed that out prbably

15:32 <bfiedler> makes sense

15:32 <leon-p> also pointer resize/move still needs to be special-cased, as they are right now.

15:32 <leon-p> I think at least.

15:33 <bfiedler> what about set-position vs move

15:33 <leon-p> good question. And TBH I don't have an answer.

15:33 <bfiedler> move should not change the window size, but I feel like set-position should have the border-eats-up-extra-window behaviour

15:33 <leon-p> I can get onboard with that

15:34 <bfiedler> I feel like that is the best tradeoff between precision and intuition

15:34 <leon-p> you know, we could always wait until monday and defer the decission making to ifreund :D

15:34 <leon-p> anyway, I think this requires more discussion

15:35 <bfiedler> +1

15:35 <bfiedler> I'll let it rest until Mo then :)

15:35 <leon-p> especially with regards to usecase. Something that is used interactively should behave differently than something that is used through scripts / a wayland client

16:07 <bfiedler> Alright, I've added a comment to my (now WIP) PR: https://github.com/ifreund/river/pull/430

22:14 <swl> How can I set my keyboard layout using riverctl? In sway I could do 'input '*' xkb_variant colemak' but I don't see any reference to xkb or any keyboard related command in riverctl(1)

22:20 <inclement> I think you can use the env vars $XKB_DEFAULT_LAYOUT etc., I think the river man page explains more

22:57 <ecocode_> @swl you need to modify ```/usr/share/wayland-sessions/river.desktop```

22:58 <ecocode_> hmm, he already left :)