Comment 3 for bug 716177

I posted some other rationale for this in bug #717496, which I have now marked as a duplicate.

A big problem with the current behaviour is going to be GIMP. We want people to maximize things like GIMP. That is where Unity really shines. However, because GIMP is a multi-window application, the panel can easily end up with the window controls (and the menu, for that matter) of one of its tool windows. It is all downhill from there. Unity's art assets also play a role here, because the panel looks like a title bar.

I'm still finding my way around Unity (and Compiz, for that matter), but I have a mostly broken (but kind of working) implementation of our fix. I will keep poking at it, but hopefully as it is people can get an idea how this should feel.
That branch is linked to this bug report, lp:~dylanmccall/unity/panel-drag-frontmost-maximized

So, right now my branch adds Activate, Raise and IsWindowVisible to WindowManager and PluginAdapter.
In PanelMenuView, it keeps track of all the maximized windows in a set. (There are a bunch of one-line changes to implement that).
PanelMenuView's OnMaximizedGrab function will run whether the _is_maximized property is true or not.
OnMaximizedGrab now grabs the first visible window of the set of maximized windows. It Activates that window and runs StartMove as usual. Note that this also enables tapping (what looks like) the title bar to bring that window into focus.

Running the above GIMP example, it did what I wanted and I felt happy, though that could have just been residual happiness from my build actually working :)

I know this is pretty broken because Compiz's CompWindow->invisible () method doesn't do what I think it does, so right now my code just grabs the first maximized window it sees, even if it's on a different workspace or behind the front-most one. I'm hoping for something simple that does what I do want (window->z_index(), please?), because doing an elaborate series of checks from here just feels wrong.

The other thing to note is I haven't implemented window buttons or this same functionality for other mouse buttons. Window buttons will want a bit of refactoring, I think, because we would show them whenever _something_ is maximized. Contemplating killing the _is_maximized thing altogether since it is no longer so simple. I have a hunch that anyone doing multi-monitor support is thinking the same thing.

We might not even want the window buttons for this case, though. There is some design to be done!