search

LemonBoy / bar

A featherweight, lemon-scented, bar based on xcb
MIT License
1.63k stars 194 forks source link

Multi-monitor geometry fix. #61

Closed jvvv closed 10 years ago

jvvv commented 10 years ago

By waiting until we've gotten the multi-monitor screen width and height before checking for screen fit, we are better able to handle over/under monitor configurations.

jvvv commented 10 years ago

I've tested this pretty heavily. I welcome further testing, especially from those who have resorted to my wip-monitor-opts branch to fix monitor over/under display troubles.

LemonBoy commented 10 years ago

Let's see if it fixes #56 @TrevorBasinger Can you please check if this fixes your problem?

TrevorBasinger commented 10 years ago

@LemonBoy I'd be happy to. I'm away from my desktop until Monday. I'll report back then.

jvvv commented 10 years ago

Added some related cleanup. And fixed my own omission.

TrevorBasinger commented 10 years ago

@LemonBoy, Issue #56 still persists.

EDIT: I've noticed you haven't merged into master yet. That may have been my problem... Let me test using the code in this pull request.

TrevorBasinger commented 10 years ago

Okay, after compiling @jvvv's master branch, some things look different. Before, when I would run bar without any additional params, I couldn't get it to fill both monitors. That problem seems to be solved.

When I run with bar -d -g 2560x20+0+1080, it only fills about half of the bottom monitor. I suspect this is more of a problem with my X11 config.

jvvv commented 10 years ago

Try it with 2560x20+1920+0. That was how figured it (though I may have done so mistakenly). I will look into making it work with the -g option you used, since it's a sensible approach.

jvvv commented 10 years ago

Damn, that commit breaks x offset handling. Bide on testing that.

Edit: I've removed the commit I'm referring to here. For now, I'm sticking with the syntax I suggested. I need find a clean way to implement the syntax you were using to achieve the same thing, without breaking anything else (obviously). There's nothing technically wrong with the syntax you used, it's just not as easy to place the bar using it. I haven't given up, it's just a setback.

Would you test using the x and y offsets I suggested? I'd really appreciate it, as I think this could still be a valid fix for your issue and perhaps implementing monitor aware y_offset handling on my todo list.

TrevorBasinger commented 10 years ago

@jvvv Hey, I'm sorry I'm just now able to give you some feedback.

Using your master branch, bar -d -g 2560x20+1920+0 runs the bar across the top of my (bottom 2560x1440) screen.

http://imgur.com/xUyWqSS

jvvv commented 10 years ago

Cool, thanks for the heads up. No worries from me about the date of the feedback: life happens. LemonBoy has merged these changes, so I think you would be best served to follow his master branch. When I have time, I'll try to get y-offset to give this same layout since it seems the intuitive way for it to work. Thanks again for your input and testing; much appreciated.