09:20 <c> /help

13:10 <leviathan> Hey guys, I've recently been diving into the implementation of InputMethodPopup. As a complete newbie, this includes getting to grips with Wayland, wlroots, and Zig, so I've been referencing the implementations in projects like Hyprland and Sway. I noticed that Hyprland seems to have customized a lot of event listeners, while River appears to only

13:15 <ifreund> leviathan: I think your message got cut off, for me it stops after "while river appears to only" (IRC has a character limit per message)

13:16 <ifreund> anyhow, I'd strongly recommend not looking at hyperland's code as a reference, all the hyperland code I've seen has been quite poor quality

13:17 <ifreund> reading sway's code is generally fine to help understand the problem space but an implementation in river should neven just be a straight port of code from some other compositor

13:17 <ifreund> if you have questions about wayland/zig/river's codebase feel free to ask them here

15:05 <ifreund> well I touched the transaction system again since I found a possible assertion failure

15:06 <ifreund> I've ended up making interactive resize of mpv behave even nicer I think

15:06 <ifreund> always a bit nervous of causing regressions when I touch this code though

15:07 <ifreund> you know, interactive resize of mpv is one thing river handles a lot better than sway. I'm kinda proud of that

15:15 <larstiq_> ifreund: cool!

15:19 <itshog> Hi! I just wanted to thank ifreund for adding tablet support to river, much appreciated!

15:20 <ifreund> itshog: no problem! Is it working well for you? I'm not a heavy tablet user myself and am not sure how annoying e.g. lack of pointer emulation is in practice

15:21 <itshog> I have only a little annoyance

15:21 <itshog> But maybe it's intended behaviour

15:22 <ifreund> you mean the lack of pointer emulation? I wouldn't say it's intended behavior long-term, more a limitation of the current implementation

15:24 <pkap> I am encountering a weird rendering thing. When I have Firefox and foot views next to each other and opening certain websites, slight horizontal lines are rendered in the foot view. next to the website.

15:24 <itshog> ifreund: When using Xournal++ and trying to select an item from one of the dropdown menus (like the one for selecting eraser or pen type) with the pen the menu disappears almost instantly

15:24 <pkap> Not problematic. It is very slightly. But I am curious if this is a bug in river, foot or is it my display?

15:25 <itshog> It works fine with mouse and touch input, but not with the pen

15:25 <leon-p> itshog: arguably that's a xournal++ bug for not making their menus usable with tablet input

15:25 <leon-p> I for one really like that the tablet tool is not bound to the cursor

15:25 <leon-p> *the primary cursor

15:26 <itshog> ifreund: It works properly in Sway, but maybe it's becasue of the pointer emulation

15:26 <ifreund> pkap: hmm, could you try to get a screen capture?

15:27 <leon-p> however what I am missing is restricting the tablet to a specific area on screen. tablets really aren't made for ultra-wide screens. Clients really should be able to ask the compositor to restrict the tablet to their canvas, but I don't think that's a thing yet

15:28 <leon-p> either way, I can finally use my tablet again for notes, thanks ifreund :]

15:28 <ifreund> leon-p: yeah, we only have support for mapping tablets to outputs not arbitrary rectangles currently

15:29 <ifreund> I wonder what UX GNOME has for tablet input region mapping, It would be nice to have something less manual than specifying a hardcoded rectangle of the compositor coordinate space in logical pixel coordinates

15:30 <ifreund> itshog: If you open an issue I'll take a look eventually, I probably won't block 0.3.0 on it though

15:31 <leon-p> I do remember reading something about clients requesting mapping the tablet just to their canvas, but I can't remember where. Also not sure how that would work with those expensive tablets that have a screen in them

15:33 <ifreund> pkap: in any case, that kind of graphical glitch sounds like a bug somewhere lower in the graphics stack than river. Maybe a wlroots scene graph bug or maybe a driver issue triggered by firefox doing something strange

15:34 <itshog> ifreund: Just tested, the same issue appears in LibreOffice so it's probably not a Xournal++ bug

15:34 <ifreund> you could try running river with WLR_SCENE_DISABLE_VISIBILITY=1 set to rule out a lot of the most complex wlroots scene graph code

15:34 <ifreund> itshog: excellent, please do open an issue telling me how to reproduce it in LibreOffice :)

15:35 <ifreund> Though it could still be a Qt bug I suppose (I think both of those programs use Qt?)

15:35 <itshog> They both use gtk3

15:36 <itshog> It's kind of strange because in LibreOffice some menus work properly and some don't

15:36 <itshog> Anyway I'll open an issue

15:37 <adamcstephens> i accidentally touched my laptop screen last night and realized touch works well. also realized i have a touch screen on this x13s i bought used 😄

15:38 <ifreund> that's pretty funny

15:38 <ifreund> touch doesn't have any pointer emulation either, but gtk stuff and the like support touch input quite well

15:39 <ifreund> anyhow, I'll probably be offline the rest of the day o7

15:41 <leon-p> o7

15:41 <pkap> ifreund: the rendering bug still occurs with with WLR_SCENE_DISABLE_VISIBILITY=1