Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

-g flag/dimensions bug #147

Closed
neeasade opened this issue Oct 7, 2015 · 9 comments
Closed

-g flag/dimensions bug #147

neeasade opened this issue Oct 7, 2015 · 9 comments

Comments

@neeasade
Copy link
Contributor

neeasade commented Oct 7, 2015

Hi,

I'm under the assumption that the -g flag argument is in relation to the xroot window, and believe I'm having an error.

you can see it here: https://u.teknik.io/rpgWbi.png

I'm trying to launch lemonbar on the middle monitor, using lemonbar -g 1080x32+1920+0 -p.

with an x offset of 1920, shouldn't lemonbar be on the middle monitor, as 1920 is the width of the left monitor? The 0+0 point is being set to what is really 1920+0.

output of xrandr | grep " conn"

DisplayPort-0 connected 1080x1920+1920+0 right (normal left inverted right x axis y axis) 477mm x 268mm
HDMI-0 connected primary 1920x1080+0+472 (normal left inverted right x axis y axis) 477mm x 268mm
DVI-1 connected 1920x1080+3000+472 (normal left inverted right x axis y axis) 477mm x 268mm
@neeasade
Copy link
Contributor Author

neeasade commented Oct 7, 2015

Alternatively I can use the @jvvv fork which includes named outputs and just loop through the xrandr outputs using 0+0 as the point of relevance for the screen I'm targeting. I will be using that method until #127 gets merged.

I do see that you are sorting the monitors here. You are sorting them by increasing x and y offset values yes? which is why the middle portrait monitor gets the point of reference for geometry flag?

@neeasade
Copy link
Contributor Author

neeasade commented Oct 7, 2015

This bug does not seem to effect xinerama setups - another user has helped provided a screenshot with xinerama in a similar configuration: https://u.teknik.io/aZNSBM.png. you can see at the left he has the middle monitor raised, yet is able to launch lemonbar with the same flags I could and have it work as expected(-g flag values in relation to xroot window). I will do the same test with my monitors in the same landscape config when home today.

dump of that uses xrandr | grep " conn":

HDMI-0 connected 1920x1080+0+264 (0x1c1) normal (normal left inverted right x axis y axis) 531mm x 299mm
DP-2 connected 1920x1080+3840+264 (0x1c1) normal (normal left inverted right x axis y axis) 598mm x 336mm
DP-4 connected primary 1920x1080+1920+0 (0x1c1) normal (normal left inverted right x axis y axis) 598mm x 336mm

@LemonBoy
Copy link
Owner

LemonBoy commented Oct 8, 2015

monitors are sorted by coordinate, I don't get what the problem is.

@neeasade
Copy link
Contributor Author

neeasade commented Oct 8, 2015

The issue is in the first screenshot I launch lemonbar at 1080x32+1920+0 but it shows up at 1080x32+840+472.

@neeasade
Copy link
Contributor Author

This is kind of interesting - alignment is also affected, though I guess that's somewhat expected (aligns related to the monitor lemonbar dimensions from): https://u.teknik.io/vWFGKr.png

@neeasade
Copy link
Contributor Author

The issue is fixed for me(geometry matches xroot window) if I change the monitor sorting to be done only by x coordinates - but I can see this might interfere with say, two monitors on top of each other or weird other settings. will continue to mess with it.

same call from initial screenshot: https://u.teknik.io/YwMeJr.png

diff --git a/lemonbar.c b/lemonbar.c
index 065ecd6..7c0041e 100644
--- a/lemonbar.c
+++ b/lemonbar.c
@@ -784,9 +784,9 @@ rect_sort_cb (const void *p1, const void *p2)
     const xcb_rectangle_t *r1 = (xcb_rectangle_t *)p1;
     const xcb_rectangle_t *r2 = (xcb_rectangle_t *)p2;

-    if (r1->x < r2->x || r1->y < r2->y)
+    if (r1->x < r2->x)
         return -1;
-    if (r1->x > r2->x || r1->y > r2->y)
+    if (r1->x > r2->x)
         return  1;

     return 0;

edit:
okay I can see how sorting by all coords makes sense, because of a case like this: https://u.teknik.io/C32nEI.png

maybe some logic can be in place like height of a monitor in relation to its y coord with the sorting? still messing.

@neeasade
Copy link
Contributor Author

okay, so this needs more thorough testing, but changing the sort function to the following allows for geometry relating to the xroot window on both my setup and setups with monitors vertically set:

diff --git a/lemonbar.c b/lemonbar.c
index 065ecd6..d949ae8 100644
--- a/lemonbar.c
+++ b/lemonbar.c
@@ -785,9 +785,16 @@ rect_sort_cb (const void *p1, const void *p2)
     const xcb_rectangle_t *r2 = (xcb_rectangle_t *)p2;

     if (r1->x < r2->x || r1->y < r2->y)
-        return -1;
+    {
+        if (!((r1->y + r1-> height) > r2->y))
+            return -1;
+    }
+
     if (r1->x > r2->x || r1->y > r2->y)
-        return  1;
+    {
+        if (((r1->y + r1-> height) > r2->y))
+            return 1;
+    }

     return 0;
 }

edit: Nevermind, this doesn't sort correctly for the weird case with https://u.teknik.io/C32nEI.png.

@neeasade
Copy link
Contributor Author

Okay, I was making that harder than it had to be - here's what I ended up with, that covers the -g flag in relation to the xroot window correctly with both my setup and the ▄█ monitor arrangement, along with an all landscape setup.

diff --git a/lemonbar.c b/lemonbar.c
index 065ecd6..a75ae07 100644
--- a/lemonbar.c
+++ b/lemonbar.c
@@ -784,10 +784,15 @@ rect_sort_cb (const void *p1, const void *p2)
     const xcb_rectangle_t *r1 = (xcb_rectangle_t *)p1;
     const xcb_rectangle_t *r2 = (xcb_rectangle_t *)p2;

-    if (r1->x < r2->x || r1->y < r2->y)
+    if (r1->x < r2->x || r1->y + r1->height <= r2->y)
+    {
         return -1;
-    if (r1->x > r2->x || r1->y > r2->y)
-        return  1;
+    }
+
+    if (r1->x > r2->x || r1->y + r1->height >= r2->y)
+    {
+        return 1;
+    }

     return 0;
 }

@neeasade
Copy link
Contributor Author

closing, merged.
#150

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants