10:57 <isti115_> Hi! 👋

10:58 <isti115_> I was wondering whether anyone else here is using a mulit-monitor setup.

10:58 <isti115_> I can't seem to get the hang of the tags workflow with several outputs.

11:53 <leon-p> isti115_: what problems are you facing?

12:38 <ifreund> I use multiple monitors fwiw, one rotated vertically and one horizontal

14:25 <isti115_> I'm constantly fumbling around when looking for something. I feel like there's a lot of potential in the tag system, but in order not to get lost I find myself mostly keeping one window on one tag on one output and not utilizing it at all.

14:27 <isti115_> This way when I want to reach something I first need to switch to the given output and then activate the given tag. (e.g. checking my emails means going to my right side monitor [I have four: center, left, right, top] and switching the tag over.)

14:29 <isti115_> I know that several issues have already been mentioned on GitHub as well, such as having a window moved can result in it disappearing if the given tag is not active on the target output and such. (Also, the focus stays on the source of the movement, which is often undesirable for me, but I know that I could probably script this.) I might try submitting some patches if I can sort some problems out.

14:33 <isti115_> I usually figure out my own workflows and don't try to copy someone else's setup when it comes to productivity, but with river I couldn't find my grasp so far as easily as with e.g. Sway or Hyprland, where the regular "workspace" approach meant that I could just press a single key combination and for example see my emails instantly. On the other hand I feel like Sway is kind of stuck because it has

14:33 <isti115_> reached feature parity with i3, while Hyprland's develompent is kind of a mess. (I have a small accepted PR there, but am not that motivated to continue contributing as the project feels very chaotic.)

14:35 <isti115_> On the other hand I feel like the direction river is taking is a good one, and I also really appreciate the language choice of Zig, which is much more modern. Yesterday was the first day i actually wrote any of it (I'll submit an issue regarding loading keyboard layouts from files soon), but I already fealt much more convenient writing it rather than C (Sway) or C++ (Hyprland).

14:37 <isti115_> So all in all, I'm looking for advice / expedrience on what for example, you keep on your monitors and how do you utilize tags across them, @ifreund.

14:40 <isti115_> (I have already read the development example in the README with documentation, code and running app, but I have enought monitors to spread those all out at the same time and have communications on the fourth one.)

14:42 <isti115_> Some of the other "categories" that I have had with separate workspaces previously would for example include music, time tracking, 3d modeling, system monitoring, version control, etc.

14:47 <ifreund> isti115_: my vertical monitor is usually just music (always on the same tag) or documentation/something else I need open while doing some task on my main horizontal monitor

14:47 <ifreund> I tend to always have my terminals/editors on tags 1/2 on the main monitor, firefox on 3/4, IRC on 7, that kind of thing

14:55 <isti115_> So essentially the "main" monitor behaves like the example described in the README and the side ones have more static roles. 🤔

14:56 <isti115_> I might try that approach and see if I can maybe start building on top of it.

14:56 <isti115_> Thanks for the answers! :)

14:57 <isti115_> I have submitted the issue regarding keyboard layout loading: https://github.com/riverwm/river/issues/869

14:58 <isti115_> Nothing urgent, as I have it working properly for me right now, but if you'd like to have this functionality merged (I saw that you have marked it as a TODO previously) I'd be happy to clean it up and submit a PR, I'm just not happy with a workaround I had to employ, see the issue for details.

14:59 <ifreund> Hmm, I think that TODO was just about the zig-xkbcommon binding tbh, I didn't know how best to handle the libc FILE type

15:00 <ifreund> doesn't xkbcommon have a way to load a keymap from an in-memory buffer?

15:00 <isti115_> Yes, but I mean, there's not much use to the binding without it being utilized anywhere though. 😉

15:01 <ifreund> The simplest thing is likely to read the file in to a buffer using the zig standard library and use that other xkbcommon API (assuming I'm correct and it exists)

15:02 <ifreund> RE multi-monitor stuff again, In the long term I'd like to move handling of tags outside of the compositor process into layout generators (or let's be real, "window managers" at that point)

15:02 <ifreund> I'm not entirely satisfied with having to manually manage tags across outputs in this way, I just copied it from dwm in the early days of river as it is simple and works well enough

15:02 <ifreund> it feels a bit too manual though in a way, in the same sense that river's tiling is dynamic I'd like to try making the distribution of windows across outputs similarly dynamic

15:03 <ifreund> yeah there's xkb_keymap_new_from_buffer()

15:04 <isti115_> Yes, I'm just checking that out as well right now, but I guess that in that case we'd need to handle the `include` statements ourselves.

15:05 <isti115_> RE multi-monitor stuff: Great, I'm looking forward to trying other layout generators and see what they can come up with in terms of tag management if this gets implemented! :)

15:05 <ifreund> isti115_: what "include" stuff do you mean?

15:06 <isti115_> My xkb config is split up into multiple parts that are included from one "main" file.

15:06 <isti115_> TBH, I'm not sure how those imports are resolved.

15:06 <isti115_> So far I thought that it was relative, but that might actually not be the case. 🤨

15:07 <ifreund> isti115_: I just took a peek at the xkbcommon source code and the only difference between the two functions is that the FILE variant mmaps the file before processing the buffer

15:07 <isti115_> YAY!

15:08 <isti115_> I'll just rewrite it using either the buffer or string variant and submit a PR.

15:08 <ifreund> also, it doesn't look like the rules stuff is used when using an explicit file. Perhaps the CLI needs some more consideration

15:09 <ifreund> i.e. keymap -file foo.txt -layout de

15:09 <ifreund> the -layout has no effect given your current patch, and I think is meaningless in general if loading from a specific file

15:10 <ifreund> I think a separate `riverctl keymap-file /path/to/foo.keymap` is probably the way to go

15:12 <ifreund> er, I forgot what the command was, s/keymap/keyboard-layout/g

15:12 <isti115_> That's what I was about to suggest too.

15:13 <isti115_> I just didn't initially want to take the effort to create an entirely separate command.

15:13 <isti115_> But I'll look into the codebase and see how it's done.

15:14 <ifreund> It's nothing hard, just a bit of boilerplate

15:14 <ifreund> not particularly pretty, but in my defense I hadn't been writing zig for very long when I came up with it years ago xD

15:15 <isti115_> Solving this without `xkb_keymap_new_from_file` will also be better, as it doesn't need changes to submodules.

15:17 <ifreund> yeah, can't wait to get rid of submodules when zig's package manager is ready

15:18 <isti115_> While you're here, I might ask one more question: I have encountered some visual glitches while toggling fullscreen windows. I have narrowed it down to the position of the windows being updated before they are resized, thus flashing in their original size at their new positions. Should I look at rivertile or river itself for fixing this?

15:20 <ifreund> river for sure, though be aware the bug will be in what's likely the trickiest part of river's code

15:21 <ifreund> if you open an issue with steps to reproduce and whatnot I'll make sure to have a look before the 0.3.0 release :)

15:21 <isti115_> Thanks, I will do that then! :)

15:22 <ifreund> if you want to learn how the code works, the place to start reading is probably Root.applyPending()

16:24 <leon-p> IMO handling windows and tags and multiple monitors might already get a lot more ergonomic when we eventually can use window switchers

16:25 <leon-p> what's needed for that is someone reviewing and merging my wlroots PR, a wlroots release and my unique view ID PR