Comment 7 for bug 716177

On Tue, Mar 15, 2011 at 10:53 AM, Dylan McCall <email address hidden> wrote:
> 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.

::invisible () checks if the window is not mapped as isViewable or is
offscreen. To get the actual stacking order use screen->windows ()

>
> 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!
>
>
> ** Branch linked: lp:~dylanmccall/unity/panel-drag-frontmost-maximized
>
> --
> You received this bug notification because you are a member of Unity
> Bugs, which is subscribed to unity in ubuntu.
> https://bugs.launchpad.net/bugs/716177
>
> Title:
>  The Unity Panel's window controls and window dragging features should
>  work for the uppermost maximized window regardless of current window
>  in focus.
>
> Status in Ayatana Design:
>  New
> Status in Unity:
>  Confirmed
> Status in “unity” package in Ubuntu:
>  Confirmed
>
> Bug description:
>  I love that the Unity Panel allows you to drag and unmaximize a
>  maximized program as if it were really the titlebar, but when
>  selecting another, unmaximized window, you can no longer do this
>  because the panel is 'connected' to the current window in focus.
>
>  While I agree that the Global menu applet should change to whatever
>  window is currently in focus, it is much more efficient for the window
>  controls and panel-titlebar dragging to be connected to the uppermost
>  maximized window.
>
>  Eg, I maximize Firefox and then open an Empathy chat window. I drag
>  the chat window to the side of the screen, letting the Grid plugin
>  half-resize it. I then move the cursor to click and drag the Firefox
>  window to the other side of the screen, but I cannot do this because
>  the panel is now connected to Empathy and not Firefox.
>
>  Is there a way to make only the window title and global menu shift to
>  the current window in focus and keep the window controls and panel
>  'grab-ability' working for the uppermost maximized window?
>

--
Sam Spilsbury