12:06 <MrBrownFR> Hello ! I've been watching the river repo for a bit now, and it says a major refactoring is coming for 0.4, does anyone has an idea for a potential release date ? The layout generator stuff is really cool but I'm afraid if I invest my time into writing one now it will become useless for the next release...

12:10 <tiosgz> MrBrownFR: i wouldn't expect it to land any sooner than a year from now or later, especially since this is a major change

12:11 <tiosgz> the plan so far is to make a compatibility layer so that layout generators have time to migrate to full window managers (dunno if that will be temporary or permanent)

12:12 <MrBrownFR> tiosgz thank you ! I'll see what I can achieve with the current API then :)

12:13 <tiosgz> good luck!

12:13 <MrBrownFR> thanks !

13:06 <ramblurr> hi folks o/

13:06 <ramblurr> i've been on an wayland wm/compositor finding mission and ran across river..

13:07 <ramblurr> I was wondering what's the state of the idea that isaac describes in "Balancing Flexibility and Complexity in River" to move more windo management features into a separate process.. how's that going?

13:10 <ifreund> ramblurr: working on it: https://codeberg.org/river/river/pulls/1100

13:11 <ifreund> the protocol design seems pretty good so far, lots of implementation work still to be done though

13:13 <ramblurr> wow, great! i find the idea of a high-level window management wayland protocol very interesting!

13:15 <ifreund> Yeah, I think it has a lot of potential

13:17 <ramblurr> i'd like to explore some window management / desktop environment ideas in clojure and was looking for a wayland compositor that is at a high enough level. river jumped out because of its out of process layout generator

13:18 <ramblurr> smithay and louvre are wlroots alternatives but they are both still rather low level for what i wanted to play with

13:19 <ifreund> cool, yeah I'd say have a look at the draft protocol and see what you think

13:19 <ramblurr> fwiw i've managed to port the example layout.c in contrib/ to clojure with jdk 22's new FFI features

13:19 <ifreund> if you notice anything that seems to limiting for your vision feel free to leave a comment on the PR

13:20 <ifreund> cool, I know that leon-p is working on a higher level C ABI library to make the client-side implementation of WMs nicer

13:20 <ifreund> and in particular easier to use from guile scheme, though I believe it's intended to be general purpose

13:21 <ramblurr> is pr #1100 at a state where clients could be written against it?

13:22 <ifreund> the server side implementation isn't complete yet but I'm pretty confident the general structure of the protocol won't change drastically

13:22 <ifreund> so clients can be written in theory but not really tested yet as there is not yet a complete server implementation

13:25 <ramblurr> hmm i'd be interested in seing that library, i suppose it's related to their work on riverguile?

13:27 <ifreund> As I understand it, it is a rewrite with lessons learned from riverguile and targeted at the new draft protocol

13:27 <ramblurr> in clojure the biggest pain point of implementing FFI is that static inline functions defined in headers aren't callable, because they aren't compiled as standalone symbols

13:28 <ramblurr> and it seems most of what wayland-scanner produces is static inline functions :\

13:30 <ifreund> this repo might be of interest: https://github.com/gfxstrand/wayland-java

13:31 <ifreund> doesn't seem to be actively used/maintained, but gfxstrand very much knows their stuff

13:35 <ramblurr> yea that's one of the first things i came across, unfortunately it uses JNI the older way of doing FFI on the jvm.

13:36 <ramblurr> something like it could (should?) be created for the new way

15:17 <leon-p> ramblurr: the library I am working on explicitly avoids the user needing ot install callback functions and instead has a blocking next_event() function

15:18 <leon-p> the API is designed with FFIs in mind (at least the ones I know how to use)

15:18 <ramblurr> sounds handy! is it available to play with?

15:19 <leon-p> language bindings can of course expose that in whatever way they see fit, f.e. the guile bindings don't expose that function and instead calls it internally and uses it to raise hooks

15:19 <leon-p> I don't think I have pushed it anywhere yet

15:19 <leon-p> either way, it can't do much without a server implementation

15:20 <leon-p> if it helps, I can descrive how events work though: The function returns a C struct with an enum tag follows by a union.

15:21 <leon-p> Some languages have issues parsing C unions, so instead there is also another function which returns a pointer to that event struct, since pointercasts seems to be easier to do than struct casts

15:22 <leon-p> since all events come through the single next_event() function, it isn't exactly object oriented like wayland, you just get opaque pointers for windows/outputs/etc

15:25 <leon-p> I should probably do an implementation of the current layout protocol with that library, so the basic design can be tested right now

15:25 <leon-p> maybe later

15:27 <larstiq> leon-p: ah, what made you decide on the next-event way?

15:27 <leon-p> I did not want callback functions, the language bindings should decide how to dispatch

15:28 <ramblurr> how would a user of that lib register listeners like river's layout listener"

15:28 <leon-p> that would be behind-the-scenes magic

15:29 <ramblurr> in your lib?

15:29 <larstiq> leon-p: sounds sensible

15:29 <leon-p> you create the library context, init the connection and go into your event-loop calling next_event()

15:29 <leon-p> the library does the rest

15:29 <ramblurr> ah so this is a very river specific lib :)

15:29 <leon-p> probably

15:30 <leon-p> I am not interested in writing a general purpose high-level wayland

15:30 <leon-p> this is specifically for writing a WM with that exact protocol

15:31 <leon-p> other wayland servers can of course choose to implement that very same protocol, in which case it may work with them as well

15:33 <leon-p> ramblurr: if you are enthusiastic about writing a WM, you should focus on what you can do and test right now: f.e. I spend a significant amount of time already writing the code that will draw the desktop shell elements. That can be tested via the layer shell and later ported to proper widgets

15:34 <leon-p> although I am on the fence whether the library should include that or just expose the pixman_image_t

15:45 <The_Buhs> Is there some simple explanation of what's part of window management versus the compositor (once they become separated)? Is the wm: window layout, keybinds, ssd/csd, and the mouse pointer?

16:02 <leon-p> The_Buhs: WM decides window geometry, placement, decoration, visible vs hidden, keybinds

16:02 <leon-p> maybe even more

16:10 <The_Buhs> ty

20:50 <bist> I'm using archcraft with wayland and river. Could someone point me in the right direction where I can configure the time on the screensave/lock screen? I checked in .config/river/init but found nothing.

21:21 <leon-p> the screenlocker is not part of river but an external program

21:22 <leon-p> you need to find out which one

21:22 <leon-p> the one I am aware of which can display time is swaylock

23:14 <andrew`> I am using river in a virtual machine and am seeing significant lag in cursor movement. Does anyone know if this is expected or if there is a workaround?