11:50 <ifreund> leon-p: I've got a half-baked idea to solve the race for the "click on a button in a shell surface to change keyboard focus" example

11:51 <ifreund> the key insight is that we can let the window manager specify input events that may require a synchronous update to WM state with bindings

11:52 <ifreund> adding support for "passthrough" bindings that also pass the input event on to the target surface could be useful here

11:54 <ifreund> I suppose we would probably need a way to match the wl_pointer.button event to the river_pointer_binding_v1.pressed event, this could be done by adding a serial to the river_pointer_binding events

11:57 <ifreund> I'm pretty sure this would work, but am not quite sure it's worth the complexity

11:58 <ifreund> This might be one of those things where I just make sure it's possible to add to the protocol in a non-breaking way in the future if it turns out we do want it later

12:52 <leon-p> FWIW this same race also hits already existing setups where you can switch window focus via a button on a desktop widget. Like KDE, the labcwc XFCE integration, etc.. I am not sure how much of an issue it is in real-world usage.

12:54 <leon-p> IMO we could simply start by having a mapping between wl_seat and river_seat (via wl_seat's global name would make the most sense to me) and see what happens

12:56 <leon-p> we'll likely have quite the list of possible extensions later anyway, so I am definitely in favour of seeing what happens first

18:01 <Guest25f> is there any way to make touchscreen input affect only 1 monitor? right now, its treating both monitors as 1, and its quite annoying

18:02 <vyivel> Guest25f: riverctl input <name> map-to-output <output>

18:02 <vyivel> i think

19:06 <kaisan1> leon, ifreund, how is the work progressing on the branch? Are we near to a sneak preview?

19:11 <ifreund> kaisan1: not quite sure how you'd define a sneak preview, there's a lot that works already and a lot that still needs to be done

19:12 <leon-p> kaisan1: you can pull and compile the rwm branch if you like

19:12 <ifreund> and yeah, the code's available and all the development is public so feel free to have a look at the commit messages or build and play with it

19:12 <leon-p> but there aren't any realy window managers yet of course

19:12 <leon-p> s/realy/real/

19:14 <ifreund> realistically, the river part of the implementation isn't missing much that would prevent me from daily driving it

19:14 <ifreund> the only regression for my personal usage would be some input config stuff I could like without

19:15 <ifreund> I guess that's a sign that most of the work that prevents merging the rwm branch is on the window manager side

19:15 <leon-p> same, I am only missing pointer enter/leave and wiring up move/resize requests from xdg-toplevels. And input config of course, but short term I am fine hard-coding that in river

19:16 <ifreund> I would like to stop doing breaking changes to the protocol without versions bumps when the rwm branch is merged

19:16 <ifreund> leon-p: ah yes, those should be next on my TODO list

19:16 <leon-p> in that case, we shouldn't merge until we had a chance to test it in real-world usage for a while

19:17 <ifreund> indeed, and that means we need to make it possible to daily drive asap

19:17 <leon-p> though I am also looking forward to custom window decorations, because I want my motif window borders. I can live without them for a while still though

19:18 <ifreund> the custom window decorations will pretty much be next on my list after the (comparatively easy) pointer stuff you listed

19:18 <leon-p> nice!

19:18 <ifreund> I need to try out the approach described here: https://codeberg.org/river/river/pulls/1100#issuecomment-2573818

19:19 <ifreund> that's the last significant architectural change I forsee though

19:20 <leon-p> if it wasn't for the title bar, arguably the WM could also just give river a wl_buffer once which river stretches around the window without the WM needing to re-render

19:21 <leon-p> that is how I'll do decorations in my WM anyway, a single buffer and 8 surfaces with viewporter

19:22 <leon-p> but I have other things on my todo list until then. I've been putting off text and image rendering for a while now :)

19:24 <ifreund> leon-p: thes architectural change is necessary for e.g. riverctl resize horizontal 42 as well

22:41 <Guest58> helo :D

22:43 <leon-p> hello

23:06 <Guest58> i am very new to wm-s and im trying to switch between fullscreened windows on the same tag is that possible? only change i made from the example config is adding a rule so that all new windows are fullscreen. any help would be appriciated :-)

23:29 <leon-p> that is not currently possible, sorry

23:40 <Guest58> oh, ok thanks for the info (y) it should work if they are on diffrent tags right? so i would just switch the viewed tag. I am trying to get it working by having new windows open in a new tag but i am completely clueless as of how to do that (new tag as in all new windows would have their own tag so i can get something simillar to what i first

23:40 <Guest58> asked)

23:42 <leon-p> doing that programmatically isn't possible right now unfortunately

23:42 <leon-p> however there is an alternative

23:42 <leon-p> you could use a layout generator which makes all windows use the entire output and also set the border-size to 0

23:43 <leon-p> that is effectively simulating fullscreen, but you'll be able to switch between windows

23:49 <Guest58> Thanks for the help, just realised i was on your site earlier reading a guide for this. Sorry to pester you but could you tell me the exact commands i need to put in my config >.<

23:52 <leon-p> it starts with looking at the wiki and looking up a layout generator that fits

23:53 <leon-p> then launch that instead of rivertile in your config and set the layout namespace accordingly