© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
35a32c5
(Get the code!)
+ * There used to be a lot more logic here to handle the rare special
+ * case of maximizing a window whose hints say it is too large to fit
+ * the output and choose a different one. However that logic was a bad
+ * idea because:
+ * (1) It's confusing to the user to auto-magically move a window
+ * between monitors when they didn't ask for it. So don't.
+ * (2) In the worst case where the window can't go small enough to fit
+ * the output, they can simply move it with Alt+drag, Alt+F7 or
+ * expo.
I'm a little skeptical that this is actually the correct solution, and in fact it reintroduces the regression it was trying to solve.
The problem r2775.2.3 was trying to solve was that maximizing a window on a monitor where there was no room for it (eg, the monitor was smaller than the actual window size). In that case, the "next best" solution was to go to the next monitor.
Was bug 751605 about this behaviour specifically? Or was it about a general problem where windows may occasionally maximize over the wrong monitor (and its possible to maximize over both).
Having a window maximized on a monitor where the entire window is made not visible as a result is a really bad situation to get into IMO. First of all, the constrainment code is not really designed to handle that situation and so what you end up with is a window that tends to jump up and down on that monitor on input as the constrainment code tries to get it within the monitor bounds. Second of all, we can't assume that all users know about alt-drag or even the workspace switcher. When the window titlebar is thus made invisible because it is offscreen, the user is effectively not able to get the window back into its original state. That's an even more buggy state to get into because instead of doing something that might initially seem against the user's intention, you've essentially gotten them into a situation they can't get out of.
Reading the comments of bug 751605 it seems like the /real/ gripe is with the fact that the grid plugin displays the window maximization preview on the first monitor and then the maximization happens on the second. I think, just brainstorming a little that there are some better solutions to this problem:
a) Don't allow maximization of windows that might be bigger than one of the available monitors
b) Allow maximization of windows when they are already on the monitor that they can be maximized on (though this could be a little tricky to implement - and could look a bit weird if a window suddenly gains a maximize button as a result of moving it between the monitors)
c) Display the grid preview in the place where the window is about to go.
Is it possible that we can consider those alternatives? Trust me - if you've ever seen what happens when you maximize a window to a smaller size then its minimize size the result is really really bad.