catman has quit [Remote host closed the connection]
catman has joined #river
angry_vincent has quit [Ping timeout: 246 seconds]
angry_vincent has joined #river
leviathan has joined #river
eShaev9z has joined #river
eShaev9z_ has quit [Ping timeout: 272 seconds]
novakane has quit [Ping timeout: 240 seconds]
kennylevinsen has quit [Ping timeout: 240 seconds]
geemili has quit [Ping timeout: 240 seconds]
geemili has joined #river
novakane has joined #river
kennylevinsen has joined #river
leviathan has quit [Quit: Client closed]
angry_vincent has quit [Ping timeout: 255 seconds]
angry_vincent has joined #river
leopoldek has quit [Ping timeout: 240 seconds]
pfr has joined #river
pfr has quit [Client Quit]
pfr has joined #river
hspak has quit [Quit: Ping timeout (120 seconds)]
hspak has joined #river
pfr has quit [Quit: Quit]
leviathan has joined #river
pfr has joined #river
pfr has quit [Client Quit]
leviathan has quit [Quit: Client closed]
leviathan has joined #river
leviathan has quit [Quit: Client closed]
leviathan has joined #river
leviathan has quit [Quit: Client closed]
leviathan has joined #river
Guest14 has joined #river
<Guest14>
Greetings. I've been reading through river's manpages and wiki a bit and tried it out. It seems that while custom layouts can be created, these are unaware of actual windows and one cannot have scripts react on arbitrary events and act on individual windows as possible with swaymsg. Is that correct? Am I overlooking something?
<leon-p>
that is correct
<leon-p>
however there are plans for more flexibility
<leon-p>
(fwiw scripts as event listeners are kinda terrible either way, since they do not guarantee frame perfection. Wayland scripting should be done with proper wayland clients)
<Guest14>
Unfortunatly that makes the entry barrier for customizability high. I don't think learning how to do manual memory management correctly (I think 'proper wl clients' need C/Zig/Rust (?)) just to code window placements is worth it. But I'll try some of the existing layout makers, maybe one of them will already be sufficient for me.
<leon-p>
you don't really need to learn C or similar
<leon-p>
F.e. I am working on a scripting layer for river in guile scheme
<leon-p>
should be possible to also bind the backing library to lesser scripting languages like python which people commonly claim are simple
<leon-p>
as for window placements, we also have rules in river master
<Guest14>
Oh cool. Guile is the one I'm planning to learn once I enter lisp territory.
<leon-p>
that's the proof of concept implementation
<Guest14>
But its's a future thing, right?
<Guest14>
Thank you. Gotta go, but will keep this on my radar
Guest14 has quit [Quit: Client closed]
<ifreund>
if y'all are wondering what I'm up to today, I'm working on the biggest remaining release blocker: updating my website for the first time in over a year
<ifreund>
I've completely forgotten how to use hugo and relearning it feels just as hard as learning a more transparent alternative so I'm now in a janet rabbit hole
<ifreund>
I've wanted to try janet for something meaningful for a while and so far it's been great
alexherbo2 has joined #river
<leon-p>
neat!
<ifreund>
I almost went with https://dthompson.us/projects/haunt.html in order to learn some guile so I can play with riverguile and its future evolutions but getting a copy on my musl based distro working proved to be too much effort
<ifreund>
it seems to be pretty easy to make static binaries for janet, which is great for a ssg
<leon-p>
fwiw many guile projects also work in other scheme impls, like chicken which I think is easier to bootstrap
<ifreund>
yeah, chicken is probably what I'll go with when I get around to properly messing with a scheme
<ifreund>
iirc it compiles to C code which is fairly easy to compile into something statically linked
<leon-p>
it does, but only optionally IIRC
<leviathan>
Great to see you all active again! Due to time zone differences, I've been unclear about when you're most active.
<leviathan>
Sometimes I want to ask questions about the design and implementation of River, but you're all not around, which can be frustrating.
<leviathan>
Returning to yesterday's question, I'm wondering if it's feasible to use seat.focused_output to position the IME_popup surface?
<leviathan>
In my implementation, positioning the IME_popup surface only requires a parent output_box and the parent scene graph.
<leviathan>
I noticed that Output.zig includes tree: *wlr.SceneTree, and I'm unsure if this could serve as the parent scene tree for the IME_popup surface object.
<leviathan>
Alright, I made another typo – there's no such thing as a scene graph, it's a scene tree.
<leon-p>
leviathan: this channel has logs, check the link in the header. So you can ask questions and come back later
<ifreund>
leviathan: is the compositor supposed to send pointer events to input method popup surfaces?
<ifreund>
if so they probably belong in the Output.layer.popups scene tree
<ifreund>
if not, they may need to go somewhere else in order to not interfere with input event routing
<leviathan>
Yesterday, I took a look at the protocol and found that wlroots' description of the input_method_v2 protocol is rather rudimentary.
<leviathan>
In my view, input method popup surfaces probably don't need pointer events.
<ifreund>
what do other compositors do? what do clients expect?
<ifreund>
how do clients even use these surfaces? is it purely a visual feedback or are they interactive?
<leviathan>
It's merely for visual feedback. Both Sway and Hyprland locate their associated View object through the input method popup surface, and from the View object, they obtain its output and scene tree.
<leviathan>
Actually, it's quite odd, but I don't think the compositor sends pointer events to input method popup surfaces.
<leviathan>
However, when I click on the input method popup surface with a mouse, the IME software still responds.
<ifreund>
how does it respond?
<leviathan>
The input method popup surface displays several candidate words, and when I click on one, the input method popup surface disappears, and the selected text is shown at the input location.
<ifreund>
well then the compositor absolutely does need to send pointer events to input method popups surfaces
<ifreund>
which means they belong in the Output.layer.popups scene tree
<ifreund>
probably touch and tablet events as well
<leviathan>
That's great! So, all I need is to obtain seat.focused_output to perform all operations?
<leviathan>
If I understand correctly, the input method popup surface only appears on the focused output, right?
<ifreund>
To route input events you'll need to add a new SceneNodeData type for input method popups and handle it in the places required
<ifreund>
you'll see where in the code that tagged union is currently switched on
<ifreund>
as for positioning, I'm not sure I understand what the problem is... The goal is to position the popup relative to the text input rectangle of the text-input client's surface
<ifreund>
so you'll need to determine the output relative coordinates of that surface, which means you need to obtain the parent view/layer surface/etc
<leviathan>
If we don't need to worry about the surface going out of bounds, from what I've seen, we might only need to use tree.node.coords() to get the position of the parent scene tree？
<leviathan>
Also, combining this with server.root.output_layout.getBox(output.wlr_output, ) seems to allow for precisely determining the position where the window pops up
<ifreund>
leviathan: node.coords() will give you output layout coordinates iirc, that is not relative to the output
<ifreund>
there's some wlroots function to adjust them to be relative to a given output in the layout
<ifreund>
yes, we do need to make sure the input method popup isn't placed partially out of bounds of the output
<novakane>
ifreund: re scheme: chicken is pretty cool, I prefer it over guile personally
<novakane>
didn't write any big project with it but a compiled binary to replace my shell script for zelbar which was nice to write
<ifreund>
leviathan: to answer your question more concretely, I think it would be more robust to use wlr_output_layout_output_at() to obtain the specific wlr_output
<leviathan>
Alright, thank you very much. I'll carve out some time later to optimize the implementation.
leviathan has quit [Quit: Client closed]
waleee has joined #river
leopoldek has joined #river
waleee has quit [Quit: WeeChat 4.1.2]
catman has quit [Quit: WeeChat 4.3.0-dev]
catman has joined #river
<ifreund>
website rewriting went well today, I believe all that's left to do to match the old hugo output is the atom feed
<ifreund>
oh, and sitemap.xml if that's even needed...
alexherbo2 has quit [Remote host closed the connection]
<LarstiQ>
I suppose that lets webcrawlers (e.g. google) generate a sort of toc under your site in their results
<LarstiQ>
needed is a big word
<ifreund>
I'm not sure if the one hugo has automatically generated is even being used. It's at https://isaacfreund.com/sitemap.xml but isn't referenced anywhere on the site
<ifreund>
do things know to look there?
<ifreund>
also, doesn't an atom/rss feed serve the same purpose?
<novakane>
now I need to look at it before the update to remember what it looks like when I saw it for the last article :P
<ifreund>
novakane: it's going to look exactly the same after the migration is done. The migration will unblock a much needed content update and expansion though :)
<novakane>
oh ok, well that the most important part :D
<ifreund>
The thing I really like about bagatto is that I can take it apart and see how it works and how the data flows, the repl makes that even easier
<novakane>
looks better than html or whatever to me for sure
<ifreund>
hugo was like a massive black box with heaps of inpenetrable extreemely generic documentation
<novakane>
repl is really an awesome invention
<ifreund>
the hope is that next time I don't look at this code for years and then want to change it baggato will make that much easier