Bar is wrapping around instead of filling

[TrevorBasinger]

I googled around and searched existing issue and I couldn't find evidence of this problem anywhere else. Maybe here someone can help me.

http://i.imgur.com/4FcUQvp.png

My monitor setup is 1920x1080 on top of a 2560x1440. The screenshot is somewhat misleading since it is a rectangular. If I try to set the bar for anything larger than 1920px in width it will wrap around to the middle of my screen.

I'm just trying to get it to run across the full length of the 2560x1440 monitor on bottom.

I've tried with and without the -d flag also. I'm sorry if I'm not giving enough information, I really don't know what would be the most helpful in diagnosing this.

I'm running on the most current version of the master branch.

[jvvv]

LemonBoy, I am fairly certain that the -m option I added in my wip-monitor-opts branch will allow the user to decide which monitor to display the bar on when there is an over/under output configuration like in this issue and in one other before.

[TrevorBasinger]

@jvvv +1

Works flawlessly for me now. I tried everything I could think of manipulating bar/master with the -g argument. @jvvv's branch did the trick.

[LemonBoy]

The code that creates the monitor chain should take into account setups with stacked monitors, it shouldn't be hard but it'd be a pain for me to write as I don't have two monitors.

@jvvv your patch is fine but I didn't merge it because I wanted to fix this problem properly some day :)

[jvvv]

On Tue, 06 May 2014 06:49:23 -0700 Giuseppe notifications@github.com wrote:

The code that creates the monitor chain should take into account setups with stacked monitors, it shouldn't be hard but it'd be a pain for me to write as I don't have two monitors.

@jvvv your patch is fine but I didn't merge it because I wanted to fix this problem properly some day :)

---

@LemonBoy I'm not pushing to have this merged. I think I that didn't explain an other reason why I added the '-m' option in my branch. I run into cases where, depending on the xorg driver (e.g. nouveau vs nvidia proprietary drivers) or perhaps even different video cards, I find that the ordering of monitors may differ from the left to right pattern used to sort them. In at least one case, the middle monitor of three was desired to be the primary monitor (monitor #0) even if it is geometrically not located at 0x0+0+0. With my branch, the option reads: '-m 1:0:2', strange as that my sound, but it allows for the user to specify that the order may be different than what can be assumed when looking at X or even Y values. It just happens that this also makes it easier to configure for over/under monitor situations. I think that you may be right that there is probably be a better way to handle all of these cases, so I have no problem looking at my branch as a bandaid on the issue.

[LemonBoy]

The monitor ordering is just used when selecting the current monitor using the S switch, I don't understand why would one change it manually. After all it's just a matter of writing

%{S1}Center%{S0}Left%{S2}Right

instead of

%{S0}Left%{S1}Center%{S2}Right

unless I've completely mistaken the point of your modifications.

[jvvv]

On Wed, 07 May 2014 12:12:29 -0700 Giuseppe notifications@github.com wrote:

The monitor ordering is just used when selecting the current monitor using the S switch, I don't understand why would one change it manually. After all it's just a matter of writing

%{S1}Center%{S0}Left%{S2}Right

instead of

%{S0}Left%{S1}Center%{S2}Right

unless I've completely mistaken the point of your modifications.

---

You may be right in the use case I described... I will play around with it.

[jvvv]

@LemonBoy You were correct about changing the input to fit the monitor layout. I had forgotten about this because my wip-monitor-opts branch hid the details. Working on a cleaner fix for the over/under monitor layout unmasked the issue to me. Using an array variable and some indirection in my input script was an easy way to handle it. Thanks for your suggestion.