No knowledge of multiple monitors.

[bbenne10]

Currently, sxlock has no knowledge of monitor geometry. This causes the prompt to be centered across monitors when using two monitors, which is rather ugly. I believe this could be solved in two ways:

1) Allow the user to specify the width/height in which the text is centered. I have implemented this solution in my fork of sxlock, and can issue a pull request if you'd like. Code-wise, this is the simpler solution, but requires user interaction to get right (rather than just "doing the right thing")

2) Use a call to XGetGeometry() to get the width and height of Monitor #0 and center in that.

[lahwaacz]

1) Your current implementation has a disadvantage in that it is not possible to center the text on the output positioned in the right, the coordinates are measured from the left-top corner. You would have to specify offset, but that would mean another two arguments and the solution would not be so simple.

2) I don't see how XGetGeometry() could be used, you would always get width/height of the full screen and not individual outputs.

3) The cleanest solution would be to use the RandR extension and center the text on the primary output (by default, user-specified output could be used).

I was aware of this, but I don't use multiple monitors very often, so it was a low priority issue. Anyway, I'm glad that you've taken interest in this project. Patches for the 3) point are welcome.

[lahwaacz]

I made some basic support for RandR, getting the size and position of the primary output turned out to be pretty easy. But specifying the output by name would be harder, you would have to loop through all available outputs and compare the name. Though I won't work on this in near future, it would be a nice feature. I understand that centering on primary output doesn't suit everybody.

[bbenne10]

Honestly, all I want is centering on the primary. I don't particularly care where the text centers, but I don't want it stretching across screens. I had just begun working on centering on the primary and your code looks about 85% like mine did. For me, this works great.

I just tested your most recent commit, and got a BadRROutput (invalid Output parameter) error since one of my monitors was not marked as primary (thus causing GetPrimaryDisplay to fail and return it's error num - presumably -1 or 0, I've not looked). Not sure if this is a HUGE problem, but it is worth noting that a monitor must now be marked as primary, or possibly using the full screen res if GetPrimaryDisplay fails.

[lahwaacz]

Interesting, I thought there is always a primary output... Now I see the --noprimary parameter in xrandr, so some fallback solution has to be devised (and it can't be the full screen as it leads to the previous behaviour). Maybe use the first connected output?

[bbenne10]

I'd be perfectly happy with the fallback being the first connected. I was under the impression that there would always be a primary as well...and wasn't setting one explicitly >_>

[lahwaacz]

The fallback is now implemented, please test it.