07:19 <gochujang> As someone coming from sway, I was wondering how stable river is

07:19 <gochujang> I'm running void, is the package availability good enough?

07:23 <ifreund> gochujang: stable in terms of breaking changes or crashiness?

07:23 <gochujang> the latter mostly

07:23 <ifreund> river should be less than or equally as crashy as sway

07:23 <gochujang> Ok nice, should be fine then

07:24 <ifreund> using a language that makes it hard to mess up basic things like pointer nullability gives river a slight edge here

07:24 <ifreund> as for void package availability, you know better than I do

07:25 <gochujang> Nice. And I understand a refactor is in the works for outsourcing some more stuff to the layout generator?

07:26 <ifreund> probably closer to a rewrite than a refactor, all window management policy will move to an external process, which will be more accurately called a window manager than a layout generator

07:27 <ifreund> I'll keep river's 0.3.x branch going as river-classic for the forseeable future though to ease the transition

07:27 <smoon23> FWIW, I changed to river full time something like eight month ago and have yet to experience a "crash".

07:27 <gochujang> ifreund: I see. That sounds good! How's it going? Doable?

07:28 <gochujang> smoon23: nice. Yeah I'm also not planning to do anything crazy, so should be fine then

07:28 <ifreund> gochujang: most of the work on the compositor side is done, see https://codeberg.org/river/river/pulls/1100

07:28 <ifreund> (when codeberg is back from the manitence break)

07:29 <ifreund> I'm currently building infrastructure for writing my personal window manager in janet

07:29 <ifreund> leon-p: has one going in scheme/zig as well

07:30 <ifreund> there's a long tail of minor missing features and whatnot to resolve before this work becomes ready for end-users though

07:31 <gochujang> and will rivertile be ported to the new api as well?

07:33 <ifreund> We will see if river's current window management get reimplemented as a window manager, I currently don't have a lot of motivation to work on that myself, but you never know

07:33 <ifreund> the point of maintaining river-classic is to give people who like the status quo the option to stick with it

07:34 <gochujang> ah, I didn't know there was a river-classic

07:34 <ifreund> there isn't yet, but there will be :D

07:34 <ifreund> though it will be pretty much feature frozen aside from wlroots and zig build requirements updates

07:35 <ifreund> unless someone forks it and takes over maintenece of course

07:35 <FireFly> I'm really liking the idea of river as a way to provide your own window manager without having to worry about all the other compositor bits

07:37 <ifreund> that's the idea, also being able to write the WM in a high level, garbage collected language without worrying about destroying latency is nice

07:37 <gochujang> how involved would writing a window manager be in this case? Are there any existing repos to look at?

07:38 <FireFly> ifreund: right, yeah

07:38 <ifreund> gochujang: here's one example https://gitlab.gwdg.de/leonhenrik.plickat/antares/-/blob/master/antares/antares.scm

07:38 <ifreund> though I don't know how complete it is currently

07:39 <ifreund> in general though it's a bit early to say exactly what level of abstraction makes sense for WM implementations

07:39 <gochujang> ok, so definitely not trivial, by my standards at least

07:39 <gochujang> yeah I see

07:40 <gochujang> completely understand though, first and foremost you need to enjoy what you're maintaining in open source

07:40 <gochujang> and it sounds interesting

07:41 <ifreund> I expect to see WMs similar to AwesomeWM where you can choose to use the defaults provided by the WM but also extend/tweak pretty much everythg

07:42 <gochujang> yeah that sounds cool

07:43 <gochujang> and river-classic would then be a wm that interfaces with the new river api right?

07:43 <FireFly> I think the suggestion was that river-classic would just be the continuation of the 3.x branch with the old structure(?)

07:44 <FireFly> but I guess someone could port/write a rivertile-y kinda WM using the new protocol

07:44 <gochujang> ah ok I see

07:45 <gochujang> Cool! Thanks for the info, sounds very interesting!

08:27 <ifreund> yep, FireFly is correct

08:27 <ifreund> maintaining the 0.3.x branch with just bugfixes and dependency updates is pretty low-effort

08:43 <gochujang> ah yeah

12:13 <leon-p> gochujang: writing a WM is a lot more trivial than my code makes is seem, because I chose to myke it hard on myself by trying to make it module and very configurable. Also because Lisp code has a tendency to seem more complex than it really is to those who aren't used to it.

12:13 <leon-p> If you stick to plain C or zig, you can have a usable WM in about 1k lines of code

12:53 <leon-p> ifreund: you've planted the seed of doing the Wayland bits in the scripting languages in my brain now. If I come up with a good dispatcher design and dig up an XML parser from somewhere, I think I can have live wayland support in scheme as well

12:54 <leon-p> not sure I'll go through with it, but a XML->AST parser and a macro to turn the AST into hooks and a dispatch-table would be my idea

12:54 <leon-p> you can even generate the AST for known protocols at comptime

13:29 <ifreund> leon-p: I'm pretty sure doing as much as possible of the glue code in janet will pay off, only tight loops like filling buffers for software rendering need to be in C/Zig

13:29 <ifreund> you could also just use janet when my thing is ready :P

13:30 <ifreund> by the way, this is all my scanner macro will need to output per interface: https://codeberg.org/ifreund/janet-wayland/src/commit/d0613f8604729b90915dd084b957a632b172ebca/src/wayland.janet#L5

13:31 <ifreund> I did these 3 by hand so I could test the design of the C bits before writing the macro

13:32 <ifreund> dynamically typed languages should only need one dispatcher, regardless of interface

13:32 <ifreund> the one I wrote for janet is here: https://codeberg.org/ifreund/janet-wayland/src/commit/d0613f8604729b90915dd084b957a632b172ebca/src/wayland-native.c#L447

13:33 <ifreund> anyhow, you could also just use janet after I finish janet-wayland :P

13:49 <ifreund> janet also allows doing the xml scanning part during "compile time" by the way, which is indeed my plan

13:50 <ifreund> (though "compile time" may be a misleading way of describing what janet does, it's not like zig comptime)

13:50 <ifreund> https://janet.guide/compilation-and-imagination/

15:00 <aimixsaka> Hello, i'm using river 0.3.7 on archlinux, and i have a tablet (wacom ctl672), and when using krita with wayland support(-git version), my cursor(tablet pen) disappeared when entering krita area. While in other applications(firefox, ghostty...), the cursor(tablet pen) rendered as is. And i tried running krita on sway 1.10.1, cursor is rendered as is. Is this a bug or do i need some extra configuration ?

15:04 <ifreund> aimixsaka: does krita actually support the tablet-v2 protocol? River doesn't do any pointer emulation for tablet tools yet so the application needs native tablet support

15:04 <ifreund> (all gtk and qt apps should have this though)

15:28 <aimixsaka> @ifreund It's a qt app. Haven't check if it supports tablet-v2 protocol. Maybe that's the point? As it was just able to run under native wayland last month by this mr: https://invent.kde.org/graphics/krita/-/merge_requests/2363, which said "not officially supported yet".

15:49 <leon-p> aimixsaka: ifreund: I doodled around in krita on river last year for a while. the cursor will disappear, but you should still be able to draw

15:56 <aimixsaka> yeah, that's true. Though not that frequent, but it feels a bit weird to move between mouse and pen :D

15:57 <ifreund> oh, is qt just bad at setting tablet tool cursors?

15:57 <ifreund> (or maybe krita)

23:07 <leon-p> I think last time I looked into it krita was still running via XWayland even

23:07 <leon-p> not sure what unholy incantations software on X needs to get tablet events