On Thu 17.Sep'09 at 0:10:51 +0200, Carlos R. Mafra wrote:
> I _think_ the problem happens because there is only one loop scanning
> all the windows and setting the vertical and horizontal max. at the same
> time. Perhaps it should do one pass to get the vertical maximumization,
> and then scan everything again to set the horizontal max.
Perhaps the above might even be right, because I tried to reproduce my own
test case from a few hours ago and I couldn't, even though I put
the windows at the same positions.
So maybe that is because the order in which the windows are probed
matters, and now their order is different from before (because
I didn't record the order in which I opened them).
So if that is the case, then the ugly patch below should solve
it, as it is breaking the probing loop into two (it is not
apparent, but this is a bit before the point where the y
intersections are considered)
Does somebody else checked those snapshopts I've sent
and tried to reproduce that bug? I am curious now.
diff --git a/src/actions.c b/src/actions.c
index 1a383f2..c9c8070 100644
--- a/src/actions.c
+++ b/src/actions.c
@@ -474,6 +474,26 @@ static void find_Maximus_geometry(WWindow *wwin, WArea
usableArea, int *new_x, i
new_botton_0 = top_j;
}
}
+ }
+
+ tmp = wwin;
+ while (tmp->prev) {
+ /* ignore windows in other workspaces or minimized */
+ if (tmp->prev->frame->workspace !=
wwin->screen_ptr->current_workspace
+ || tmp->prev->flags.miniaturized) {
+ tmp = tmp->prev;
+ continue;
+ }
+ tmp = tmp->prev;
+
+ /* set the w_j window coordinates */
+ x_j = tmp->frame_x;
+ y_j = tmp->frame_y;
+ width_j = tmp->frame->core->width;
+ height_j = tmp->frame->core->height;
+ botton_j = y_j + height_j;
+ top_j = y_j;
+ right_border_j = x_j + width_j;
/*
* Use the updated y coordinates from the above step to account
--
To unsubscribe, send mail to [email protected].
