18:36 <leon-p> huh, so apparently it is still possible to get river confused. I just had an image viewer crash on me and now I can't focus anything on that tag :D

18:37 <leon-p> or, actually the image viewer did not die, apparently it is fullscreen but not rendered?

18:38 <ifreund> hmm, is this on an up to date river version?

18:40 <leon-p> 0.2.0-dev-5cc3d78

18:42 <leon-p> that was my cursor theme patch. I don't think there have been any changes since then in this area

18:43 <leon-p> although I can't reproduce anyway

18:48 <ifreund> leon-p: I actually did fix stuff in this area just after merging that

18:49 <ifreund> be870e05 and 147d9c2f90

18:49 <ifreund> (race conditions, yay!)

18:50 <leon-p> huh, I missed that. That could be it

18:54 <Nulo> River just crashed again :D https://0x0.st/oXw8.txt

18:54 <Nulo> I was away when it happened so no clue what did it (machine locked with a few things open)

18:59 <ifreund> hrm, stack trace doesn't shed much light :/

18:59 <ifreund> Nulo: what river version is this?

18:59 <Nulo> ifreund, commit 79d7775

19:00 <ifreund> I've fixed one crash since then, but it's a race condition around fullscreening so probably not related

19:00 <Nulo> Why is it that all the crashes I trigger are always not reproducible with unhelpful stack traces D:

19:00 <ifreund> I don't know, river hasn't crashed on me like that in like a year

19:01 <ifreund> honestly though, the "unhelpful stack traces" part is wayland/libwayland's fault

19:01 <ifreund> at times like these I start to think the arcan guy is write about libwayland

19:01 <ifreund> s/write/right/

19:05 <leon-p> he certainly has interesting ideas, not sure I agree with all of his solutions though

19:05 <ifreund> through knowledge of libwayland's internals, it seems that this was triggered by a wl_surface.commit request

19:06 <ifreund> Nulo: I think you gave me a very similar stack trace once before, would you mind opening an issue to track this?

19:06 <ifreund> might very well be a wlroots bug, but it'd be worth getting fixed there as well

19:08 <Nulo> https://github.com/riverwm/river/issues/539

19:08 <ifreund> thanks

19:08 <Nulo> I feel like I already opened an issue though..

19:09 <Nulo> Nah, probably confused it with https://github.com/riverwm/river/issues/483

19:09 <Nulo> Which hasn't happened again BTW

19:09 <ifreund> nice!

19:10 <Nulo> A few thoughts about how I use river:

19:10 <ifreund> Nulo: yeah last time you gave me this wl_surface.commit() related stack trace I spent a bit going through the code and found one possible dangling pointer pushed some commit fixing it

19:10 <ifreund> Seems like that was probably not the same bug though

19:11 <Nulo> I feel like I have to have a tag per window, at least in my tiny screen. Because having, for example, a tag with IRC and Telegram in monocle view works, but when I want to see Telegram and Firefox at the same time (say, I'm drag and dropping something from Firefox) I bring IRC along wasting screen space and making it annoying to use

19:13 <Nulo> However, the way river is designed (which I guess is derived from dwm, not sure, never used it) I have to have as many tags as views/windows. But I feel that tags are not the right way to treat it, and instead having a bar with all views with an assigned key (like qutebrowser/foot follow link mode) would work better

19:13 <Nulo> Just a thought, wondering how y'all handle this sort of thing

19:14 <ifreund> Yeah river pretty much just does what dwm does here

19:14 <Nulo> Expanding on that last thing: sometimes I just plain forget in which tag I left a window/view. Some bar could show this info though.

19:15 <ifreund> My bar shows which tags have views on them and which tags are focused, but not any info about what the views are

19:15 <Nulo> My bar works the same way, doesn't really help *for me*

19:15 <ifreund> I pretty much always have my browser on 3, random terminals on 1 and 2, IRC on 7, etc

19:17 <ifreund> you mean like 4-6?

19:17 <tiosgz`> yea

19:18 <ifreund> I usually use those to temporarily stash stuff I had on 1/2 if I switch to working on something else but intend to go back

19:18 <ifreund> It's not a highly thought out system, just kinda what I've ended up doing

19:18 <Nulo> Well, I do that but the things that I have open vary on what I'm doing. Sometimes I'm doing multiple things at once (to be specific: maybe I'm waiting for something to compile or for someone to answer). I try to be consistent where I put things (1: editor, 2: general commands/git, 3: development daemons, 6: browser, 8: IRC..) But it varies. Sometimes I want to have multiple Firefox windows and I dump them in 5, but I might also use 5 for opening Inkscape to look at

19:18 <Nulo> mock-ups

19:19 <tiosgz`> i usually have 1=browser, 2-4=code, sometimes 9=random stuff; other screen 1=chat, 2=music player, 3=msteams

19:20 <ifreund> Nulo: One thing that might help which I want to try out at some point in the future would be a way to fuzzy search open views by app-id/title

19:20 <ifreund> that's kinda blocked on getting a shared tagset between monitors in my mind though

19:20 <ifreund> as otherwise I'm not happy with how focusing the result would work out

19:21 <Nulo> I thought about that! I also think it would be helpful, but I feel like it would be a ton of key presses instead of the "qutebrowser model". I think it's a space to look into

19:21 <tiosgz`> iow... keep that for complete external view mgmt :D

19:25 <ifreund> yep, that's the plan

19:26 <Nulo> Is there no way to get the titles of all views in all tags for a bar to use?

19:29 <ifreund> Nulo: currently there's no way to associate specific views and their titles, etc with tags they are on

19:29 <ifreund> though you can get all the titles through wlr-foreign-toplevel-management

19:29 <Nulo> Sad

19:30 <ifreund> which also can be used to focus arbitrary views, but river will ignore the request if the view is not on the already focused output currently

19:30 <ifreund> so you could implement the fuzzy view search/focus thing for a single output in river's "userland" using wlr-foreign-toplevel-management already I believe

19:31 <Nulo> Ohh interesting

19:31 <Nulo> Is there a Wayland i3bar equivalent? For text-based status bars, kinda wanna build something

19:32 <ifreund> I mean, there's swaybar for the direct equivalent

19:32 <ifreund> there's also https://git.sr.ht/~andreafeletto/levee

19:32 <ifreund> and waybar of course

19:33 <Nulo> Didn't know about levee, and of course swaybar

19:33 <ifreund> someone should really write a lemonbar equivalent thing for wayland

19:44 <Nulo> Why is everything in my system broken, now ls-ing my home directory takes ages. /OT

19:46 <Nulo> https://0x0.st/oXww.mp4 I often stumble upon these kinds of view-moving issues

19:50 <Nulo> ifreund, what would I need to use to focus what I got from wlr-foreign-toplevel-management?

19:51 <ifreund> Nulo: you would make the zwlr_foreign_toplevel_handle_v1.activate request in your client

19:54 <ifreund> Nulo: ah, so what's happening there is that the program didn't take the size river told it to (in this case cause hello-wayland is pretty dumb)

19:55 <ifreund> I don't have a good fix for that yet, it's relatede to https://github.com/riverwm/river/issues/519

20:07 <novakane> ifreund: I'll probably try a zig/wayland lemonbar "soon" now that I'm on point with fonts

20:07 <ifreund> \o/

20:11 <novakane> I'm confident enough with pixman and fcft now, probably should be enough to start something like ths

20:21 <tiosgz`> feels bad that i haven't managed to get buffer allocation & swapping right yet :(

20:50 <leon-p> Nulo: back when I used Sway, I had a keybind to rename workspaces on the fly. I used it aggressively and never lost a window. I plan on bringing that feature back when I'll eventually write my river window manager. Also I'll probably make worspaces behave a bit more like in tmux, but that is a different issue.

20:52 <leon-p> I find that I don't use most of the features of rivers tags often enough to really warrant replicating that. Basically I only need having a window be part of mulitple tags.

21:08 <tiosgz`> ifreund: normally i retest even cosmetic changes, but i've already put my laptop back to where i can't unplug the monitor

21:08 <tiosgz`> is it okay if i just trust that i haven't broken anything?

21:09 <tiosgz`> re #537 ^^

21:12 <ifreund> tiosgz`: sure, no worries

21:17 <ifreund> leon-p: yeah, I'm not 100% happy with just copying dwm's idea of how window management should be done either, making it quicker and easier to iterate on window management features is a large part of why I want to move that stuff outside of river

21:30 <Nulo> ifreund, I made the fuzzy window thing but it doesn't work because river ignores requests outside of the current tag

21:30 <Nulo> Or, the views that are visible

21:30 <Nulo> And I can't manually focus the correct tag as river doesn't tell me in which tag it is

21:34 <ifreund> Nulo: hmm, yeah that's trivial to implement (e.g. https://0x0.st/oXx2.diff

21:34 <ifreund> but it's not clear to me if that's the right way to do it

21:34 <ifreund> maybe it would be better to bitwise and the target view's tags with the currently focused tags instead for example

21:35 <ifreund> which is why I want to boot this decision outside of the compositor so we don't have to have a billion different config options

21:35 <tiosgz`> s/and/or/ ?

21:36 <ifreund> yeah, bitwise or

21:36 <ifreund> also something will go wrong with that patch if activating a view not on the currently focused output

21:37 <ifreund> or maybe not, Seat.focus() handles that

22:28 <Nulo> ifreund, yes, I agree, I don't think river should do it. Although I did notice that it didn't focus them at all in unfocused tags