GNOME Bugzilla – Bug 166757
Xinerama placement bug?
Last modified: 2005-02-20 22:38:18 UTC
While trying to come up with a patch for bug 166524, I noticed the following code in meta_window_place that looked strange to me: /* if the window wasn't placed at the origin of an empty xinerama, * cascade it onto the current xinerama */ if (placed_on == -1) { find_next_cascade (window, fgeom, windows, x, y, &x, &y); placed_on = 0; } Shouldn't placed_on be set to window->screen->last_xinerama_index or something like that instead of manually set to 0? Granted, this section of code is in a very-last-fallback kind of place so it's not likely to matter much (it's possible no one has ever actually been hit by this problem, if it is in fact a problem), but I was curious all the same. I'll attach a patch that makes the change that I thought was right, but I can't test it or anything...
Created attachment 37224 [details] [review] Change the placed_on fallback xinerama for the case where we want to compare a window that may be bigger than the workarea of the given xinerama to see if we should maximize after placement
Rob, Havoc: Could one or both of you take a look at this and tell me if I just misread the code or if I did spot a bug? Thanks!
Comment on attachment 37224 [details] [review] Change the placed_on fallback xinerama for the case where we want to compare a window that may be bigger than the workarea of the given xinerama to see if we should maximize after placement Makes sense to me. Lots of people have been arguing we should always use current xinerama instead of cascading, but sort of an orthogonal debate.
currently any cascading will always occur on the current xinerama. It goes to other xineramas only if there's room for the window there.
committed.