ifreund changed the topic of #river to: river - a dynamic tiling wayland compositor || https://github.com/riverwm/river || channel logs: https://libera.irclog.whitequark.org/river/
<NickH_> talismanick: how did you end up installing wayland.xml?
snakedye has quit [Ping timeout: 256 seconds]
snakedye has joined #river
waleee has quit [Ping timeout: 260 seconds]
<talismanick> NickH_: doas xbps-install -S wayland-devel
<NickH_> Thanks. I want to add some more documentaion to the readme.
<talismanick> works great btw - nice to have back my bspwm keys
<NickH_> Cheers. Yeah that feature was an absolute must for me when I first started using river.
<NickH_> Was able to implement it very quickly with the help of people here in irc.
<talismanick> If I find how to detect if the program is running in a venv, I might contribute an additional call to auto-generate the protocol and tell the user to reinstall after fetching the .xml files if it doesn't work
<talismanick> (on first invocation)
<talismanick> #python suggested a way of doing that, but said not to use it (some kind of horrible hack, I guess)
<NickH_> I was thinking about shipping the required protocol files with riverwm-utils and then scanning them on install, but didn't yet look into how feasible that approach would be.
<leon-p> so, how is going back-and-forth tags linearily like this useful for you all? I personally just tend to remember where my stuff is (waiting for the day a proper window switcher will work and the day I can configure river to automatically reorder my tags like tmux does, so that they move to fill the "gap" when one becomes empty).
<NickH_> leop-p I have over 20 years of mussle memory for navigating around my workspaces/tags in this way. Not interested in changing.
<leon-p> i see
<NickH_> Also I only have to move one finger from the home row for this.
<NickH_> Missing emty tags was something that sway drove me crazy with.
<leon-p> sway unfortunately isn't missing them in the way I'd like: if you have workspaces 1 and 9 with windows, then you still have to press S-1 and S-9, the last one doesn't automatically get moved to S-2
<talismanick> leon-p: to the extent that I "organize" my desktop around tasks, it's either Firefox tabs (which is its own deal that stays in 1 window) or Emacs buffers
<talismanick> However, I don't always like to switch buffers in 1 screen because that makes the layout inconsistent
<leon-p> tried to do that, but the way I work is just to chaotic. I ended up just having a few scripts to quickly set up working environments, so that I don't particularly care about saving some state
<talismanick> so, in bspwm, for projects with multiple moving parts I wanted to keep open, I "smeared" the buffer displays across several tags/workspaces
<talismanick> and switched linearly back and forth, with explicitly numbered jumps as something of a mental context switch
<talismanick> screen-at-a-time switches between adjacent workspaces/tags beats scrolling
snakedye has quit [Ping timeout: 246 seconds]
<NickH_> I'm adding to the docs for riverwm-utils. Can anyone tell me how to install wayland.xml on arch?
<talismanick> NickH_: give me a moment to check if it's the case, but Arch usually bundles the files other distros would keep in a -devel version into the main package
<leon-p> NickH_: should be in the 'wayland' package
<talismanick> It does
<NickH_> ok, so just: "pacman -S wayland"?
<talismanick> yeh
<NickH_> thanks. Also how is root normally handled on on void and arch. I'm assuing that sudo isn't used by default?
<NickH_> But I guess void and arch users a likely knowledgeable enough to know how to get root without hand holding.
<talismanick> It is. On Void, you can change it out for doas (OpenBSD's minimal, more secure equivalent)
<talismanick> (sudo is default)
<NickH_> Hmm...
<talismanick> weird to think that sudo wasn't yet a standard default by 2008
<NickH_> So for void I should prbably ommit doas and sudo and just put "xbps-install -S wayland-devel" and assume that the user knows what they are doing?
<leon-p> pretty sure arch doesn't pull sudo by default, only if you explicitly install it. And doas is also available these days I think.
<leon-p> I am on a derivative though, can't say for sure
<talismanick> NickH_: yeah, do think that goes for most users who come across river and want adjacent-tag switching though :P
<leon-p> river isn't quite as niche as it used to be, so you can't be too sure
<NickH_> Thanks for you input. I updated the README. https://github.com/NickHastings/riverwm-utils/tree/documentation
talismanick has quit [Read error: Connection reset by peer]
talismanick has joined #river
mon_aaraj has joined #river
<mon_aaraj> hey, I've spoken about a wlroots release earlier and how it provides the scene API, but wasn't that already merged a year ago via https://github.com/swaywm/wlroots/pull/1966 ?
monaaraj has joined #river
mon_aaraj has quit [Ping timeout: 246 seconds]
emersion has quit [Remote host closed the connection]
emersion has joined #river
monaaraj has quit [Quit: WeeChat 3.5]
mon_aaraj has joined #river
mon_aaraj has quit [Read error: Connection reset by peer]
mon_aaraj has joined #river
mon_aaraj has quit [Read error: Connection reset by peer]
mon_aaraj has joined #river
notzmv has quit [Ping timeout: 260 seconds]
mon_aaraj has quit [Ping timeout: 260 seconds]
mon_aaraj has joined #river
lxsameer1 has joined #river
mon_aaraj has quit [Read error: Connection reset by peer]
mon_aaraj has joined #river
mon_aaraj has quit [Ping timeout: 240 seconds]
mon_aaraj has joined #river
snakedye has joined #river
notzmv has joined #river
mon_aaraj has quit [Ping timeout: 256 seconds]
<bw> is it possible to run river as a systemd service?
<leon-p> bw: yes, but not recommended.
<bw> why isn't it recommended?
<leon-p> also it not directly supported, so there is no communication between river and systemd
<leon-p> bw: because you shouldn't run your display server directly as a service.
<leon-p> usually you should have something inbtween, like a display manager or greetd
<bw> what do DEs like gnnome and kde do? do they not run as systemd services?
<leon-p> nope
<bw> i'm using greetd
<leon-p> well, then just start river via greetd, problem solved.
<bw> ok, so then my question becomes, how do i properly "integrate" it with systemd, such that various targets and dependencies are managed correctly by systemd
<bw> like, if i want to run mako as a user service, but have it depend on river
<leon-p> create a river target, then create service unit file for mako and make it depend on your river target, enable the mako service as a user service and use that one systemd-command I can't remember right now to manually enter the river-target (also as user) in your init.
<bw> is it not just systemctl start river.target?
<leon-p> probably
<tleydxdy[m]> <bw> "like, if i want to run mako as a..." <- you don't need to, it starts automatically by socket activation
<tleydxdy[m]> so when something actually wants to send a notification
<bw> tleydxdy[m]: right, but i need to set that up myself. nixos doesn't have a unit for mako
<tleydxdy[m]> sure, it doesn't need to have a dep on river tho
<bw> i know
<tleydxdy[m]> presumably all the stuff you have that sends notification are started after river already
<bw> but there are other things i'd like to start as services, that will depend on river (or some other compositor)
snakedye has quit [Ping timeout: 240 seconds]
snakedye has joined #river
<bw> i also want to put things into systemd slices
<nor[m]> leon-p: "usually you should have something inbtween, like a display manager or greetd" Is this a general recommendation, so just typing `XKBstuff river` into tty isn't recommended either, or is this just about systemd services?
<ifreund> nor[m]: I just run river from a tty, it's the most foolproof way to start it IMO
<bw> i prefer log messages actually go somewhere, not just into the tty where i'll never see them
<ifreund> I pipe them into a file in /tmp
<ifreund> very primitive I know
<novakane> sometimes primitive is the best way
<bw> i've been doing that for a long time. i'm ready to improve things
<leon-p> nor[m]: not in general, only for auto-start. although if someone /really/ wants to run river directly as a service, then you are in luck, because I actually did that quite a while back with sway and here is my old unit file: https://paste.sr.ht/~leon_plickat/f0b37d42b6909dbb4241c79dcb53844acdfcc5d4
<leon-p> very hacky and not recommended, but it works
Guest87 has joined #river
Guest87 has quit [Client Quit]
<kennylevinsen> bw: the systemd user daemon and services it runs is a slave to whatever runs your session, and cannot run the session itselfIt is not suited for running the shell itself.
<kennylevinsen> There's also environment variable handling complexities. GNOME uses a hack where what you log into is a gnome-session thing that then fixes up user services and launches mutter as such, but it's a lot of infrastructure and headache for no gain whatsoever
<kennylevinsen> You can use systemd-cat or whatever to guide output to journald though
<bw> sure, but i still want all the systemd parts to work nicely. here's an example of something that can run as a service under wayland: https://codeberg.org/dnkl/foot/src/branch/master/foot-server@.service.in
<kennylevinsen> And you can run mako and such as super services if you really want to
<bw> i want to make that `wayland-instance@.target` (or something like it) work
<kennylevinsen> Yeah there's a gazillion ways that even that foot server user service is worse and more fragile than the alternative, but I understand your sentiment.
<kennylevinsen> What you would do then is to have a target that your trigger from something started by river. You need that anyway to update WAYLAND_DISPLAY and such.
<bw> it's hard to separate the "i just hate systemd, so everything involving systemd is bad" from "this is actually not something systemd does"
<kennylevinsen> but other river people will need to chime in here, I only know the sway way
<kennylevinsen> bw: I contributed to systemd
<bw> i'm not suggesting you are one of the haters
<bw> just saying there's a lot of that, and it's hard to tell
<leon-p> river doesn't do anything systemd or service related. we just spawn the init process and kill it when we exit, should it still exist by then.
<bw> yeah, and that's 100% fine. no complaints from me
<kennylevinsen> leon-p: yeah in sway the trick is to add a few exec systemctl blah calls to the config to mimic part of the gnome-session stuff. E.g. import-environment and the target trigger
<leon-p> also FWIW, when I say it's not supported, I mean it like that; I am a happy systemd user otherwise
<leon-p> kennylevinsen: I suspect that could be copied 1:1 to river, not perfectly sure though
<bw> kennylevinsen: for example, i *need* to do some of that systemd/dbus environment trickery just to get firefox to not sleep for 60 seconds on startup
<kennylevinsen> Sway also have a "no integration" policy as we believe it can all be handled with configuration and scripts outside the sway codebase, not because we don't want people to use systemd
<kennylevinsen> bw: xdg-portal dbus stuff I suppose. systemctl --user import-environment as the first exec from river should allow that to start properly with dbus service activation. You'll need to follow the xdg-desktop-portal-wlr guide though.
<bw> yeah, that's what i do
<bw> it's just annoying there's all this poorly documented weirdness in the ecosystem
<leon-p> socket activation for the desktop portals was broken at some point though, not sure if it works again, but I right now just launch them directly in my init, which is a terrible hack but works
<kennylevinsen> Yeah sometimes other developers care little about the experience outside gnome and kde and expect us to follow their odd design choices :(
<bw> the portals work for me. not sure if they are socket activated or not. i just have them "turned on" in my nixos config
<kennylevinsen> but we're stubborn. Better documentation is definitely needed, but often it's lacking from upstream stuff (e.g. xdg-desktop-portal, gtk runtime requirements, blah), and we end up having to cover it up in our docs
<bw> fwiw, i've been quite satisfied with your projects
<bw> and leon-p's too
<kennylevinsen> glad to hear :)
<leon-p> yep, I same here :)
<leon-p> if my silly code saves you a minute or two, that's a win in my book
<tleydxdy[m]> does this help?
<bw> one of the next crazy things i want to figure out is how to get greetd/tuigreet enabled for multiple VTs, not just one of them
<bw> tleydxdy[m]: probably. that's something i'm maybe settling on. my concern is it probably won't "stop" the target if the compositor stops, or crashes, or something along those lines
<leon-p> bw: you could catch SIGTERM (?) in your init and stop the target
<bw> yeah, that's what i was going to look into. traps. never used them before
<tleydxdy[m]> if you make it so when river crashes it logs you out then I would think the session will also get killed
<tleydxdy[m]> * think the systemd user session will
<bw> long-term i'm probably still going to want to make my own compositor. maybe some kind of cross between river, kiwmi, and something else, with _explicit_ systemd support
<bw> which seems to be one thing the wayland community has no interest in?
<leon-p> careful: systemd user sessions != DBUS user sessions != wayland sessions != login sessions
<bw> right, i need a better understanding
<bw> but if the documentation exists, it's very scattered
<bw> seats are another thing i don't understand
<tleydxdy[m]> I'm having flashbacks to when I try to figure out gnome-keyring
<leon-p> wayland seats are a simple concept, other seats not so much
<bw> i imagine if i ever tried to do multi-seat, 80+% of stuff wouldn't work the way i expect
<leon-p> depends on what you mean with "multi-seat": Multiple wayland sessions running on the same computer, or multiple users using a single shared wayland session.
<bw> well, seats as i understand them are the latter
<bw> (which is a weird use-case, imo)
<bw> the former *does* sound useful
<bw> and it seems like for the most part, that's really problematic
<bw> (if you want to use systemd, at least)
<leon-p> tbh, I think the first sounds utterly useless, since computers aren't really expsince enough anymore to make that necessary (typing this on a laptop I got for less than 100€), the second one however is pretty useful if you want to group input devices. i.e. have your drawing-tablet work independently from your mouse and keyboard. Or maybe you have two drawing tablets and want to draw together with a friend.
<bw> i mean, my use-case for the first is trying out other compositors without losing quick access to documentation i have open in firefox :P
<leon-p> isn't switching TTYs fast enough?
<leon-p> you can run river on TTY1 and some other compositor on TTY2
<bw> leon-p: that's what i mean, i switch ttys
<bw> that's multiple wayland sessions on one computer...
<leon-p> well, I wouldn't call that multi-seat, what I meant was more like separate wayland sessions with separate input and output devices running all simultaneously
<bw> it's not multi-seat by any definition
<bw> ah, yeah, that sounds kinda useless
<bw> the multi-seat i imagine is two monitors, two keyboard, two mice, two chairs, two people, one desk, one computer
<leon-p> bw: that's what I meant. the different is whether they use the same sessions or two separate ones.
<bw> yeah, and separate sessions sounds questionable. as you said, computers are cheap
<bw> but collaborating...
<bw> huddling around one monitor is not always a great experience
<leon-p> if the client implements multi-seat properly and in a useful way, never tried it though
<bw> right, i have a feeling most don't
<bw> dnkl: where is the `wayland-instance@.target` mentioned in foot's systemd units supposed to come from?
<bw> i imagine that was written with some existing pattern in mind
<dnkl> bw: by the system, I guess. foot's systemd service is a user contribution, that I (can't) offer any support for, as I don't use systemd myself
<dnkl> you might find more information in the PR that added the service
<bw> ok, thanks
<kennylevinsen> Yeah true multi-seat is rare. seatd also only handles single-seat multi-session right now because I haven't been bothered yet with such a rare feature. (The internals are there, but not exposed.)
<kennylevinsen> Wayland multi-seat is honestly also pretty rare to use
<kennylevinsen> Most setups are entirely single-user after all
<kennylevinsen> Even multi-session is rare and mostly used for debugging and such
kraem2 has quit [Ping timeout: 260 seconds]
smo has joined #river
smo has left #river [#river]
<bw> How much of river is boilerplate vs actual river-specific functionality?
snakedye has quit [Ping timeout: 250 seconds]
snakedye has joined #river
<lordmzte> i'd guess that theres very little boilerplate. zig is very good at being boilerplate-free
<ifreund> bw: hard to say, there's a fair bit of generic 2D desktop wayland glue code that will be replaced when we switch to the wlroots scene graph API
<ifreund> I think most of the code is still river specific despite that though
waleee has joined #river
talismanick has quit [Ping timeout: 256 seconds]
snakedye has quit [Read error: Connection reset by peer]
boombim has joined #river
flub has joined #river
<boombim> Hello. Is layout per tag feature already released?
<leon-p> boombim: that needs to be implemented in the layout client. rivertile doesn't do it, some others however do, see the Wiki page for a list of available layout clients
lxsameer1 has quit [Ping timeout: 240 seconds]
lxsameer1 has joined #river
lxsameer1 has quit [Ping timeout: 260 seconds]
lxsameer1 has joined #river
snakedye has joined #river
mon_aaraj has joined #river
mon_aaraj has quit [Remote host closed the connection]
mon_aaraj has joined #river
<NickH_> boombim: If you want something that can be configured to be similar to the default rivertile but with per tag layouts, then stacktile is a good option.
mon_aaraj has quit [Ping timeout: 256 seconds]
<NickH_> It looks a little differnt to rivetile straigh out of the box (has a third "remainder area") but settings can be tweaked.
<boombim> I'm not sure I understand you correctly. May you share some config please?
<boombim> I'm on sway now but I like dynamic wm slightly more
<boombim> However what's a current status of river? Any roadmap?
<NickH_> I launch it with the following options: stacktile --inner-padding 2 --outer-padding 2 --primary-ratio 0.5 --primary-position right --per-tag-config --secondary-count 2 --secondary-ratio 0.6
<boombim> Got it.
<NickH_> acutaIn particulare the secondary count=2 raito=0.66 makes it look like a standard two region layout until you have more than 3 windos in the secondary area.
<leon-p> you can also achieve that by just setting the secondary ration to 0.5
<leon-p> *ratio
<NickH_> I don't want the remainde area to take 50% of the secondary area.
<NickH_> I want the remainder area to be the same size as the other windows. Thats basically what I get with those settings.
<NickH_> So I guess what I actually have is 2 windows in the secondary area, and 1 in then remainder, but it just looks like a normal 3 window secondary without a remainder
<boombim> Sounds totally messed... In sway you can just set any layout to any workspace and that just works
<leon-p> boombim: sure, but that comes at the extra cost of window management being way more manual
<leon-p> you just have to decice what you're more comfortable with
<NickH_> The number of windows in each area and the various ratios can all be changed at runtime with bindings.
<NickH_> Those commanline options just set the default for each tag.
<NickH_> The defualt way that sway treats layouts is complelty brain dead in my option.
<NickH_> Just vomits new views onto the display an makes the user clean up the mess.
<NickH_> s/option/opinion
kindablue_ has joined #river
anjan_ has joined #river
psnszsn_ has joined #river
raiaq_ has joined #river
leon-p_ has joined #river
Ankhers_ has joined #river
kennylevinsen_ has joined #river
andrea_ has joined #river
novakane_ has joined #river
whereswaldon_ has joined #river
dnkl_ has joined #river
coder_kalyan_ has joined #river
bw_ has joined #river
angry_vincent has joined #river
kindablue has quit [Ping timeout: 250 seconds]
kennylevinsen has quit [Ping timeout: 250 seconds]
andrea has quit [Ping timeout: 250 seconds]
Ankhers has quit [Ping timeout: 250 seconds]
anjan has quit [Ping timeout: 250 seconds]
leon-p has quit [Ping timeout: 250 seconds]
voroskoi has quit [Ping timeout: 250 seconds]
bw has quit [Ping timeout: 250 seconds]
dvzrv has quit [Ping timeout: 250 seconds]
raiaq has quit [Ping timeout: 250 seconds]
novakane has quit [Ping timeout: 250 seconds]
psnszsn has quit [Ping timeout: 250 seconds]
dbuckley has quit [Ping timeout: 250 seconds]
angry_vi1cent has quit [Ping timeout: 250 seconds]
dnkl has quit [Ping timeout: 250 seconds]
whereswaldon has quit [Ping timeout: 250 seconds]
coder_kalyan has quit [Ping timeout: 250 seconds]
kindablue_ is now known as kindablue
kennylevinsen_ is now known as kennylevinsen
Ankhers_ is now known as Ankhers
raiaq_ is now known as raiaq
psnszsn_ is now known as psnszsn
whereswaldon_ is now known as whereswaldon
novakane_ is now known as novakane
leon-p_ is now known as leon-p
dnkl_ is now known as dnkl
anjan_ is now known as anjan
andrea_ is now known as andrea
coder_kalyan_ is now known as coder_kalyan
voroskoi_ has joined #river
voroskoi_ is now known as voroskoi
dbuckley has joined #river
dvzrv has joined #river
bw_ is now known as bw
bw has quit [Changing host]
bw has joined #river
talismanick has joined #river
<boombim> I'll try to explain. I want to enable fullscreen on first workspace and tabs on second and plain layout on third. I go to second and change tabs to plain layout.
<boombim> I don't want to care about any predefined config to do such a common things
<boombim> I don't want workspaces with predefined layouts
<boombim> They have to be changeable on the fly
snakedye has quit [Read error: Connection reset by peer]
snakedye has joined #river
<NickH_> Um, you just predefined three layouts that you want by you then say you don't want predefined layouts.
snakedye has quit [Ping timeout: 256 seconds]
snakedye has joined #river
<tleydxdy[m]> river won't do too hot on monocle/tabbed unless you mod the source for you local build
<tleydxdy[m]> it kinda works but is not great
<boombim> To be honest I don't really like tabs. It's just example. I mean I can switch layouts on the fly in sway. Can I do it with river?
<tleydxdy[m]> yes
<tleydxdy[m]> river rely on external program to do the layout, and there's enough information given to implement pertag behavior
<NickH_> You can even switch the layout genator on the fly.
<NickH_> I think the onyl real way to understand how it works right now is to just use it.
<NickH_> Try different layout generators and write one of your own.
<NickH_> Any maybe keep and eye on the the various RPs and Issues on github to understand what direction river is moving in.
<boombim> Cool. I'll try it. BTW I cannot find any useful demonstration of river in text or video
<tleydxdy[m]> you can check out this commit if you just need monocle https://github.com/tleydxdy/river/commit/de8138951a7e1102b29d36f7ec66d8db4f8a0dcc
<tleydxdy[m]> it isn't great but it works
<NickH_> boombim: I don't think any videos exist. There are a couple of blog posts though.
<NickH_> boombim: what distro are you using?
<boombim> The link is broken for me...
<boombim> I use alpine edge.
<boombim> And void sometimes
<boombim> Does it matter?
<NickH_> Ok. Be aware that the version of river packaged on void is very out of date
<boombim> Oh
<boombim> Got it
<boombim> Looks like last release was almost half year ago
<boombim> 5 feb
<NickH_> One of the dependencies needs to be updated. Don't recall which.
<boombim> I use alpine mainly
<NickH_> That version had an anoyting xwayland bug.
<boombim> I don't use any xwayland app :D
<NickH_> Ok.
<boombim> Thanks for aware
<boombim> Does river have roadmap?
<NickH_> Not one that has been clearly layed out as far as I've seen.
<NickH_> But as far as I understan ifeund does have plans.
<NickH_> As I underdstand it, a lot of the window management that is currently in the river itself will be offloaded to external programs.
<NickH_> Much like how the layout generation is done by external programs.
<talismanick> Any opinions here on wtype vs ydotool?
<talismanick> I installed wtype because it has fewer deps, but I'm open to hearing about a workflow with either
<talismanick> (never used xdotool, so the tutorials which referenced it flew over my head)
<talismanick> boombim: I'm using river on Void, but I've been told by two others that it doesn't work on their machines (with different bugs)
<talismanick> Also, if you want to build your own by updating the template in void-packages and building with xbps-src, I'm told you'll also have to pull in more recent versions of the deps (haven't checked myself to verify)
<talismanick> I find it interesting that everyone else is having trouble, though - I've encountered fewer bugs than in bspwm, a "completed" codebase, where I found a grand total of 1 (which others knew about)
<talismanick> (don't remember what it is, only that I looked it up, saw that there weren't plans to fix it, and moved on)
<talismanick> Oh, I see someone mentioned the dependency issue already
snakedye has quit [Ping timeout: 252 seconds]
snakedye has joined #river