<ifreund>
We would expose these things as well in the future as well after that work gets merged
yiyu has quit [Read error: Connection reset by peer]
yiyu has joined #river
<ifreund>
actually, I think I may have just changed my mind again :/
<ifreund>
ext-image-copy-source-v1 is based on wl_outputs
<ifreund>
so the window manager might need a wl_output to implement a screenshare UI
<ifreund>
lets just link them, the lifetime issue isn't that hard
<ifreund>
and I'm leaning towards exposing only 1 wl_output during mirroring/tiled display anyways if/when we get those features
autisticshark has quit [Ping timeout: 260 seconds]
autisticshark has joined #river
<zuki>
I managed to make a river window manager, lots of missing functionality mainly not implementing binds yet, but It can tile windows and can focus a window on mouse over.
<zuki>
I'm a little confused if river is supposed to be able to switch to a new window manager on the previous wm exiting.
<zuki>
When my wm exit's, if it exits gracefully then all other window managers trying to connect just stall,but if it crashes after sending a update_rendering_finish signal then I can restart my window manager and it will reconnect and work mostly normally except, if there is preexisting windows then the compositor will crash upon the last one being
<zuki>
closed.
<ifreund>
zuki: indeed, there is some bug around switching window managers currently
vimproved has quit [Ping timeout: 248 seconds]
<ifreund>
the long term plan is for river to have some kind of fallback window manager that allows the users to restart or switch window managers if the currently running one crashes
<ifreund>
as well as a hardcoded compositor keybind to kill the current window manager
<ifreund>
Right now, one has to restart the compositor every time one restarts the window manager though, I haven't gotten around to digging in yet
fitrh has joined #river
<leon-p>
oh I totally agree that wl_output was a mistake :P
<leon-p>
but that ship has sailed, I think
<leon-p>
we can drop wl_output in
<leon-p>
~40 years when X13 replaced wayland
fitrh has quit [Remote host closed the connection]
zuki43 has joined #river
zuki43 has quit [Client Quit]
fitrh has joined #river
<lordmzte>
But what about x12? 🤔
twelve has joined #river
Ireozar has quit [Read error: Connection reset by peer]
Ireozar has joined #river
Keeto has quit [Quit: Lost terminal]
<Nickli>
it became W12 -2
fitrh has quit [Ping timeout: 272 seconds]
vimproved has joined #river
notzmv has joined #river
yiyu has quit [Ping timeout: 252 seconds]
yiyu has joined #river
yiyu has quit [Ping timeout: 248 seconds]
yiyu has joined #river
yiyu has quit [Read error: Connection reset by peer]
yiyu has joined #river
twelve has quit [Remote host closed the connection]
<ifreund>
leon-p: pushed wl_output and wl_seat association
<ifreund>
the serial-based seat op thing will have to wait until I actually implement starting serial based seat ops
yiyu has quit [Read error: Connection reset by peer]
yiyu has joined #river
<leon-p>
nice, thanks!
<leon-p>
I should be able to do menus and resize by border-dragging now
fitrh has joined #river
<leon-p>
after I ported the fontpool from the C version of antares that is; Just implemented titlebars and they look like sad and empty without buttons and text :)
<ifreund>
leon-p: what language have you settled on now?
<leon-p>
zig + chicken scheme. It's the least headache inducing combination
<ifreund>
cool :)
<ifreund>
zuki: I fixed the bug stopping one from switching between window managers by the way :)
<zuki>
awesome thanks so much, that should make testing much easier.
<ifreund>
no problem :)
<leon-p>
zuki: what's your tech stack?
<zuki>
I'm just using c
fitrh has quit [Ping timeout: 272 seconds]
<ifreund>
Definitely a valid option
<ifreund>
in janet-wayland news, I figured out that I need to patch libwayland :/
<ifreund>
but the high level janet API is going to be worth it :D
<ifreund>
I'm already using it for testing protocol changes cause its so much quicker to modify than the zig version
<leon-p>
yeah I've seen the discussion on #wayland@oftc :)
<leon-p>
do you already do REPL driven development?
<ifreund>
I am somewhat surprised that nobody else seems to have done as thorough of a job at libwayland bindings for a dynamic language as I am doing yet.
<Nickli>
🐔
<leon-p>
zuki: btw let us know if you require any pointers w.r.t. drawing custom UI. I've figured out how to do that in Cairo and pixman and are happy to share to others don't have to go through that
fitrh has joined #river
<ifreund>
perhaps no one else is trying to integrate into a single threaded event loop?
<ifreund>
leon-p: no, my REPL works but is is still kinda lame because Janet doesn't have the decades of tooling that common lisp/scheme have
<leon-p>
maybe people interested in dynamic languages are turned off by code generation :shrug:
<ifreund>
I need to write a better REPL server and kakoune plugin at some point so I can just save a file to have the running program be updated to match
<leon-p>
you might also want a "send selection or region" command, which is often a bit nicer than sending the entire file on save
<ifreund>
even in its limited state though the REPL attached to the running wm is fantastic for debugging
<ifreund>
leon-p: I have that, the missing part is the server knowing which file the input is coming from
<leon-p>
I see
<ifreund>
and evaluating the input in the correct environment
<leon-p>
I have all scheme stuff in the same environment. I get a separation between low-level things and high-level, safe-to-play-with things for free at the zig / scheme boundary.
<ifreund>
leon-p: does scheme not have separate namespaces for separate files? I'm talking about enviroment in that kind of sense
sugarbeet has quit [Ping timeout: 260 seconds]
sugarbeet has joined #river
<leon-p>
it does! but I took care to avoid that, because I want every definition to be available to the users init
notzmv has quit [Ping timeout: 248 seconds]
<ifreund>
I see :D
<leon-p>
and the hook model is working quite well so far. It's definitely possible to do hacky jank, but it also makes it very simple to add even more complex features like always-on-top (which is just a hook after calling place-top which moves the window below all always-on-top windows, f.e.)
<leon-p>
this means window management features can be developed in the init, without needing to recompile at all
<leon-p>
although currently UI is more fun to me, so I am in pixel-placing hell and dreading the day I can test it with fractional scale
notzmv has joined #river
notzmv has quit [Ping timeout: 252 seconds]
notzmv has joined #river
notzmv has quit [Ping timeout: 252 seconds]
fitrh has quit [Ping timeout: 272 seconds]
<leon-p>
porting my font pool from C to zig, I just discovered what is arguably the greatest upside of using zig over C: I don't have to do any magic incantations to make sure a UTF8 enabled locale is active to appease the conversion functions...
<pkap>
ifreund: I started to make zig-wlroots for image-copy-capture and image-capture-source. However, a part of image-capture-source (the toplevel part) is not released in wlroots yet. Do you prefer separate PRs in zig-wlroots as well?
<ifreund>
pkap: however you like, if you split it up we can merge the part that's already in wlroots 0.19 sooner
<ifreund>
leon-p: indeed, not using the c standard library is great
zuki has quit [Quit: Client closed]
zuki has joined #river
<pkap>
ifreund: Great! I'll split it up then.
Snetry has quit [Ping timeout: 252 seconds]
Snetry has joined #river
twelve has joined #river
Nosrep has joined #river
twelve has quit [Remote host closed the connection]
coreopen has joined #river
zuki has quit [Quit: Client closed]
Guest26 has joined #river
Guest79 has joined #river
Guest26 has quit [Ping timeout: 272 seconds]
zuki has joined #river
<zuki>
Just went though half a hour of confusion before I realized that the river_window_v1 passed by river_seat_v1_listener.pointer_enter was set to null upon function exit.
schneid3306 has joined #river
Guest79 has quit [Ping timeout: 272 seconds]
schneid3306 has quit [Ping timeout: 268 seconds]
zuki20 has joined #river
zuki has quit [Ping timeout: 272 seconds]
<leon-p>
zuki20: the object should still exist, the function argument should a pointer to a river_window_v1 object which is internal to libwayland. Pointer stability is guaranteed: Two pointers to the same object will always compare as identical
<zuki20>
I've been stuck on this for a while and completely unsure what mistake im making.
<leon-p>
have you bound all window objects?
<zuki20>
I'm not what what exactly you mean but I've used river_window_v1_add_listener on every new window event and stored all window data into a linked list struct, if thats what you mean.
<zuki20>
I can just send my full repo if it would be of help.
<ifreund>
you pass a pointer to a pointer to a Seat as the user data
<ifreund>
you probably intent to pass just seat not &seat
<zuki20>
AHHHHHHHH, yeah I did it fine for all the other river_v1_add_listeners but typo'ed that one. thanks so much
<ifreund>
valgrind probably would have caught it fwiw
<ifreund>
or asan
<ifreund>
If you stick to C I highly recommend getting used to using one of those
<leon-p>
also -fanalyzer, if your gcc is new enough
<ifreund>
this also wouldn't have compiled if using zig-wayland :D
<leon-p>
or a newer C compiler, because the noop trick doesn't work anymore :)
<zuki20>
I've now switch to using asan thanks for the tips
<zuki20>
and once again thanks for the help!
zuki20 has quit [Quit: Client closed]
schneid3306 has joined #river
bitblt_ has joined #river
bitblt has quit [Ping timeout: 260 seconds]
bitblt_ is now known as bitblt
ccha has quit [Ping timeout: 252 seconds]
Guest79 has joined #river
Snetry has quit [Ping timeout: 252 seconds]
sentry has joined #river
Nosrep has quit [Remote host closed the connection]
Nosrep has joined #river
Guest79 has quit [Quit: Client closed]
mewt has joined #river
<mewt>
Hi, quick question: is there any known way to remove the titlebar on applications not listed in the workarounds of the FAQ? Zathura is particularly painful
<mewt>
well, looks like in the backlogs the answer is essentially "gtk doesn't give us a way to tell it not to do this"