Add support for multiple monitors setup (in i3wm)

[andreykaere]

I opened this PR to close #4 and #5. Since I don't have ability to test the changes myself, I kindly ask other people (especially the author of mentioned issues) to test it out on their systems and give me the feedback (that I am gonna ask) here.

[andreykaere]

Hi! I am working on implementing support for multi monitors setup. I want to know, how do you use it in polybar? Are you using different modules (like ixwindow1, ixwindow2 ...) for different monitors or you're using one module for all monitors? What is more logical and conventional (with how you manage it in polybar) way to do it? What is your opinion on that, @kontroll?

[kontroll]

I have a script that launches the same config/bar for each monitor, so there's only one module definition of each type (be it volume, list of workspaces etc etc) in a single bar definition. The only thing that behaves differently between the monitors is the system tray, which I think is only able to spawn a single instance. I spawn the bars like this:

for m in $(polybar --list-monitors | cut -d":" -f1); do
    MONITOR=$m polybar --reload polybarconfig &
done

Whether or not this approach is optimal, I couldn't say. I scavenged bits of configs from all over the internet, and arrived at something that works and stays out of my way. :smile:

If it's of any help, here's a little bit of output from this computer:

$ polybar --list-monitors
DisplayPort-1: 2560x1440+0+0
DisplayPort-2: 2560x1440+2560+0

[andreykaere]

I mean, the problem is that I can handle displaying two icons at the same time on each monitor. However, if it's basically one module, then I can't really print name of app to both of them in correct way. I am proposing to have two different modules like ixwindow1 and ixwindow2 and in exec put something like path/to/ixwindow <name of monitor>. What are your thoughts on that?

[kontroll]

Ah, got it. The way I use the window title falls completely in line with how a single module definition works out; I value being able to see which window is in focus at all times, especially when a window on one monitor is in fullscreen mode. For me it's not an issue at all, but I can certainly see the value in also having the option to show which window would be in focus on a given monitor.

[andreykaere]

Yes, that's what I am proposing: for each monitor have the ability to show currently focused app on the polybar. However I don't think I can achieve control of which polybar bar to print info on. So as a workaround I am proposing simply creating two modules: one for each monitor. Got it?

[andreykaere]

You know, on the second thought, I think it can work with one module as you do. But it will result in two the same scripts runn at the same time. It's not a disaster, just something that seems strange to me. I really think above is a good option, but it still requires some thinking...

[andreykaere]

Let me know your thoughts, please, if you think it's reasonable solution. Once more, I am proposing to have two modules which look something like that:

[module/ixwindow1]
type = custom/script
exec = /path/to/ixwindow "DisplayPort-1"
tail = true

...

[module/ixwindow2]
type = custom/script
exec = /path/to/ixwindow "DisplayPort-2"
tail = true

I think that's the best we can do to have that behavior.

About integrating it with your script, I would suggest creating two bars [bar/bar1] and [bar/bar2] in which include respective ixwindow1and ixwindow2 module. Then run something like that instead of your usual script (I don't really understand how you run polybar without specifying a bar itself, so maybe it's not 100% correct):

i=1
for m in $(polybar --list-monitors | cut -d":" -f1)
do
    MONITOR=$m polybar --config=/path/to/config "bar$i"&
    $((i++))
done

[kontroll]

That does seem reasonable to me.

[andreykaere]

I mean, I just don't think there is a real way to get rid of this "crutch" ... If you have some thoughts -- I am open to ideas, for now I will implement it this way

[andreykaere]

Hi! @kontroll, check it out now, please. It's not fully ready yet, but I want to know, if you are able to see icons on both of your screens. If you will run into some panic or something, please, post here. Thank you.

[kontroll]

I'm getting some weirdness. :confused: So I've created two bars, and a second ixwindow module, and I'm not getting any config errors. All fine there, I believe.

What happens now is... well, a lot, frankly.

1. Right after launching polybar, no icons anywhere (just like before).
2. After switching back and forth between windows on the same monitor, icons show up (much faster than they did before; did you upgrade the pixel pushing? :wink: )... but there's two of the same icon, and they're both on the same monitor.
3. The offset appears to be wrong, but I didn't do anything with the offset (config wise). If the toml config has been updated then that's why.
4. If I switch to the second monitor I see just a single icon (the leftmost one), still on the first monitor. This icon corresponds to the process on the second monitor.
5. If I then switch back to monitor 1, I get just one icon this time (in the other position), and this icon also corresponds to the correct process.
6. As I keep switching back and forth between the two processes I tested with, on the two different monitors, eventually they both stop showing up anywhere.
7. Continually switching between windows on the second monitor yields the same results as in item 2. Still on the first monitor.

I think this is a pretty comprehensive list of what I've been experiencing in my testing. :smile:

Edit: I installed the module using the _support_multi_monitorsi3 branch.

[andreykaere]

Okay, thank you very much for your comprehensive report of what is going on. Some weirdness can be happening, for now I want to focus on displaying icons on both screens. Let me get you straight, there was not a moment when icon showed up (even for a millisecond) on your second monitor?

And if so, can you provide me with some debug information: Please, pull last commit to your local repo, navigate to the directory ixwindow/wms/i3/src and execute one by one the following commands and tell me what happens when you run each of them: 1) cargo test display_icon1_works 2) cargo test display_icon2_works 3) cargo test display_icon1_by_name_works 4) cargo test display_icon2_by_name_works 5) cargo test screen_num -- --nocapture

[kontroll]

1. The Alacritty icon shows up on monitor 1 (it takes a noticeable amount of time for it to appear).
2. Fail:

   
   Finished test [unoptimized + debuginfo] target(s) in 0.05s
    Running unittests src/lib.rs (/home/ctrl/random/code/ixwindow/ixwindow/wms/i3/target/debug/deps/ixwindow_i3-d801a3c0e32d2fbc)

failures:

---- x11_utils::tests::display_icon2_works stdout ---- thread 'x11_utils::tests::display_icon2_works' panicked at 'index out of bounds: the len is 1 but the index is 1', src/x11_utils.rs:20:19 note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

failures: x11_utils::tests::display_icon2_works

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 14 filtered out; finished in 0.00s

3. Works fine (also appears on monitor 1 after a delay).
4. Also works, exactly as above (same delay, same monitor).
5. I don't know what this is trying to do; it runs very quickly and outputs the following:

running 1 test 1 test x11_utils::tests::screen_num ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 14 filtered out; finished in 0.00s

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

[andreykaere]

Okay, thank you very much. I am gonna need more "testing" like that, because I never worked with this before and I don't have ability to test it myself. Can we chat somewhere else, where you can answer more often. If it's alright with you, of course. I propose to use matrix or telegram:)

[andreykaere]

Please, go to ixwindow/wms/i3/src and run the following:

1. cargo test display_window_on_monitor1_works
2. cargo test display_window_on_monitor2_works

and report what you get. Thank you.

[kontroll]

I'll have to look into those two communication options in that case. But I'm heading to bed right now, so... not today. ;) Anyway...:

1. Big white box on monitor 1.
2. Big white box on monitor 2!

Progress, it seems! :smile:

[andreykaere]

Oh, great, it's working! Thank you very much, will work on that tomorrow, it seems! In that case, communication options are not really that necessary :) Thank you for you patience and colobaration!:)

[andreykaere]

Hi! Icons right now should be displayed on both monitors. I also added showing info and icon at start. Please give me some feedback on that and tell me if icons are actually getting displayed on both monitors.

One bug is expected (for now): icon can disappear on one monitor, while something is changing on another one. I am still looking for a good solution here. Thank you for helping me improve this project!

[andreykaere]

This should fix "destroying icons on both monitors". Let me know how it works for you!

[kontroll]

Very peculiar...! It works fine when I'm switching between windows on one monitor (which makes sense; this is the use case you can test). But if I switch back and forth between two windows on two different monitors, one of three things happens:

1. Both icons show up, as expected.
2. Only one icon shows up.
3. Neither icon shows up.

The preponderance of occurrences favors case 3. I can't think of a reason why this would happen. :thinking:

[andreykaere]

How do you switch between windows on different monitors? Are you switching between desktops or you're switching directly?

What about the titles in all three scenarios? Are they correct?

By the way, what about position of the icon?

P.S. Did you use the latest version of this branch?

[kontroll]

Switching via clicking/selecting workspaces/super+directions all do the same thing. I usually switch between windows using a mix of these methods, as well as specific application shortcuts that sets the focus to a given workspace and window (or start the application and puts it there if it's not running). I think that's an exhaustive list of the way I interact with or select windows/workspaces.

It might be a good thing that you asked me to check the titles; I have been suppressing them all along since it appeared to show the window class (or something), and I didn't think to touch that after I had initially set that up. When I switch to a window and it doesn't have an icon, the title (according to ixwindow) is "Empty". Either way, the title still appears to show the class name (or a similar property) of the window.

Also, I noticed a new thing when I un-suppressed ixwindow generated titles: Sometimes there's a rather significant delay before icon and title shows up. Peculiar! This didn't happen with just the icon visible, for some reason. Furthermore, they both show up at the same time after that delay, for what it's worth.

I assume you somehow changed the way the position is combined and calculated; I had to fiddle quite a bit to get it to align properly again after I mentioned it (I think I did anyway) in a previous message. That's all working fine now though, but I kinda wish I could use decimals (that then get rounded to an int) in the offset. :sweat_smile: Some of my workspaces apparently have titles that's 1 px off from the normal size. It's a very minor thing though, nothing to worry about. It's not something I noticed before, and it's not really something that shows up unless you really, really look closely at the final icon position.

And yes, I always pull the latest code before doing anything. :)

[andreykaere]

Thank you for detailed response! I don't quite understand what's going on here:

When I switch to a window and it doesn't have an icon, the title (according to ixwindow) is "Empty". Either way, the title still appears to show the class name (or a similar property) of the window.

If you could record bizarre things that you see, that would be very helpful!

Also, I noticed a new thing when I un-suppressed ixwindow generated titles: Sometimes there's a rather significant delay before icon and title shows up. Peculiar! This didn't happen with just the icon visible, for some reason. Furthermore, they both show up at the same time after that delay, for what it's worth.

I don't know how often that happens for you. But that's normal behavior, when you focus the given window for the first time (if that makes sense), because program needs some time to retrieve icon. After that it should never happen, because it uses cache. Let me know if that is the case!

I assume you somehow changed the way the position is combined and calculated; I had to fiddle quite a bit to get it to align properly again after I mentioned it (I think I did anyway) in a previous message. That's all working fine now though, but I kinda wish I could use decimals (that then get rounded to an int) in the offset.

Again, didn't really get you here. I didn't change the formula since the first time, I just made it calculating differently on different monitors. About using decimals - I don't know if that's a good idea to have decimals when we're dealing with pixels. And I don't understand why would you need that? You can adjust pixel-wise, how that can be not enough freedom? :)

So, summing up, I would really like to see strange things you described in previous comment (i.e. recording), it can really help me figure out what's going on. Or if you can't provide step by step what you see on both screens when you are switching between windows on different monitors.

[kontroll]

Further mysteries, I suppose. I didn't see the thread panic error text when I was testing earlier. That seems to be blocking the instantaneous icon / title display though.

Anyway, in the clip you see [workspaces] [icon] [ixwindow label] [xwindow label] So as you can tell there's a difference in what ixwindow and xwindow uses for the window name.

https://user-images.githubusercontent.com/4224444/222916331-53c33136-11e3-4416-87b8-280b0c341b8c.mp4

The window that causes the panic is a Vivaldi browser window.

As for the decimals: If I have workspace labels that are 42 and 43 pixels wide, the average would be 42.5, plus/minus some fraction depending on how many workspaces are actually active. If I have 8 workspaces up, with 4x42 + 4x43 pixel width it's a combined width of 340 px. I'm off by 4 pixels if I use a workspace offset of either of those values (8x42=336, 8x43=344 respectively). However, if I can use a 42.5 pixel offset, the inaccuracy is minimized. Obviously this should be rounded up or down to the nearest integer value. But, as I said, it's not a huge thing. The margin of error is tiny, and unless you're looking very closely at it, you will probably not notice it in the first place. Does that clarify what I mean? :smile:

[andreykaere]

Yes, thank you. About decimal offset -- I will work on that after fixing main bug first. If that is not much of a problem for you, could you record the same video, but instead of running script on polybar (disable it), run it with cargo run in src directory.

I tried to reproduce it with vivaldi on my computer -- everything works fine, so, I guess, it's not related to vivaldi browser having weird wm_class or something, but something getting wrong during switching. Thank you!

About difference in output of ixwindow and xwindow -- of course the are different. In fact, I don't really like the input of xwindow, because it's super long. I can add an option for selecting one of these options as a preference. Do you think that's something worth to be considered? Because the idea of using this module just to display icon and the other thing for displaying text seems weird to me and I am eager to fix it.

[andreykaere]

Now it should support floating numbers in gap_per_desk, check it out, please

[kontroll]

It appears to die instantly when I try to switch to a window on a different workspace.

Switching between windows on the same workspace doesn't cause any issues.

[andreykaere]

This should prevent panic. But I am not sure if the behavior will be correct. Give me some feedback, please

[kontroll]

Seems to work fine now, switching between both workspaces and monitors. :+1:

[andreykaere]

So, do you think this PR can be merged?

P.S. What about other things I've mentioned: about how is offset now and about info that is being printed out?

[kontroll]

Offset appears to function very well! As for the info being printed, I'm wondering if that's worth touching upon for me? The current xwindow thing has enough options for me to be satisfied with the output and customizability; the length can be adjusted well enough in that, so for my purposes that's a good enough solution. I'll leave that part up to the feedback of others. :)

Unless there's stability issues, I'd say it looks like things can be merged.

[andreykaere]

Okay, then, I am closing it! Thank you very much for your time and very helpful feedback! Feel free to open new issues if you will notice something weird!

About info: okay, seems reasonable to me, because implementing all these details like controlling length and such is quite tedious and why rewriting xwindow functiononality, if one can just combine them like you did?:)

[kontroll]

why rewriting xwindow functiononality, if one can just combine them like you did?:)

Exactly my thinking. :)