00:21 <kindablue> hello is there any way to get dimensions and coordinates of a view in river?

00:21 <kindablue> I can't seem to figure out how to take a screenshot of the active view

07:59 <ifreund> kindablue: no, not currently

11:16 <dnkl> ifreund: I think perhaps me being unused to zig was an advantage... I don't yet have the ability to skim through code quickly, and had to go fairly slow

11:16 <dnkl> hopefully there'll be some progress on IME now :D

13:31 <novakane> dnkl: well obviously there more chance that the IME PR progress now that river doesn't crash :P

13:32 <novakane> I think overall the implementation without keyboard grab is mostly done, at least for me I don't saw too much wrong thing

13:33 <novakane> maybe ifreund gonna disagree with this statement though^^

14:37 <ifreund> what you have so far looked pretty good to me, just gotta finish it up and fix the bugs :)

14:46 <novakane> ifreund: btw could you point me in the right direction on how to fix `@intCast(u32, input_method.current.preedit.cursor_begin)` directly from zig-wayland?

14:46 <novakane> afaik this is the only remaining problem of the current implementation

14:48 <ifreund> you know where to access the function in zig wayland right?

14:49 <ifreund> the wl.Resource you need is in the wlr.TextMethodV3 sturct

14:50 <ifreund> s/Method/Input/

14:50 <ifreund> could also replace that wl.Resource with the proper wrapper type in the bindings for more type safety

14:50 <ifreund> (you'll currently need to @ptrCast() it to make the call)

14:56 <novakane> not really, I'm not sure how to access zig-wayland function in river

14:56 <novakane> is that something I need to change in river or in zig-wayland or wlroots

14:58 <ifreund> you need to edit river's build.zig to generate the marshalling code for text input v3

14:59 <ifreund> then you can do @import("wayland").server.zwp.TextInputV3.sendPreeditString()

14:59 <ifreund> the first argument will be a *zwp.TextInputV3, this is the same pointer as the *wl.Resource field of the wlroots struct though

14:59 <ifreund> does that clear things up?

15:03 <novakane> I guess there is no example on how to generate this in build.zig yet?

15:17 <ifreund> novakane: https://github.com/riverwm/river/blob/0cbe2b9fc34f253ac86115c469eef46ad0387ecb/build.zig#L75

15:18 <novakane> oh duh I overthinked this

15:22 <ifreund> :d

15:22 <ifreund> s/d/D/

15:38 <novakane> ifreund: does this looks like I understand correctly https://paste.sr.ht/~novakane/59261a17c3170b05fbb401cb00b82f19c494f008

15:39 <novakane> it works at least lol

15:40 <ifreund> novakane: yep, though I'd put the comment at the call site and get rid of the `const sendPreeditString = ...`

15:43 <novakane> no problem, well it was way more complicated and hard in my head before your explanation, thanks :D

16:02 <novakane> I can't really take inspiration in sway code for the keyboard_grab implementation, it's way too different from river one :(

16:06 <ifreund> pretty sure I looked at sway's input code, went "that looks complicated" and wrote my own

16:11 <novakane> haha I get you, for now I still have no idea on how to integrate this in Keyboard.zig though

17:42 <novakane> oh so earlier I forced push the fix for IME without using git add before \o/

18:36 <novakane> I'm playing a bit with stacktile, and it's so easy to changes the default layout of river, with runit service, I can have rivercarro and stacktile running and just use `riverctl default-layout <foo>`

18:36 <novakane> that was really a great design

20:06 <snakedye> You can also change the input mode to quickly remap keys :)

20:08 <novakane> oh that's not a bad idea! You do this?

20:40 <snakedye> novakane: I do it when I test my layout generator

20:46 <novakane> snakedye: I never thought of this but maybe I'll do this if I'm not to lazy :P

20:47 <novakane> I need to try kile someday too, to be on point on all layout generator :D

20:50 <snakedye> \o/

20:52 <novakane> snakedye: so how do you build the man page for kile? I'm not really an expert with cargo

20:53 <snakedye> If you have scdoc it'll build it automatically

20:54 <novakane> allright so where then? I don't see anything in target/

20:55 <snakedye> It's when you build kile

20:55 <snakedye> The man page should be in doc/ like river

20:57 <novakane> ah yeeh I see it, wasn't looking in the right place, thanks

21:20 <elshize> hey yall, I'm unfortunate enough to have a hybrid nvidia card on my work laptop; I'm experimenting with proprietary and open source drivers; river kinda almost works fine with proprietary, but some apps have issues. trying nouveau now, and having this issue: I have an external monitor that is detected by nouveau drm, and I start apps there and move them between monitors, but the external monitor is

21:20 <elshize> all blank... any idea if this can be fixed? got logs here: https://0x0.st/-RVD.log

21:21 <elshize> I desperately don't want to go back to x11 :(

21:27 <elshize> btw, the same happens on sway, though I actually get a cursor on the other screen.

21:28 <elshize> but it works on gnome/wayland

22:46 <ifreund> elshize: one option would be to only use the integrated graphics card to run the compositor, you can select the card with WLR_DRM_DEVICES

22:47 <ifreund> that'd be assuming that you have a nvidia dedicated card + an intel CPU with integrated graphics, which is pretty common I believe

22:49 <ifreund> ah, from that log it seems that you have one display running off the integrated intel gpu and one running off the nvidia gpu with noveau drivers

22:49 <elshize> ifreund: yeah, I think (not sure) that the external display only works via nvidia card

22:50 <ifreund> you might not be able to physically plug the external display into the integrated gpu yeyah

22:50 <elshize> hecking sad

22:51 <elshize> it's weird that I got river running on nvidia proprietary drivers

22:52 <elshize> but then e.g. qutebrowser no longer works

22:52 <ifreund> they recently added GBM support after however many years of trying to push EGLStreams

22:52 <elshize> and tearing is bad

22:52 <ifreund> maybe they'll fix whatever outstanding bugs their GBM code has in the future, I couldn't say and it's closed source so... yeah

22:53 <ifreund> so their properitary driver now in theory supports everything wlroots/sway/river need, but obviously still has issues

22:54 <elshize> fun fact: when I try to start sway under proprietary drivers, it prints out in red that they're not supported

22:54 <elshize> and then says that you can bypass it with an arg but "don't report bugs", which is reasonable

22:55 <elshize> but the option is called something like --my-next-card-will-not-be-nvidia (or something similar, don't remember exactly)

22:56 <ifreund> yep, we could do that for river too but I don't really want to maintain the code unless we need it to filter out such bug reports

22:56 <ifreund> which we haven't gotten any of yet :D

23:04 <elshize> it just makes me sad I can't just use intel card :( I have no use for that nvidia