waleee-cl has quit [Quit: Connection closed for inactivity]
yyp has joined #river
danyspin97 has quit [*.net *.split]
dominikh has quit [*.net *.split]
mmurd has quit [*.net *.split]
hspak has quit [*.net *.split]
Edd[m]1 has quit [*.net *.split]
anthony25 has quit [*.net *.split]
travankor has quit [*.net *.split]
novakane[m] has quit [*.net *.split]
edrex has quit [*.net *.split]
samhsmith[m] has quit [*.net *.split]
danyspin97 has joined #river
voroskoi has quit [Ping timeout: 240 seconds]
ammen99 has quit [Ping timeout: 240 seconds]
Bonicgamer[m] has quit [Ping timeout: 244 seconds]
dominikh has joined #river
mmurd has joined #river
hspak has joined #river
ifreund_ has quit [Ping timeout: 268 seconds]
entenel has quit [Ping timeout: 268 seconds]
travankor has joined #river
anthony25 has joined #river
ammen99 has joined #river
samhsmith[m] has joined #river
voroskoi has joined #river
novakane[m] has joined #river
Bonicgamer[m] has joined #river
edrex has joined #river
ifreund_ has joined #river
ammen99 has quit [Ping timeout: 240 seconds]
Bonicgamer[m] has quit [Ping timeout: 240 seconds]
novakane[m] has quit [Ping timeout: 240 seconds]
ifreund_ has quit [Ping timeout: 265 seconds]
samhsmith[m] has quit [Ping timeout: 268 seconds]
voroskoi has quit [Ping timeout: 268 seconds]
edrex has quit [Ping timeout: 240 seconds]
yyp has quit [Ping timeout: 264 seconds]
yyp has joined #river
Edd[m]1 has joined #river
entenel has joined #river
ifreund_ has joined #river
Bonicgamer[m] has joined #river
ammen99 has joined #river
novakane[m] has joined #river
voroskoi has joined #river
samhsmith[m] has joined #river
edrex has joined #river
yyp has quit [Quit: bye!]
yyp has joined #river
leon-p has joined #river
yyp has quit [Quit: bye!]
yyp has joined #river
yyp has quit [Quit: bye!]
yyp has joined #river
pkill9 has joined #river
<pkill9>
hi, is River stable enough for daily use?
<yyp>
probably is unless you want advanced input settings
<leon-p>
current git master hasn't crashed for me in a long time, so probably yes
<pkill9>
nice
<pkill9>
how does this views and tags system work?
<leon-p>
at least if you mean that kind of stability. If you mean the other kind, than you should expect breaking changes considering we are pre version 1.0
<pkill9>
I haven't used dwm but I'm interested
<pkill9>
yea I mean it not crashing
<yyp>
pkill9: riverctl(1) man page explains it much better than I could ever do
<leon-p>
ok, so you have on single global list of views (wayland term for toplevel windows) per output
<leon-p>
each view has tags, which is a bitfielf, like f.e. 10010
<leon-p>
each output also has tags
<leon-p>
if the outputs tags OR'd with the views tags is true (meaning at least one of the resulting bits is 1), the view gets displayed
yyp has left #river ["bye!"]
<pkill9>
my understanding is, a view is similar to a 'workspace' from most other tiling window managers, is this correct?
<leon-p>
Or to use common words: Tags are effectively arbitrary groups of windows. A window can be part of multiple such groups and multiple groups can be active on one output at once
<leon-p>
nope
<pkill9>
except instead of being given a list of windows, it's given a list of tags
<pkill9>
ok
yyp has joined #river
<leon-p>
forget workspaces when using river
<leon-p>
A view more or less is a window.
<pkill9>
ah ok
yypnc has joined #river
<pkill9>
does that mean the view gets filled with a window? so you can save layouts of views?
<leon-p>
nope
<pkill9>
ok lol
<pkill9>
i'll look up a demo of dwm
yypnc has quit [Remote host closed the connection]
<leon-p>
view == window, more or less, it does not get filled with it. view is just a Wayland term of what X calls windows
<pkill9>
ok
<leon-p>
and you can not save layouts. Layouts get auto-generated.
yyp has left #river ["bye!"]
<pkill9>
is it possible to enable multiple tags at the same time?
<ifreund>
indeed
<pkill9>
nice
<pkill9>
gonna try running it sometime
<ifreund>
regarding stability: river should ideally never crash no matter what you do and master hasn't crashed on me in a long time
<ifreund>
fixing crash bugs is pretty much the highest priority thing for a wayland compositor IMO
<ifreund>
now the exact features river provides are definitely not stable, so expect those to change
<leon-p>
seems to be c-import related. which distribution are you on?
<ifreund>
you're missing libevdev headers
<ifreund>
probably need the libevdev-devel package or whatever your distro's equivalent is
leon-p has quit [Ping timeout: 264 seconds]
leon-p has joined #river
<pkill9>
ahh i didn't even read the top, thanks
<pkill9>
im on guix
<pkill9>
oh hmm i have libevdev
<pkill9>
I added libevdev-1.0 to beginning of include path as that's where it is in th package
<yyp>
Does `pkg-config --cflags libevdev` work?
yyp has left #river ["bye!"]
<pkill9>
oh, the problem dissappeared *shrug*
<pkill9>
i got it compiled \o/
<pkill9>
and running
<ifreund>
nice :)
<pkill9>
could you show all windows of a given class?
<pkill9>
nice i see there is a set-focused-tags command
<pkill9>
does river add the current focused tag to a window when the window is first created?
<ifreund>
the currently focused tags yeah
<pkill9>
nice
<pkill9>
so you can see where the window came from
<pkill9>
e.g. if i have 'chat' tag focused, and click a link in quassel, and open new browser window, it gets tagged with chat
<ifreund>
yup, that's what I would expect
<pkill9>
is there a way to automaticlaly sewt tags for certain classes of windows
<pkill9>
s/sewt/set
<pkill9>
?*
<pkill9>
all this will make everything easier
<ifreund>
nope not yet, though that's certainly planned
yyp has joined #river
yyp has quit [Quit: bye!]
yyp has joined #river
yyp has quit [Quit: bye!]
yyp has joined #river
waleee-cl has joined #river
<pkill9>
a good workflow turns your laptop into something akin to a powerful book
<leon-p>
meh, zero boot time beats 20s boot time, so for some things I'd prefer the book :P
<ifreund>
20s? you need to drop that systemd crap :P
<leon-p>
actually, void with runit on that laptop was about 5s slower, so...
<waleee-cl>
clearlinux boots extremly fast, but I think some of the checks are disabled
<waleee-cl>
(^ with systemd)
<leon-p>
the fastest I got was with some homebrewed init I found online once
<leon-p>
but that still used the shell, which makes it a bit slower than it could be
<leon-p>
I suppose to get a fast init you'd need to have the config in binary format.
<leon-p>
but to be fair, a better ramdisk may also help :D
<pkill9>
I find playing a game in steam it freezes the output, and then I switch to another tty and back and it unfreezes, then it freezes soon again, it says xwayland support is experimental though
<pkill9>
what needs to be done to make it work better?
<ifreund>
that sounds strange, I'm not sure why that would happen
<leon-p>
probably the same output-freeze bug that's already known?
<ifreund>
oh yeah, that one I've been hoping will evaporate when I finally implement damage tracking
<pkill9>
actually i think it might not have anything to do with xwayland, it was just more noticeable, it did freeze when I was just using 'foot' terminal
<leon-p>
do you use multiple monitors, by chance? In my experience the bug does not trigger with only a single output.
<pkill9>
no i don't
<leon-p>
interesting
yyp has quit [Ping timeout: 264 seconds]
yyp has joined #river
yyp has quit [Client Quit]
<ifreund>
what graphics hardware/driver? I have yet to reproduce this once on my RX580/amdgpu
<pkill9>
intel hd3000 (thinkpad x220)
<pkill9>
i think it's hd3000
<pkill9>
integrated intel graphics anyway
<Bonicgamer[m]>
Just found out that the set_region signal inside of wlr.PointerConstraintV1 is actually supposed to be void.
<pkill9>
can you set xkbmap options to swap caps and ctrl?
<pkill9>
found an env variable for it
<ifreund>
Bonicgamer[m]: indeed, just pushed a fix
<ifreund>
pkill9: yeah, the XKB_DEFAULT_* environment variables mentioned in river(1) are the best way to do keyboard config currently
<pkill9>
steam's window has a limit to how small it can get in river, whereas in sway it squashes down
<pkill9>
how can this be changed?
<leon-p>
No idea what sway does here, but river respects a windows size constraints
<leon-p>
so if the steam sets the minimal size of its window, river will never make it smaller than that
<pkill9>
i guess sway just ignores the minimal size
<leon-p>
possibly
<leon-p>
or, considering steam is probably going through XWayland, we may be using the wrong size constraints. On X there are tons of them for some odd reason.
<pkill9>
it does cut it off too, so maybe the application gets the minimal size, but the window cuts it off
<pkill9>
so the window thinks it has the minimal size
<leon-p>
either way, resizing a window smaller than it's constraints is not supports and will probably never be supported. if a windows constraints are impractical, that is a bug in the application and should not be worked around in the compositor
<leon-p>
s/supports/supported/g
<leon-p>
note that if the window cuts off, its application-internal. River renders the buffer as-is