12:19 <zuki> I'm trying to extend the layout generator at https://codeberg.org/river/river/raw/branch/master/contrib/layout.c, I'm running into a issue of my layout_handle_user_command_tags function not being called even though its in the river_layout_v3_listener struct (as `.user_command_tags = layout_handle_user_command_tags,`). I'm not sure what I'm missing.

12:22 <zuki> paste bin of the modified layout.c https://pastebin.com/GEwKWf1R.

12:35 <leon-p> zuki: you can run any wayland client, including your layout generator, with WAYLAND_DEBUG=1 in the env to see debug output

12:36 <leon-p> this allows you to see if the event is even send

12:36 <leon-p> although your printf() call in the user command handler is commented out

12:37 <leon-p> if you f.e. fprintf(stderr, ">>> %s\n", _command) in layout_handle_user_command() (before the early returns), you should see something

12:37 <zuki> I should have removed that to avoid confusion the problem is the printf() call in layout_handle_user_command_tags never runs

12:38 <leon-p> well, in that was a later addition to the protocol

12:38 <leon-p> make sure you bind the right version

12:40 <leon-p> in your registry handler, you bind version 1 of the layout protocol, you need version 2

12:40 <leon-p> if you look at the event in the spec (river-layout-v3.xml) you'll find the since="2" attribute

12:40 <zuki> thanks so much

12:40 <leon-p> no problem :)

12:41 <leon-p> but since you are already in the mood for writing a layout generator, maybe take a look at pull request 1100, which replaces the layout protocol with a full window management protocol

12:41 <leon-p> a bit more involved but also a lot more fun

12:42 <zuki> I've heard about that pull request but haven't given it a proper look It sounds like it would be fun.

12:42 <zuki> Is the pull request in a state were it usable?

12:44 <leon-p> almost. it's enough to play around with (I have an experimental WM I am working on) but some less important events aren't wired up yet

12:45 <leon-p> you can even do custom window decoration now!

12:45 <leon-p> https://files.mastodon.social/media_attachments/files/114/742/126/739/002/622/original/2799f318e8e3826d.png

12:47 <zuki> holy shit, that's really cool!

12:48 <leon-p> yeah the custom UI stuff turned out to be a lot more fun than playing around with just window management :)

12:51 <ifreund> fyi, we might need to move to wl_fixed or similar for coordinates eventually to make fractional scaling good

12:51 <leon-p> ugh

12:51 <ifreund> I'm not sure if it will be possible to do things entirely on the compositor side or not

12:52 <zuki> whats wrong with fractional scaling on wayland aside from xwayland?

12:53 <leon-p> the question of how to round coordinates mostly, from my PoV

12:53 <ifreund> zuki: right now wlroots uses position-dependant scaling which can lead to buffers being blurry due to being stretched by 1 pixel in order to avoid a gap e.g. between a window and its border

12:53 <ifreund> there is draft work for wlroots/sway to use position independant scaling which eliminates that problem

12:54 <ifreund> but it relies on sway positioning all its scene nodes such that they align with the pixels of the output they will be rendered on after scaling

12:56 <leon-p> I'd personally be fine with any approach as long as it doesn't lead to gaps in my window decoration. moving the entire window node tree to align with physical pixels is fine IMO

12:57 <ifreund> the problem is more the positioning of the decoration surfaces relative to the xdg_toplevel's surface

12:58 <ifreund> maybe there's a way we can keep using nice abstract integer logical coordinates in the rwm protocol and do something fancy to fix things up on the compositor side

12:58 <ifreund> that's a serious research project though, I don't know if anyone's ever done that before

13:00 <leon-p> I am also fine with stretching decoration surfaces by a pixel. Although I am biased here, since that's how my decoration works anyway I guess...

13:00 <ifreund> my current plan is to just keep the protocol as-is for now and come back to this after I have some non-trivial wm's to test with

13:01 <ifreund> leon-p: stretching decorations surfaces by a pixel would make them blurry...

13:01 <leon-p> Hmmm...

13:03 <leon-p> I guess that's an inherent problem with wayland scaling model. Rather than giving a scale (whether integer or multiple of 1/120 is irrelevant), it might be better to just have the server communicate the exact pixel size for the rendered buffer...

13:06 <ifreund> I don't think that would solve this problem, the protocol already is telling the client an exact pixel size

13:06 <ifreund> it just communicates it as a scale from one protocol + a configure event from a different protocol

13:13 <leon-p> well, I'll leave the scaled coordinate fun to others

13:13 <leon-p> I'll use whatever solution works and is considered canonical

13:18 <Nickli> leon-p, that border reminds me a little of the ones in BeOS/HaikuOS

13:23 <leon-p> Nickli: it's mostly inspired by motif and CDE, but a lot of toolkits in that era had a similar style

13:24 <leon-p> I also plan on supporting decoration style inspired by windowmaker / nextstep and a few custom ones. It's fairly simple to add new styles, the hard part is coming up with them :)

13:26 <leon-p> I initially wanted to allow users adding a custom bitmap as decoration texture, but that wouldn't work well with scaling :/

13:46 <Nickli> there were a lot of them back in gtk2/3

13:47 <leon-p> yeah, but I am only interested in the ones that look goot :)

13:47 <leon-p> *good

13:48 <leon-p> it's also limited in the way that the decorations can't have any change along the axis parallel to the window-side they are attached to, since it's a fixed-size texture that gets stretched

13:54 <Nickli> guess World of Warcraft or Warcraft 3 like border decorations are out of the question then

13:56 <leon-p> not if you implement your own WM 🤷

14:14 <leon-p> currently experimenting with replacing chickens cheme with s7 since it's a lot more friendly to being used embedded in another program and it add 41MB to a debug build, holy hell

14:14 <leon-p> a release build is somehow smaller than a release build with chicken, but also two minutes slower...

14:14 <leon-p> experiments will continue to see if this is a good idea

14:19 <bitblt> my dream is that at some point an embedded or native dialect of clojure will appear and we can start using that for scripting

14:20 <bitblt> i've used s7 around 10 years ago for scripting in game development and had some issues that i cannot remember fyi

14:28 <leon-p> I'll find out soon if it works for me. The main reason I want to try it is because it allows me to define scheme procedures from zig. With chicken I have to expose a C ABI function and write chicken bindings for that function. If I can parse arguments to some of the procedures I expose directly in zig, I can drop a lot of code including the C header file which defines a few enum to make chicken happy which are fully redundant with the internal zig enums and a

14:28 <leon-p> pain whenever I want to add anything new

14:29 <__toor__> is there a way to make windows not allowed to move under the potential menubar?

14:30 <__toor__> I am experimenting with floating windows and when I move them I would like it to not go under the waybar on the top

14:31 <leon-p> you mean with current river (not rwm)? Then no

14:31 <__toor__> sorry, I have been away for a while rwm is a neu river?

14:31 <leon-p> rwm is basically "layout generators are cool, but what if they were proper window managers?"

14:31 <__toor__> I am on river 0.3.5 (or at least riverctl -version is that)

14:32 <leon-p> yeah, in that case there is no way to restrict window movement like you want. it should be possible to hack that in though, since that area is computed already as the usable area for layouts

14:34 <__toor__> is that something that rivertile handles? perhaps I could give it a try then if its fairly isolated

14:34 <leon-p> it's internal to river

14:50 <leon-p> ah, s7 just outright segfaults when compiled with zig, nice! guess I'll stay with chicken for now

15:56 <__toor__> chicken scheme?

15:57 <__toor__> scheme is a beautiful language in its own way. but i dont see why people insist on using it outside academia. Lua or Javascript is right there :D

16:56 <leon-p> writing scheme is more fun than writing lua or js

16:56 <leon-p> however integrating scheme with other code which interfaces with the real-world

17:58 <ifreund> bitblt: Im doing my stuff in janet, which is quite similar to clojure I believe (never used clojure)

17:59 <ifreund> https://codeberg.org/ifreund/janet-wayland/src/commit/69ed5e4d2319e394755fd2ef9308203e80cd2c60/example/hello.janet#

17:59 <ifreund> A taste of the janet Wayland bindings I made ^

18:00 <ifreund> Also there is a native clojure dialect called jank

18:00 <bitblt> this seems nice

18:00 <ifreund> It wasnt that mature last time I looked though

18:00 <bitblt> but clojure is on a whole new level as a better language in general :)

18:01 <bitblt> (although kinda hard for people that arent into pure functional stuff)

18:04 <ifreund> bitblt: what does clojure have that janet doesn't? It definitely seems like a far more popular/mature ecosystem but the janet language doesn't seem to be missing anything major from my perspective

18:07 <bitblt> you won't see any difference in simple usages

18:08 <bitblt> but when things start getting more complex, the combination of immutable data structures with its standard library is extremely powerful

18:19 <ifreund> bitblt: janer has immutable data structures and the standard library has quite nice functional programming APIs fwiw

18:19 <ifreund> I can confirm that that combination is very comfy for high level code

18:20 <ifreund> I do think you're right that clojure leans heavier into immutable data though

18:20 <ifreund> I should try it out at some point

18:21 <bitblt> It does have immutable data structures? I didn't remember that