00:00 <leon-p> can't recommend doing it python; thanks to the python wayland bindings being annoying to set-up, it's less trouble and easier doing it in C

00:01 <NickH> I like using python for things like this since it makes it trivial to package/distribute on pypi.

00:03 <NickH> But yes, having to run "python3 -m pywayland.scanner -i /usr/share/wayland/wayland.xml /usr/share/river-protocols/river-control-unstable-v1.xml /usr/share/river-protocols/river-status-unstable-v1.xml" is a bit annoying.

00:03 <leon-p> I personally prefer C, since I find C libs to be less hassle than python libs, but that's probably personal taste

00:04 <leon-p> python is nice though for write-once-run-once programs

01:12 <mon_aaraj> leon-p: What about something like eww?

01:12 <mon_aaraj> i dislike both python and c

01:16 <leon-p> mon_aaraj: no idea how eww works

01:25 <NickH> rust?

06:47 <talismanick> Is there a way to capture and transform keyboard input?

06:48 <talismanick> in the way that StumpWM and EXWM allow setting Emacs-like keys for Firefox by intercepting keypresses

12:07 <leon-p> talismanick: not in an unhacky way, however maybe a modified keymap might satisfy your needs: https://leon_plickat.srht.site/blog/xkb-custom-layout/article.html

17:49 <tleydxdy[m]> hmm, when river freezes the ability to switch vt is also lost, I wonder if there's some way to avoid this

23:00 <xaltsc> Hey, is it possible somehow to focus-view to the left/right/etc ?

23:01 <xaltsc> I guess what I'm really asking is how to get river to mimic bspwm

23:15 <NickH> xaltsc: Like this: https://github.com/riverwm/river/pull/473 ?

23:20 <xaltsc> NickH: at the very least, yes

23:20 <xaltsc> But would it be possible, ultimately, to implement a bsp layout for river ?

23:21 <NickH> That PR is a bit old now and seems to have conflicts but you could probably rebase and build it.

23:21 <NickH> Window managment in river is planned to be overhauled soon and shipped out to separate apps.

23:22 <NickH> So yes, but I think not in the very short term.

23:23 <xaltsc> OK, thanks, River made me move to Wayland (from Bspwm and before that Xmonad) with the slogan "inspired by Bspwm" so I was a bit disapointed :D

23:23 <NickH> Where did you see "inspired by Bspwm"?

23:25 <waleee> I think it used to be in the README a while back, "inspired by dwm and bspwm" (paraphrased)

23:25 <xaltsc> The arch wiki, and I'm not even on arch

23:25 <xaltsc> https://wiki.archlinux.org/title/Wayland

23:26 <waleee> the bspwm part was in reference to structure of the wm afaik (ie bspc for control etc)

23:28 <xaltsc> Yep, that's the reason why I'm not giving up hope yet

23:29 <xaltsc> But I don't understand why no one has made a bsp compositor yet.... I've been waiting for years now.

23:29 <NickH> Ahh, "git log -Sbspwm -- README.md" tells me that is was once reference.

23:30 <NickH> LOl, why hasn't somebody written the software that I want yet?

23:32 <xaltsc> Maybe it's because I'm a mathematician, but using binary trees feels just like the most natural take on tiling there is

23:34 <leon-p> xaltsc: I'd rather not have window management complex enough so you could define an algebra or topology or vector space over it.

23:35 <xaltsc> leon-p: even a topology ? What's more natural than that ?

23:37 <leon-p> spatial memory. humans are tremendously good at intuitively keeping track of where in space we put things, and a plain list seems to complement that well.

23:38 <xaltsc> leon-p: It precisely doesn't give you a nice notion of relative positions between windows

23:38 <leon-p> that what the layout's for. It needs to be simple enough so that you can easiely guess how things will turn out if one or multiple windows appear or disappear.

23:40 <xaltsc> tbh, with Xmonad, what frustated the most was having to remember how each layout fit for a particular purpose worked. I never had this problem with bsp since there are only two windows, recursively.

23:40 <leon-p> unless of course you mean relative position as a norm of the backing data structure :P

23:42 <leon-p> anyway, I think it's a philosophical difference. River is best suited to the use case of not having specialised layout IMO. Just one you use for everything. Which in turn works best if you have the kind of workflow where you open and close many windows very often.

23:43 <waleee> I was thinking on going zilch datastructure in slow-motion project (translating hikari from c to zig)

23:45 <leon-p> there will always be a data structure. and there will always be a way it get's presented on screen. You just have to decide which suites you more: Choosing a datastructure and designing the UI based on that, or first come up with a good UI and then create a backing data structure as an after thought.

23:48 <waleee> yeah, it was mostly tongue in cheek based on the "lack" of a ui datastructure

23:56 <leon-p> well, the next wlroots release will be a pretty good time to hack on a compositor, since the scene graph API will make things a bit easier. might even revive some of my experiements