Palanix has quit [Read error: Connection reset by peer]
Palanix has joined #river
eShaev9z has quit [Ping timeout: 248 seconds]
eShaev9z has joined #river
Palanix_ has joined #river
Palanix has quit [Ping timeout: 248 seconds]
Palanix_ is now known as Palanix
Palanix has quit [Ping timeout: 276 seconds]
Palanix has joined #river
angry_vincent has joined #river
lordmzte1 has joined #river
<lordmzte1>
I've just had a though for a really neat feature: what about a riverctl command that can "upgrade" any normal window to a layer shell surface with a given positioning? This could be really useful. For example, I could open a music visualizer and then use it as a background, or I could open htop or some other system monitor and anchor the terminal
<lordmzte1>
window to be a fixed-size, tag-independant bar. This also seems like it should be doable, right?
lordmzte1 is now known as lordmzte
tiosgz has joined #river
<tiosgz>
lordmzte: what you want should very well be possible with the wm protocol (and is unlikely to happen in river itself)
<tiosgz>
but to make this clear: something being layer-shell means it uses that specific protocol, and there is no way, server- or client-side, to convert between xdg-shell and layer-shell
<tiosgz>
(other than just destroying the xdg-shell window and creating a layer surface)
<tiosgz>
(which must be done client-side)
<lordmzte>
How so? On the client side, the shell is just a means of creating the surface. Once the surface is created, what's stopping the compositor from changing its behavior?
<tiosgz>
you can change its behaviour (though you may be limited by the respective protocols, which isn't a problem here), but you can't change which protocol the client uses
<lordmzte>
But once the surface is created, the protocol is identical.
<tiosgz>
again, i am not arguing whether what you want to achieve is possible, just pointing out what the protocol is
<lordmzte>
yes, but both protocols will ultimately create a `wl_surface`
<tiosgz>
because there is no reason not to use a wl_surface
<lordmzte>
Yes. And now that we have a wl_surface the client created through xdg_shell, the compositor could theoretically move that wl_surface to layer shell.
<tiosgz>
a protocol gives the client different possibilities (and also the compositor wrt what it can request from / communicate to the client)
<tiosgz>
now that we have a wl_surface, we can display it mostly arbitrarily. but we can't convert its "wrapping object" to a different "wrapping object" cos that would only confuse the client a huge big lot
<lordmzte>
oh right.
<lordmzte>
Yea.
<lordmzte>
On another note, are you sure this is possible with the layout protocol? I don't think the layout protocol can change the tags of a given window such that is occupies all surfaces, can't prevent the window from being focused and probably also can't control the order of multiple overlapping windows (for backgrounds)
<tiosgz>
not with the layout protocol, definitely not. with the window management protocol that's currently in the planning phase
<tiosgz>
it isn't worth anything trying to implement a client with it yet though, obviously
anjan has quit [Ping timeout: 245 seconds]
Den4ikRus has quit [Ping timeout: 245 seconds]
ifreund has joined #river
larstiq_ has joined #river
Den4ikRus has joined #river
LarstiQ has quit [Ping timeout: 245 seconds]
<lordmzte>
Yes, but this looks really interesting. I'll probably implement a client with this protocol once it's ready. I assume it's supposed to replace the current layout protocol?
anjan has joined #river
<tiosgz>
it replaces the layout protocol indeed (and maybe also the other river-specific protocols, i don't know exactly)
<lordmzte>
I find the choice really interesting to have a request for the window manager to create a surface for its UI.
qyliss has left #river [WeeChat 4.3.3]
<lordmzte>
Why wouldn't the WM just go through XDG shell?
<tiosgz>
because it doesn't make sense for most stuff and it would need to identify itself and... i don't even know what else
<tiosgz>
xdg-shell is for normal windows which is just impractical here and would abuse xdg-shell for something else. and you don't need most of its possibilities
tiosgz has quit [Quit: nyaa~]
<lordmzte>
How is a surface created by the WM different from any normal window?
tiosgz has joined #river
<tiosgz>
lordmzte: first of all, the wm knows for certain "this is my surface, exacly this one i created for that purpose" without any unnecessary hacking and/or identification
<tiosgz>
it also doesn't make much sense to communicate the xdg-shell-specific stuff back to itself, perhaps unless it really wants a regular window
<tiosgz>
the purpose of these shell-surfaces is e.g. a status bar, some desktop widgets, whatever
tiosgz has quit [Quit: nyaa~]
Guest3 has joined #river
Guest3 has quit [Quit: Client closed]
waleee has joined #river
<ifreund>
yep, pretty much
<ifreund>
using xdg-shell for desktop shell components created by the window manager would do nothing but add unnecessary complexity
<ifreund>
RE converting xdg shell to layer shell, I started hacking up a proxy for that a long time ago but abandoned it as it didn't seem worth my time