ifreund changed the topic of #river to: river - a dynamic tiling wayland compositor - https://github.com/ifreund/river - channel logs: https://freenode.irclog.whitequark.org/river/
snakedye has quit [Ping timeout: 240 seconds]
leon-p has quit [Quit: leaving]
_whitelogger has joined #river
waleee-cl has quit [Quit: Connection closed for inactivity]
gspe has joined #river
gspe has quit [Quit: gspe]
gspe has joined #river
yyp has joined #river
betawaffle has quit [Ping timeout: 240 seconds]
betawaffle has joined #river
skuzzymiglet has joined #river
<skuzzymiglet> does clicking on a window in river make it floating?
<skuzzymiglet> sometimes I left-click on an mpv window and it floats
<skuzzymiglet> but not in the center of the screen
<ifreund> skuzzymiglet: if you move or resize a window with the mouse it will start floating
<skuzzymiglet> what triggers a resize by default?
<ifreund> skuzzymiglet: the default config script uses Mod + Left Click to move and Mod + Right Click to resize
<skuzzymiglet> which Mod?
<ifreund> what ever one you set in your init script? Mod4/Super what the default one uses
<skuzzymiglet> hmm
<skuzzymiglet> windows-right drag does nothing for me (qutebrowser at least)
snakedye has joined #river
<ifreund> well, what's in your config file?
<skuzzymiglet> cf7b245c944eced1ad4edbbadc8
<skuzzymiglet> broken
<skuzzymiglet> nvm
<skuzzymiglet> ^
<ifreund> skuzzymiglet: well you didn't create bindings for move/resize so of course it does nothing :P
<skuzzymiglet> seems mpv is doing its own thing then :)
<yyp> Yeah, mpv handles moving internally. I haven't tested this on river yet but on Sway it moves even without holding resize modifier
<yyp> *move/resize modifier
<ifreund> indeed, that works in river too
<ifreund> I'm not sure if I like that...
<skuzzymiglet> `mpv --no-window-dragging`?
<skuzzymiglet> seems to work for me
<ifreund> indeed
<ifreund> I could just ignore move requests from clients
<ifreund> I personally would find that a more enjoyable user experience
<yyp> ifreund: please don't do that, at least by defaulf
<yyp> I really like mpv's dragging mechanism
<skuzzymiglet> yeah that could be confusing if it's the default
<ifreund> yeah, sigh
<yyp> Maybe just add an option to block it
<ifreund> I'm not going to do anything just yet because I have bigger fish to fry :D
<skuzzymiglet> I'm getting this error building master
<skuzzymiglet> ~/code/clone/river (master) zig build -Drelease-safe -Dxwayland --prefix /usr install
<yyp> That's fine, I might try to work on this
<skuzzymiglet> ./build.zig:41:45: error: expected 2 argument(s), found 1
<yyp> For me it built just fine
<ifreund> skuzzymiglet: you need zig 0.7.1 not master
<yyp> Installer river-git from aur
<skuzzymiglet> I'm on void :)
<skuzzymiglet> zig does change a lot from release to release
<ifreund> the zig package in the void repos should work fine
<yyp> Just like rust :0
<ifreund> yyp: the difference is that zig isn't 1.0 yet while rust is...
<ifreund> post 1.0 zig should be extreemly stable
<skuzzymiglet> ifreund: do you use zigup or just stick to 0.7.1?
<ifreund> skuzzymiglet: I build from source
<skuzzymiglet> and manage versions manually?
<ifreund> i have zig and zig-git in my path for different versions
<ifreund> zig-git is master, zig is 0.7.1
leon-p has joined #river
entenel[m] has joined #river
exception has quit [Read error: Connection reset by peer]
<yyp> For something that's <1.0 such compatibility issues are understandable
<yyp> Anyway, Zig looks like a pretty good langauge
<leon-p> regarding mpv moving itself: The problem is that clients requesting move is currently directly hooked up to the moving mechanism, which makes views float if they are tiled. think this could be solved more nicely if we had some sort of drag threshhold.
<leon-p> ifreund: have you had a change yet to look at the transactions in river-layout? I am pretty sure that's the only blocker right now.
exception has joined #river
gspe has quit [Quit: gspe]
gspe has joined #river
skuzzymiglet has quit [Ping timeout: 240 seconds]
<ifreund> leon-p: I haven't yet, but I should get to it today. I've been having fun working on the zig AST memory layout rework this weekend
<leon-p> I heard zig is moving away from llvm. Is it related to that?
<ifreund> not directly, though this is part of the self-hosted compiler
<ifreund> basically it just making the parser and ast generation faster
<ifreund> if you're curious on the details: https://github.com/ziglang/zig/pull/7920
snakedye has quit [Quit: Ping timeout (120 seconds)]
waleee-cl has joined #river
gspe has quit [Quit: gspe]
entenel[m] has quit [Quit: authenticating]
entenel[m] has joined #river
entenel[m] is now known as entenel
entenel has left #river ["User left"]
entenel has joined #river
entenel has quit [Quit: authenticating]
entenel has joined #river
gspe has joined #river
entenel- has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
snakedye has joined #river
yyp has quit [Quit: have a great day]
snakedye has quit [Quit: Connection closed]
yyp has joined #river
<ifreund> leon-p: I'm going to merge this log PR and then rebase yours on to master
<ifreund> then I'll see what I can do about transactions and view destruction
ifreund has quit [Read error: Connection reset by peer]
ifreund1 has joined #river
exception has quit [Read error: Connection reset by peer]
ifreund1 is now known as ifreund
exception has joined #river
ifreund has quit [Ping timeout: 272 seconds]
ifreund has joined #river
ifreund has quit [Quit: WeeChat 3.0]
ifreund has joined #river
Guest75279 is now known as dominikh
yyp has left #river ["have a great day"]
yyp has joined #river
gspe has quit [Quit: gspe]
gspe has joined #river
gspe has quit [Quit: gspe]
<leon-p> just rebased river-layout against master
<leon-p> quite like the scoped log import
<ifreund> oops, I'd already done that locally but forgot to push it to your branch
<ifreund> leon-p: I'm currently cleaning up a few things with the layout code that are easier to just implement than to explain in a review (and fixing some minor bugs), then I will get the transaction/destruction issues tracked down
<leon-p> sounds good
<leon-p> are there any major things you had to change?
<ifreund> not really, just cleaning up some error handling and UB :D
<ifreund> and obsessing over details
<ifreund> hmm, 1000ms is pretty high for the layout demand timeout
<leon-p> well, it is an arbitrary value
<ifreund> we don't want to freeze the frame for a whole second waiting for a borked client to respond though
<leon-p> what would be a good timeout value? Maybe 500ms?
<ifreund> that's still really long, we use 200ms for transactions currently which is also quite high
<ifreund> I think 100ms wouldn't be unreasonable
<ifreund> we can tweak this later though