00:31 <leon-p> not sure if this has been discussed yet, but river handles xdg toplevel states a bit different than sway

00:32 <leon-p> you can test this in mpv

00:32 <leon-p> mpv accepts keybinds not only in the playback window but also the terminal

00:33 <leon-p> when you press "f" for fullscreen in the terminal before the playback window has been created, it will start in fullscreen mode on sway but not on river

00:35 <leon-p> I assume mpv creates the toplevel immediately but takes some time to submit the first buffer. I am not sure the XDG shell specifies what to do if the client request toplevel states in this period.

00:35 <leon-p> I don't think this is a bug, it just irritated me when mpv did not do what I suspected :P

01:06 <edrex[m]> alright, I'm going to reboot and try river+stacktile as my top level

01:15 <edrex[m]> actually, hmm.

01:15 <edrex[m]> doesn't seem like stacktile is working properly. how to debug?

01:15 <edrex[m]> (in a nested river

01:16 <edrex[m]> can I just run it manually to see stdout? should river tell me if a layout client doesn't connect? where does the layout name come from? is that something that the layout generator registers via the protocol?

01:20 <edrex[m]> leon-p: ah, stacktile --inner-padding 0 segfaults

01:20 <edrex[m]> actually with any value

01:22 <leon-p> edrex[m]: huh, it does. Thanks for the report

01:22 <edrex[m]> https://clbin.com/reXhZ

01:23 <leon-p> and yes, you can run stacktile from a terminal. Just make sure no other instance is running already

01:23 <edrex[m]> oops, that's not very helpful without debugging symbols

01:24 <leon-p> edrex[m]: no worries, I can reproduce, I'll have it fixed in a few minutes :)

01:29 <leon-p> edrex[m]: pushed a fix

01:29 <edrex[m]> leon-p: thanks!

01:30 <edrex[m]> river-tag-overlay is really nice

01:30 <leon-p> glad you like it

01:30 <edrex[m]> i wish we as a community could figure out how to make these ultra-minimal tools more accessible.

01:31 <edrex[m]> really elegant configs are possible, but require a lot of sleuthing

01:32 <edrex[m]> leon-p: did you push -f? you can't do that when you have users :P

01:33 <leon-p> accessibility is a very hard problem. Really the only thing I can do as a developer of tool is write a good man page and advertise it once here on IRC and that's it. As soon as you change the program to be more accessible to new users, it looses the simplicity

01:33 <leon-p> edrex[m]: I can do it, watch me :P

01:34 <leon-p> It's a bad habit, but as long as it does not change history, I think it's mostly fine

01:34 <edrex[m]> i'm hopeful tools for mixing/sharing configs will emerge. nix/guix seem promising. things like spacemacs sort of work but miss the point by being monolithic

01:35 <edrex[m]> i had to reset --hard origin/master

01:35 <leon-p> is that really necessary for river? my init is ~200 lines and we don't have modules/libraries/user code.

01:36 <leon-p> edrex[m]: ah I see how that might be annoying. FWIW I only had to -f because the rebase messed up history

01:39 <leon-p> it's a common problem for me, because I use multiple different computers.

01:39 <leon-p> and the last time I worked on stacktile apparently wasn't on this laptop :P

01:39 <edrex[m]> it's just, we dive deep into something and we end up memorizing a lot of things. maybe we don't want our tools to become popular because then we'll have to support them. lots of motivation to keep obscure. there are structural problems with the ecosystem. i think theyre fixable

01:40 <edrex[m]> sorry, OT and not what I should be diving into rn :)

01:40 <edrex[m]> still segfaulting tho

01:41 <leon-p> Well, the stuff I do are mostly simple enough that even with more users I would not have to do any more supporting than I do now

01:42 <leon-p> I operate on the "here is some code, here is some documentation and that is what you get. If you want more, ask _nicely_"-principle, which works well for me and unsurprisingly alienates a few of the more entitled users

01:42 <leon-p> edrex[m]: what? I'll have a look

01:43 <leon-p> edrex[m]: does not segfault for me anymore. Are you sure you installed it?

01:43 <edrex[m]> it's crazy when a project gets a bit popular. the author has to go into hiding to get any work done on it. you just can't have multiple thousands of unwashed chat-savvy users with just 2 or 3 committers doing support. someone ends up working too hard to support all those users

01:45 <leon-p> edrex[m]: that's why I like projects using IRC and man-pages. It scares off 90% of the users who are unwilling to read and spares me a lot of work :D

01:45 <leon-p> my worst nightmare is having a project become popular enough that it's user base consists mostly of r/linux regulars, lol

01:46 <edrex[m]> ah, i thought make install would make, works now. thanks :)

01:46 <leon-p> nice!

02:04 <edrex[m]> oh, i see how the stack works. I like it!

02:04 <edrex[m]> i think that was something I wanted back in awesomewm or xmonad days

02:05 <leon-p> basically stacktile does what rivertile does, but instead of having one main area, it has two and the sub layouts of all three areas can be set individually

02:05 <edrex[m]> leon-p: how about an example set of bindings for stacktile?

02:06 <edrex[m]> i know, it has a lot of knobs, but a starting point would be helpful

02:07 <leon-p> edrex[m]: here is my river init. it is sorted with headings, so you should find it easiely: https://git.sr.ht/~leon_plickat/river-config/tree/master/item/river/init

02:08 <edrex[m]> can I just change rivertile => stacktile in the default bindings, or does stacktile not implement a superset?

02:08 <leon-p> edrex[m]: stacktiles commands are slightly different

02:08 <leon-p> mostly instead of "main" it uses "primary"

02:09 <leon-p> also while rivertile updated to kebap-case for commands, I stayed with underscore_commands

02:12 <leon-p> my advice is to just ignore all the commands for the secondary area for now and start using stacktile like you'd use rivertile. You can add more commands later if yuo have a need for them.

02:14 <edrex[m]> thanks, this is very helpful

02:14 <edrex[m]> wofi doesn't show a frame in sway, but it does in river, why?

02:15 <edrex[m]> i really like how river feels. so much old muscle memory :D

02:17 <leon-p> how many [a-z]ofi's are there now? :P

02:21 <leon-p> anyway, I am off for today, need to sleep

08:27 <ifreund> edrex[m]: what do you mean by "a frame" exactly?

11:55 <leon-p> I think this came up already, but toplevel borders are rendered after xdg pop-ups, meaning that small views with large drop-down menus look a bit weird

12:13 <ifreund> leon-p: that can certainly be changed, would you like to open an issue so we don't forget again?

12:32 <leon-p> ifreund: sure

12:34 <leon-p> oh, so if an xdg-popup is active apparently focusing other views does not work correctly

12:35 <ifreund> leon-p: how so? that seems to work fine to me...

12:36 <leon-p> if a pop-up menu is open, focusing a different toplevel does not results in that toplevel gaining keyboard focus

12:41 <leon-p> a different topic: it might make sense to add the current tag set to the user command event in river-layout, because currently per-tag values are a bit hacky

12:57 <leon-p> the problem is basically that neither the last nor the next layout_demand are guaranteed to have the same tags as when the user command was send

13:36 <novakane> leon-p: did you saw that? It looks interesting for what you did the other day, IIRC you use systemd https://github.com/rvaiya/keyd

14:03 <leon-p> snakedye: yeah I saw it. It could probably solve my problem, but I don't want to add yet another moving part to my system when a problem can be solved with what is already there

14:05 <snakedye> Wrong ping 😅

14:06 <leon-p> oops, sorry

14:06 <leon-p> novakane: ^

14:39 <novakane> leon-p: yeah I get it, and at least it give us an article on your site :P

18:56 <edrex[m]> <ifreund> "edrex: what do you mean by "a..." <- i meant window border but I realized I was mistaken, in that it appears to be a client side thing wofi does (a 2px blue border around the window), and it's present in sway too. interestingly, the bottom border is missing in river though, vs sway, not sure what that's about but it's different

18:58 <edrex[m]> i'm seeing a "ghost" window border that shows intermittently when switching the focused tag. it's the size of a window in the "stacked" area of stacktile's layout, but it's positioned at 0,0 (top left)

19:01 <edrex[m]> it's timing dependent - if I play around with it i can reliably reproduce it by alternating the focused tag with ~1s delay

19:03 <ifreund> interesting, that sounds weird

19:08 <edrex[m]> taking a screenshot makes it disappear :)

19:08 <edrex[m]> something about the draw order for the borders i guess

19:14 <ifreund> edrex[m]: could you open an issue? I don't have time to investigate right now

19:18 <edrex[m]> I'm wondering if it might be https://github.com/ifreund/river/issues/375

19:18 <edrex[m]> I have a bunch of qutebrowser windows open

19:19 <edrex[m]> I think i'll sit on it till there's a fix for 375 and see.

19:24 <ifreund> edrex[m]: Oh, I wouldn't be surprised if it was QT doing something weird. If you happen to be able to reproduce without QT programs it's likely a river bug though

21:48 <edrex[m]> when you set the active window to another tag, river seems to select the MRU window in the current tag set. Is that hard-coded? Used to sway where IIRC it's next window positionally.

21:51 <ifreund> edrex[m]: yes, that is hardcoded and intentional

22:02 <edrex[m]> i find it a little surprising but it's something I can get used to. I can just "paint" the range of windows I want to send first, that's fine

22:05 <ifreund> it's what dwm and xmonad do by default as well iirc

22:06 <edrex[m]> I have an exec wrapper that sets PWD to match the PWD of the active window, in sway. It relies on PID being in the properties returned by sway's get_tree. Any way to get the PID for a toplevel in river?

22:06 <edrex[m]> https://github.com/edrex/dotfiles/blob/master/bin/exec-with-pwd

22:07 <leon-p> I don't think so. Currently the only way to querry information about windows is the foreign-toplevel prot. extension, which does not expose PID

22:08 <leon-p> From the discussions I have followed, the PID<->toplevel relationship is pretty flakey, so I doubt the protocol will ever expose it

22:09 <ifreund> edrex[m]: doesn't foot have some knob that does the same thing?

22:09 <edrex[m]> yeah, i was just trying to find that thread about wanting it in the proto extension

22:10 <edrex[m]> not sure, but i'll have a look. i did like that it worked with editors etc too

22:10 <edrex[m]> i think you linked me to it originally, or at least pointed me in that direction

22:11 <ifreund> edrex[m]: looks like if you configure your shell to emit OSC 7 new foot spawned with the foot keybind (ctrl+shift+n by default) will start with the same working directory

22:12 <ifreund> that's not as universal as what you're describing, but it's something

22:12 <edrex[m]> it's too bad though. i want to be able to write scripts that coordinate different layers of my user environment, and too often there are barriers at abstraction boundaries

22:12 <edrex[m]> thanks

22:13 <leon-p> edrex[m]: there is a lot of this kind of glue missing rn in Wayland, because the big desktops use DBus for these kind of things.

22:14 <leon-p> although I think going forward, automation like this will have to happen in dedicated Wayland clients rather than scripts

22:14 <edrex[m]> maybe some generic clients that can be used from scripts

22:14 <edrex[m]> like lswt etc

22:15 <leon-p> that's the idea

22:15 <leon-p> although lswt is probably pretty bad for scripts, since it only queries data, it does not allow you to set any toplevel states

22:24 <leon-p> ifreund: btw, did you see the issue(s) I created?

22:29 <ifreund> leon-p: yes, haven't had time to investigate though

22:30 <leon-p> no worries,

22:30 <ifreund> (adding a tag argument to the user_command event would certainly be a breaking change though)

22:30 <leon-p> huh, that is unfortunate

22:31 <leon-p> wish I had come up with that earlier

22:40 <ifreund> leon-p: we could make this work without protocol changes by sending a layout demand every time tags are changed even if view_count is 0

22:40 <ifreund> that's a bit ugly though

22:41 <leon-p> yeah I had the same idea but discarded it immediately

22:42 <leon-p> and we really can't just increase the interface version? I was under the impression you could add new parameters that way

22:43 <ifreund> adding new events is non-breaking, you can't add arguments to an existing event though

22:43 <leon-p> i see