Descriptionjonathan.protzenko
2008-01-31 15:26:25 EST
I'm using my laptop screen (1024x768, left) plus an external lcd monitor (1920x1200, right). Both are configured using xrandr --auto then xrandr --... --right-of.
When I try to maximize the terminal on my first screen, it only gets one small fraction of the height, while it correctly uses all the available width. This is quite annoying since I cannot properly maximize my terminal anymore.
Plus, when I un-maximize it, it sometimes (I cannot determine why or when) keeps all the width instead of the previous width.
Concerning the first issue (even if I suspect both are related), some digging through the code got me up to screen.c around line 1492. The area that's obtained by the client_try_configure call is totally wrong (in my case, 311 instead of 768).
for (it = struts_bottom; it; it = g_slist_next(it)) {
ObScreenStrut *s = it->data;
if ((s->desktop == d || s->desktop == DESKTOP_ALL) &&
STRUT_BOTTOM_IN_SEARCH(s->strut, search) &&
!STRUT_BOTTOM_IGNORE(s->strut, us, search))
b = MIN(b, ab - s->strut->bottom);
fprintf(stderr, "Changing b to %d\n", b);
}
the code above prints some 311 height, which ends up as as a 266px height for my terminal (because of the decorations and the top bar, I'm using gnome/openbox btw).
I'm a bit puzzled by this strange behaviour, so I someone with more knowledge of openbox than me could take a look, that'd be great.
I'll try anyway to fix this, but it looks quite difficult to me.
Any help appreciated !
Jonathan
Comment 1jonathan.protzenko
2008-01-31 15:28:46 EST
Created attachment 1653[details]
Screenshot of the bug
The terminal on the left screen was maximized.
Comment 2jonathan.protzenko
2008-01-31 15:31:27 EST
This is not specific to maximizing, btw, newly created windows on the first screen also get an unusually little height (any windows).
Comment 3jonathan.protzenko
2008-01-31 16:17:19 EST
The formula used in the code mentioned above seems correct, but one strut is wrong (height 456 but I don't know where it comes from), there must be something with screen_update_areas in screen.c
Comment 4jonathan.protzenko
2008-01-31 16:22:28 EST
Got it. Changing the line with MIN to MAX like that :
if ((s->desktop == d || s->desktop == DESKTOP_ALL) &&
STRUT_BOTTOM_IN_SEARCH(s->strut, search) &&
!STRUT_BOTTOM_IGNORE(s->strut, us, search))
b = MAX(b, ab + s->strut->bottom);
made it. Can someone confirm this is correct ? (I think this should be changed for the lines above these ones too).
Comment 5jonathan.protzenko
2008-01-31 16:24:20 EST
Still this doesn't take into account the gnome bar at the bottom. I think one of the devs should definitely take a look at this :)
ps : the 450~ strut was the one for my term
do this:
xprop | grep STRUT
and click on the gnome panel.. and see what it says.
maybe it actually is setting a strut that large.
im not able to reproduce it here so far with our test-fake-xinerama, which also makes me think it might be gnome-panel's mistake
Comment 7jonathan.protzenko
2008-02-01 04:45:57 EST
Got it.
_NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 0, 456, 0, 0, 0, 0, 0, 0, 0, 1023
_NET_WM_STRUT(CARDINAL) = 0, 0, 0, 456
That's it. How could I not see this ? Well the MIN was correct, it's just the gnome panel that's unusually high. Is there a way to tweak this with my rc.xml ? I will try to see if I can fix this with gnome panel but any ideas are welcome.
Comment 8jonathan.protzenko
2008-02-01 07:57:04 EST
/* collect the struts */
for (it = client_list; it; it = g_list_next(it)) {
ObClient *c = it->data;
if (!strcmp(c->class, "Gnome-panel") && c->strut.bottom > 450)
c->strut.bottom = 24;
if (c->strut.left)
ADD_STRUT_TO_LIST(struts_left, c->desktop, &c->strut);
if (c->strut.top)
ADD_STRUT_TO_LIST(struts_top, c->desktop, &c->strut);
if (c->strut.right)
ADD_STRUT_TO_LIST(struts_right, c->desktop, &c->strut);
if (c->strut.bottom)
ADD_STRUT_TO_LIST(struts_bottom, c->desktop, &c->strut);
}
here is an ugly ugly hack (that still manages to correct the bug). It's in screen.c, around line 1250. Should I file a bug report to gnome ? Forget what I said about MIN and MAX before, these shouldn't be changed.
Yes, you should definitely file a report to GNOME. :)
They don't in general seem to care much for xinerama in cases where both monitors are exactly the same.. hopefully more input from users can change that.
Putting limits on a strut that are within the screen is a little :/ because there may be environments or cases where it is legit. At least you have a workaround for your own machine for now :)
I'm using my laptop screen (1024x768, left) plus an external lcd monitor (1920x1200, right). Both are configured using xrandr --auto then xrandr --... --right-of. When I try to maximize the terminal on my first screen, it only gets one small fraction of the height, while it correctly uses all the available width. This is quite annoying since I cannot properly maximize my terminal anymore. Plus, when I un-maximize it, it sometimes (I cannot determine why or when) keeps all the width instead of the previous width. Concerning the first issue (even if I suspect both are related), some digging through the code got me up to screen.c around line 1492. The area that's obtained by the client_try_configure call is totally wrong (in my case, 311 instead of 768). for (it = struts_bottom; it; it = g_slist_next(it)) { ObScreenStrut *s = it->data; if ((s->desktop == d || s->desktop == DESKTOP_ALL) && STRUT_BOTTOM_IN_SEARCH(s->strut, search) && !STRUT_BOTTOM_IGNORE(s->strut, us, search)) b = MIN(b, ab - s->strut->bottom); fprintf(stderr, "Changing b to %d\n", b); } the code above prints some 311 height, which ends up as as a 266px height for my terminal (because of the decorations and the top bar, I'm using gnome/openbox btw). I'm a bit puzzled by this strange behaviour, so I someone with more knowledge of openbox than me could take a look, that'd be great. I'll try anyway to fix this, but it looks quite difficult to me. Any help appreciated ! JonathanCreated attachment 1653 [details] Screenshot of the bug The terminal on the left screen was maximized.Got it. Changing the line with MIN to MAX like that : if ((s->desktop == d || s->desktop == DESKTOP_ALL) && STRUT_BOTTOM_IN_SEARCH(s->strut, search) && !STRUT_BOTTOM_IGNORE(s->strut, us, search)) b = MAX(b, ab + s->strut->bottom); made it. Can someone confirm this is correct ? (I think this should be changed for the lines above these ones too)./* collect the struts */ for (it = client_list; it; it = g_list_next(it)) { ObClient *c = it->data; if (!strcmp(c->class, "Gnome-panel") && c->strut.bottom > 450) c->strut.bottom = 24; if (c->strut.left) ADD_STRUT_TO_LIST(struts_left, c->desktop, &c->strut); if (c->strut.top) ADD_STRUT_TO_LIST(struts_top, c->desktop, &c->strut); if (c->strut.right) ADD_STRUT_TO_LIST(struts_right, c->desktop, &c->strut); if (c->strut.bottom) ADD_STRUT_TO_LIST(struts_bottom, c->desktop, &c->strut); } here is an ugly ugly hack (that still manages to correct the bug). It's in screen.c, around line 1250. Should I file a bug report to gnome ? Forget what I said about MIN and MAX before, these shouldn't be changed.