15:43 <fleischie> I have a question regarding zig-wayland, I hope that's ok: Does someone happen to know whether zig-wayland supports setting user data via wl_proxy? (Not just getting it, which I found.)

16:24 <tiosgz> fleischie: seems to be on purpose, see 67e2c11ff3f2c67e4fc051b0564632676368c7d3

16:33 <fleischie> Ah ok. Thanks tiosgz ! :)

17:20 <JustineSmithies> I've a question about PR #852. I see there is the tag rule which I presume means you'd be able to have say foot assigned to tag 2 for instance when it was opened yes ?

17:22 <JustineSmithies> If i've understood that PR correctly then what about multimonitor setups would it not need an optional output parameter too ?

17:22 <JustineSmithies> I think this question should be directed at the author though leon-p

17:23 <leon-p> I would keep those separate: one rule for output, one for tag

17:23 <leon-p> right now the rule ignores outputs completely and the window appears on the currently focused one as usual

17:24 <JustineSmithies> Yes that's how I thought it would work as per the code now.

17:25 <JustineSmithies> Another whishlist rule would be to have a rule that if the app-id is matched then run a script or command using spawn.

17:26 <leon-p> hooks are on my personal list as well, however I fear they'd be abused for scripting that should rather be done through wayland

17:27 <JustineSmithies> I'd use for simple things like on mpv opening then move the window to x,y location and resize as I usually open mpv small in the bottom right of the active monitor until i decide to fullscreen it.

17:27 <leon-p> either way, I'd need some feedback on that PR before I do invest too much time into rules

17:28 <leon-p> JustineSmithies: the problem with that kind of scripting is that is violates Wayland "every frame is perfect" rule. Because the window opens and gets mapped, then the script runs and moves it, there exists at least one frame with the window in the wrong position

17:29 <leon-p> to avoid that we could have either a position rule, or some sort of filter protocol for an external client to control certain window features before map

17:33 <JustineSmithies> A position rule would be perfect as long as you could set location x & y and size x & y and the matched app-id window would always have those attributes on first opening ??

17:33 <leon-p> certainly possible

17:34 <leon-p> I'd ask ifreund for a definite yes or no, but that is how I would do it right now.

17:37 <leon-p> with the sole exception of the riverctl list-rules command, it's acttually rather easy to add new rules

17:37 <leon-p> especially now that I made RuleList have a variable child-type

17:40 <tiosgz> leon-p: i think the order _action_ <filter> _argument_ is rather unintuitive; i wonder if it could be made to accept <filter> _action_ _argument_ as well (both variants in order not to be a breaking change)

17:40 <leon-p> that's how the argument parser works, didn't feel like changing it 🤷

17:41 <JustineSmithies> Cool and thanks leon-p for your help and advice it's appreciated. I'm away to go build a void package of river using your latest commit from your fork to test that PR out and I'll let you know how it goes.

17:41 <tiosgz> ahh ok

17:41 <leon-p> testing is always appreciated

17:57 <JustineSmithies> Hmm the build failed ??

17:57 <JustineSmithies> /builddir/river-testing-0.2.4.20230625/build.zig:7:35: error: unable to load '/builddir/river-testing-0.2.4.20230625/deps/zig-wayland/build.zig': FileNotFound

17:57 <JustineSmithies> const ScanProtocolsStep = @import("deps/zig-wayland/build.zig").ScanProtocolsStep;

17:58 <tiosgz> did you git submodule update --init?

17:59 <JustineSmithies> No I modified a river template and used as the file https://github.com/Leon-Plickat/river/archive/refs/heads/tag-filter.zip

18:00 <JustineSmithies> I maybe will have to just manually build from source.

18:01 <JustineSmithies> Sorry forgot to say using void.

18:02 <tiosgz> phaps that's why i cannot help you... fwiw just cloning the repo, following the build steps without install and running zig-out/bin/river from there won't mess with your system

18:03 <JustineSmithies> tiosgz: Thanks

18:32 <JustineSmithies> Haha got it built finally on my test machine now to test PR #852 ;)

18:37 <JustineSmithies> leon-p: So for a test rule have I read the doc right ? Would riverctl rule-add tag --app-id "foot" 2 be correct ?

18:37 <leon-p> yes

18:37 <leon-p> just with `-app-id` and not `--app-id`

18:38 <JustineSmithies> Yes sorry that's what I have and if I open foot it should be assigned to tag number 2 yes ?

18:39 <leon-p> not to tag two, but the tag set that equals 2 in binary

18:42 <JustineSmithies> leon-p: PS typo in the doc line 276 it says Requieres and should be Requires

19:05 <JustineSmithies> leon-p: The tag rule works as expected no issues found yet.

19:10 <JustineSmithies> Is there no riverctl rule-del tag ???

19:11 <leon-p> there should be

19:13 <JustineSmithies> What format ? riverctl rule-del "foot 2 ??

19:13 <JustineSmithies> riverctl rule-del tag is accepted but not the above too many arguments

19:17 <JustineSmithies> 722884

19:18 <JustineSmithies> lol

19:19 <leon-p> ah yes, you don't need to put the argument into the command when deleting the rule

19:20 <leon-p> there can't be two rules with the exact same matching criterea, so no need to specify the tag

19:21 <JustineSmithies> Still if i enter riverctl rule-del tag "foot" I get error: too many arguments

19:21 <JustineSmithies> Yet riverctl list-rules tag shows the rule

19:23 <leon-p> maybe I accidentally changed the argument count in the rule-del command as well

19:24 <JustineSmithies> It wouldn't be fun if things worked first time ;)

19:32 <JustineSmithies> Oh nice and now the power is out here not long now until my UPS dies. Hope they get it sorted ASAP.

19:35 <leon-p> hey, still better than all lights in your flat mildly flickering for the last year or so