autisticshark has quit [Ping timeout: 255 seconds]
autisticshark has joined #river
peelz has quit [Ping timeout: 256 seconds]
peelz has joined #river
peelz has quit [Changing host]
peelz has joined #river
waleee has quit [Ping timeout: 272 seconds]
eShaev9z has joined #river
eShaev9z_ has quit [Ping timeout: 256 seconds]
waleee has joined #river
waleee has quit [Ping timeout: 240 seconds]
lillian has quit [Ping timeout: 252 seconds]
lillian has joined #river
Guest25 has joined #river
<Guest25>
hey, i wanna remove title bar in river for a specific application only. is that possible?
Guest25 has quit [Client Quit]
Guest64 has joined #river
<leon-p>
there are rules you can use to decide SSD vs CSD (search for "rule" in riverctl.1)
<leon-p>
however whether a title bar disappears is the decission of the client itself in the end
Guest64 has quit [Quit: Client closed]
Guest83 has joined #river
<Guest83>
nvm, ive changed it from the app itself
<Guest83>
a little bit related, river turns into a black screen with a curser that's controllable if i run swaylock twice (one from swayidle, one manually)
<Guest83>
also wlopm is running to turn off the screen
Guest83 has quit [Quit: Client closed]
Guest26 has joined #river
<Guest26>
i cant do anything except go to another tty then kill it, is there anyway to fix this?
<leon-p>
I don't think it should be possible to run swaylock twice?
<leon-p>
Sounds a bit like you caused swayidle to crash
<leon-p>
thanks to the new screenlocker protocol, the session remains locked when the screenlocker crashes
<leon-p>
you could switch to a tty, set WAYLAND_DISPLAY=wayland-1 and then launch swaylock from there again
<leon-p>
return to the river tty and unlock as usual
<Guest26>
i have swayidle running just to turn off the screen, and things are running fine
<Guest26>
ill try that then
Guest26 has quit [Ping timeout: 250 seconds]
<LarstiQ>
ifreund: that looks pretty nice! If you'd import `wayland` instead of `zig-wayland`, would you only get the C symbols? Bit unsure when something needs to be wrapped vs only linked
NickH has quit [Ping timeout: 260 seconds]
<dnkl>
not sure if I've asked this before... how hard would it be for river to emit the "preferred scale" event (fractional scale) *before* mapping the window?
NickH has joined #river
leopoldek has quit [Ping timeout: 276 seconds]
haliucinas has quit [Quit: .]
haliucinas has joined #river
itshog has joined #river
lbia has quit [Ping timeout: 260 seconds]
tiosgz has joined #river
<tiosgz>
leon-p: i can't believe i've messed up more than i've fixed (or i can, but it would have uncomfortable implications about my need to take a break)
<tiosgz>
are you on post-4685f690 river?
<tiosgz>
(that re #980)
<leon-p>
tiosgz: oh, I actually didn't notice that you fixed it
<leon-p>
I am on 69a51cadb41443103370247ac515f1067da4b932
<leon-p>
I just had it in my mental todo list to create an issue for this. whoops
<tiosgz>
ah. relieving :)
<leon-p>
weird, I don't think I missed any mail from github, usually I stay on top of what's happening
<leon-p>
but oh well, that's what stress does I guess 🐈
<tiosgz>
does gh send e-mails about commits? cos otherwise it could only be from cb
<LarstiQ>
tiosgz: I at least get emails for commits in a zig PR I've commented on
<tiosgz>
leon-p: oh, and re #981. do you think multiple independent transactions would be practical? (e.g. imagine two columns of views where views only resize vertically)
<tiosgz>
otoh i can't recall why i wanted that to be a thing, cos the above use-case isn't very realistic
<leon-p>
I am not sure I can follow your point here
<tiosgz>
maybe for when one grabs a tiled view and makes it floating
<tiosgz>
"I'd like all window properties a WM can manipulate to be double-buffered with a single global commit operation."
<leon-p>
Ah
<tiosgz>
i'm asking if there could be more than one
<leon-p>
The use case you describe should still be possible with that, no?
<leon-p>
because the WM will work like any wayland client: receive event, react, commit
<tiosgz>
possible indeed. might just be that i recall something about floating views where we've talked about splitting transactions into tiled and floating or something like that
<tiosgz>
sorry, it's just that i've got thoughts triggered when a certain topic gets brought up
<leon-p>
my idea was that the WM only initiates interactive pointer driven resize, but that it doesn't actually do the operation
<leon-p>
floating vs tiled as a concept will completely disappear from river, hopefully
<tiosgz>
hm. with a wm similar to current river. one grabs a view. the wm calls pointer resize, but also changes how the other views are tiled.
<leon-p>
that would also still be possible
<tiosgz>
you're right that the pointer resize is a river-internal transaction here, though
<leon-p>
WM recognizes Super-Click on window: requests pointer driven resize for window, rearranges other windows, then commits
<leon-p>
if all states are double buffered, including whether a view is currently pointer-resized, it should work
<leon-p>
although this will allow WMs that can have interactive resizing in layout, so that hypthetical future rivertile may not auto-float the view on resize, but instead change the size of the main area
<tiosgz>
i got how the transaction would go from the beginning. i guess i'll need to think through this more in-depth before i come back here. sorry for the confusion
<leon-p>
no worries. please feel free to share any thoughts on this
<leon-p>
my ideas come from the PoV of already having a pretty clear idea of what I want my WM to do
<ifreund>
dnkl: it would require a pretty good sized redactor. I do plan on doing that eventually but perjaps after updating to the next wlroots version so we can also send the correct size in the first configure rather than 0,0
<ifreund>
wouldn't hurt to have an issue to track that
<dnkl>
ifreund: I'd file them right now, but I see you're still using the GitHub tracker, and I'm not logged in there on my phone...
<ifreund>
yeah no worries, I can do it myself but there's a chance I forget :D
<ifreund>
also on the phone now, hence the typos
traidare has joined #river
traidare has quit [Client Quit]
traidare has joined #river
<dnkl>
figured... 😂
tiosgz has quit [Quit: tiosgz]
lbia has joined #river
lbia1 has joined #river
lbia has quit [Ping timeout: 264 seconds]
itshog has quit [Ping timeout: 246 seconds]
lbia1 has quit [Max SendQ exceeded]
lbia has joined #river
lbia has quit [Max SendQ exceeded]
lbia has joined #river
itshog has joined #river
lbia has quit [Max SendQ exceeded]
lbia has joined #river
<ifreund>
alebastr: you just described the current situation with git submodules exactly, the package manager will only improve things
<ifreund>
and I'll start doing actual releases of zig-wayland, zig-wlroots etc. as well
<ifreund>
LarstiQ: If i wrote @import("wayland") in the build.zig it would not compile because there is no dependency called "wayland"
<ifreund>
if I didn't want the ergonomics of idiomatic zig bindings I could just use @cImport()
<ifreund>
(and not have any zig dependencies)
<LarstiQ>
are the dependencies in build.zig only for other zig modules then?
<ifreund>
leon-p: thanks for the WM protocol issue, it all sounds pretty reasonable and in alignment with what I've had in my head from first glance
<ifreund>
LarstiQ: The zig package manager can download arbitrary tarballs of whatever and expose arbitrary zig modules and compiled artifacts that each package declares to the consumer's build.zig
<ifreund>
in addition, the build.zig of a package can be imported in the consumers build.zig using @import("package-name"), which is what you see happening for zig-wayland
<ifreund>
zig-xkbcommon on the other hand exposes a single zig module called "xkbcommon"
<ifreund>
it could theoretically also vendor and compile libxkbcommon from source, exposing that as an aritfact, but I don't have a use-case for that as I'd rather link the system library
<LarstiQ>
aaah
<LarstiQ>
thanks for the explanation!
lbia has quit [Ping timeout: 272 seconds]
lbia has joined #river
tiosgz has joined #river
<tiosgz>
leon-p: i think i've got a little better idea of what i meant about the transactions
<tiosgz>
turns out that if i paid enough attention to it, i'd realise there's nothing (or very little) the protocol can do
<tiosgz>
it's mostly about what river could behave like (perhaps over-complicated for questionable benefit), so it doesn't matter for the proto design
<tiosgz>
more valid use cases i could think of:
<tiosgz>
per-output transaction when switching tags on all outputs at once (but then you get only per-output perfect frames)
<tiosgz>
two independent (not conflicting) transactions in a row (where the wm doesn't know about the latter in advance) where they can happen concurrently
<tiosgz>
... of which i now clearly see both can happen as a sequence of two commits
<tiosgz>
i did intend it like that initially, but was too unfocused
<tiosgz>
(and what river could do is have a list of changes and apply as many as possible and... nope, it isn't worth it unless everything gets way slower suddenly)
<tiosgz>
rubberducking does help sometimes
lbia has quit [Ping timeout: 272 seconds]
lbia has joined #river
uncomfy has joined #river
uncomfy has quit [Remote host closed the connection]
uncomfy has joined #river
uncomfy has quit [Remote host closed the connection]
lbia has quit [Ping timeout: 252 seconds]
lbia has joined #river
uncomfy has joined #river
uncomfy has quit [Remote host closed the connection]
uncomfy has joined #river
uncomfy has quit [Remote host closed the connection]
uncomfy has joined #river
uncomfy has quit [Remote host closed the connection]
<ifreund>
tiosgz: I haven't followed this IRC discussion closely, but as far as transactions in river go I think there's a refactor that should happen before we move on to wm protocol prototyping
<ifreund>
namely, output state should become double buffered and part of the transaction system
uncomfy has joined #river
uncomfy has quit [Remote host closed the connection]
lbia has quit [Ping timeout: 256 seconds]
<ifreund>
this means we wouldn't commit outputs directly in response to e.g. wlr-output-management changes but rather wait till the next transaction completes and make the required changes while rendering the new frame
lbia has joined #river
<tiosgz>
ifreund: well, the "discussion" was mostly me needlessly complicating everything and leon trying to follow what the heck i'm trying to say
<tiosgz>
but speaking of outputs, looks like what you're talking about would also make it easy to delay first frame after the init has finished, right?
uncomfy has joined #river
uncomfy has quit [Remote host closed the connection]
uncomfy has joined #river
uncomfy has quit [Remote host closed the connection]
lbia has quit [Ping timeout: 264 seconds]
<leon-p>
I'd argue that the WM protocol would also mean the end of init scripts, at least from rivers side. That should be moved to the WM as well.
uncomfy has joined #river
<tiosgz>
the init or the wm's initialisation
<tiosgz>
stil there's a delay between river starting and being fully configured
uncomfy has quit [Remote host closed the connection]
<tiosgz>
s/stil/still/
<ifreund>
yeah, this would allow frame perfection for new outputs by waiting for an ack/commit/whatever from the wm before rendering the first frame
<ifreund>
gotta get 0.3.0 done before we can have fun with this stuff though, too many bugs at the moment :/
itshog has quit [Ping timeout: 252 seconds]
lbia has joined #river
lbia has quit [Ping timeout: 246 seconds]
lbia has joined #river
tiosgz has quit [Quit: tiosgz]
alexherbo2 has joined #river
itshog has joined #river
waleee has joined #river
itshog has quit [Quit: WeeChat 4.2.1]
waleee has quit [Quit: oops]
waleee has joined #river
alexherbo2 has quit [Remote host closed the connection]
_whitelogger has joined #river
waleee has quit [Quit: WeeChat 4.1.2]
alexherbo2 has joined #river
lillian has quit [Ping timeout: 268 seconds]
lillian has joined #river
traidare has quit [Ping timeout: 276 seconds]
leopoldek has joined #river
traidare has joined #river
The_Buhs has quit [Changing host]
The_Buhs has joined #river
traidare has quit [Ping timeout: 252 seconds]
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #river
waleee has joined #river
waleee has quit [Quit: updating system]
waleee has joined #river
waleee has quit [Client Quit]
waleee has joined #river
lbia has quit [Ping timeout: 252 seconds]
lbia has joined #river
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #river
alexherbo2 has quit [Remote host closed the connection]