The Unity Panel's window controls and window dragging features should work for the uppermost maximized window regardless of current window in focus.

[David Raid]

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?

[Alex Launi (alexlauni)]

While I agree there is definitely a problem here, it runs the risk of becoming confusing and inconsistant. Adding an ayatana design task to specify what the desired behavior should be.

[David Raid (davidraid)]

I'm glad you agree, I was worried that the reaction would be that others thought it unimportant.

My vision of the perfect default behaviour would be that the indicator-appmenu continue to act as it does, connecting to whatever window is currently selected.

The panel's titlebar replacements (eg, window controls (close, minimize, maximize) and draggability should work only for the uppermost maximized window. As the unmaximized window, even if currently selected, has its own titlebar and does not need duplicate functions in the panel. If the panel is to replace the functions of maximized windows, it needs to only work for the window that is maximized and visible.

The appmenu should be separate from this, as there is no such duplication.

[Dylan McCall (dylanmccall)]

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!

[Paul Sladen (sladen)]

The ayatana-design should be covered by:

  https://bugs.launchpad.net/unity/+bug/661049/comments/8
  "I confirm that the unused (non-menu, non-indicator) space should behave
as a proxy for the titlebar, BUT implementation is up to the Unity team."

There's a whole bunch of bugs that single-click/double-click/drag/right-click don't work as they would on a detached titlebar and they probably want processing as a set. The implementation is of course not fixed, but my hunch is that it should be more about handing the 'default:' case when unprocessed events fall-through and passing those to the Window Manager than trying to pick them off one-by-one and continuously missing odd ones.

[Didier Roche-Tolomelli (didrocks)]

@Paul: the current bug is about the top panel acting on the maximized window only and not the focus one. Nothing to do with your comment.

@Dylan: Thanks a bunch for your work there and helping to make unity better!
As described on the merge request, I would either raise the discussion on the ayatana mailing list, either wait for designer's feedback before deciding to merge such a huge behavior change so close to the release. I think we should discuss all the impact and such (like, if you do that, there is the menu for the focus window which isn't available at all anymore) to take the clever decision with all needed cautious.

[Christian Mackintosh (christian-mackintosh)]

IMO this is a valid point, but it would be very confusing if the titlebar buttons in the panel corresponded to the non-focused window whilst the menu in that very same panel corresponded to the focused window.

I think the best solution might be to adopt Andrea Azzarone's idea and move the menu bar of unmaximised windows into their own title bar: http://www.webupd8.org/2011/02/unity-mockup-menu-integrated-in-window.html

That way the unmaximised, focused window would have its own controls, menu and title whilst the panel would continue to serve as the title bar of the unfocused maximised window, maintaining grabability etc.

[Sam Spilsbury (smspillaz)]

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.
>
...

[Paul Sladen (sladen)]

Christian: To me, the worry about confusion between menu bars and titlebars of focused/unfocused isn't there. My expectation is for the top bar to correspond to the top focused window, since it *looks* like that is the case (the theme and position correspond). The menus give a hint at what confirmation they correspond to aswell. The only ambiguity you have is if there is a maximised application and an identical unmaximised application: but in this case you can't tell them apart anyway since they both just say "Firefox Web Browser".

The disjoint menubar I can cope with... every mid-/late-1990s computer except the RiscOS had it. But all of those system have had the titlebar physically attached, so that's what I'd still expect to happen in this case.

It's like say saying that the indicators should be attached to the currently focused window only. Whereas they are global.

[Christian Mackintosh (christian-mackintosh)]

Paul,

Perhaps I've misunderstood the proposal but if my understanding is indeed correct then I still think it would prove confusing. Let's say you had a maximised firefox window in the background and an focused, unmaximised nautilus window in the foreground. Currently the panel would display the nautilus window title and menu whilst the nautilus window itself has its own title bar with window controls. Now there are problems with this which do need fixing, as the initial bug report outlined, but in terms of interaction with the focused window I think it's pretty clear.

Under this proposal, however, the panel would now contain the firefox window controls right next to the words "File Manager", and on mouseover the firefox window controls would be next to a fairly generic set of menus (File, Edit, View etc.) which could belong to either program. I think this would be highly confusing, users would end up closing firefox when they meant to close nautilus or possibly think that the nautilus menus relate to firefox (though I think the former is the biggest issue).

I think my proposal, as it were, would be the neatest way around this. That way the panel would continue to serve as firefox's title bar with window controls, window title and menus and all the titlebar clicking and dragging functions, and all of nautilus' functions would be provided within its own title bar.

[Didier Roche-Tolomelli (didrocks)]

So, after a talk with the design team, it seems that we would rather for natty focus on fixing this bug: https://bugs.launchpad.net/unity/+bug/723882 which is connected to Dylan's work, but only applied to dragging downward and double-clicking on an empty space.

Dylan? are you interested to make this change for natty from your branch?

[David Raid (davidraid)]

I don't think it's confusing for the panel window controls (and panel dragging abilities as I said when making this bug) to work for the uppermost maximized window when it isn't in focus at all.

In fact if the current window in focus is unmaximized, it will have its own window controls. Since the uppermost maximized window won't have its own window controls (because maximized window decorations are gone) it makes sense for the panel to continue to act as a substitute for them , e ven if it isn't in focus, so that each window has window controls and can be dragged without having to first make the window be in focus.

A program that already acts in this fashion exists, called Namebar. Namebar doesn't add panel dragging abilities but it does show the window title and controls for the topmost maximized window only only one maximized window can be seen at any one time.

I recommend installing this on maverick or Lucid to see how it works. It's behaviour is exactly what Natty should be emulating.

I've attatched a screenshot of how Namebar works, as you can see the focussed window is an unmaximized one, but the panel still shows the name and window controls of the uppermost maximized window, which is an intuitive behaviour well worth emulating.

[David Raid (davidraid)]

It's a shame the menu for unmaximized windows can't appear in their window decorations, eg, their titlebars.

I do agree that the menu could potentially be confusing, it's the main problem with trying to make the panel replace both the menus of every window and the titlebar of the maximized window. They're two separate elements and trying to cater to both could cause confusion when trying to make the behaviour more intuitive.

[Dylan McCall (dylanmccall)]

On Wed, Mar 16, 2011 at 3:23 AM, Didier Roche <email address hidden> wrote:
> So, after a talk with the design team, it seems that we would rather for
> natty focus on fixing this bug:
> https://bugs.launchpad.net/unity/+bug/723882 which is connected to
> Dylan's work, but only applied to dragging downward and double-clicking
> on an empty space.
>
> Dylan? are you interested to make this change for natty from your
> branch?

Ah, excellent. I was thinking it would be good to split this report
into two tasks, since the buttons are a much more aggressive change.
If I understand correctly, the branch as it is satisfies bug #723882.
I'll leave a comment there just to be sure.

Thank you!

Paul: Yeah, the buttons are a trickier thing. We have a funny
confusion between title bars and window menus because this space is
being used so frequently. I think it's important to treat title bars
as physical objects that are directly attached to their own windows
and never go away. People are just used to that. We should be thinking
of the window / application title as attached to the menu, and not to
the title bar. (The title bar is a “title” in name only).

It isn't totally logical, but I don't think anyone right now reads the
title on his Firefox window and thinks “okay, that says Firefox. If I
drag this, I'll be moving the Firefox window.” Instead, they see that
squishy black bar that is physically attached to their Firefox window
and they click it.

On the other hand, buttons seem to carry a different tone. For one
thing, the buttons lead in to the window menu (which has the title).
People also probably think more about window buttons before clicking
them, so there's a real possibility of someone thinking “okay, that
title says gedit, so I am closing gedit” when in fact they are closing
Firefox.

With that said, I get the feeling we're all on the same page but using
slightly different words :)

[Christian Mackintosh (christian-mackintosh)]

Dylan, I think you're right. ;)

To sum up (my position, at least):

1. For maximised, focused windows the top panel functions as a title bar. This behaviour should be consistent even if the window is not focused.

2. Currently, non-maximised, focused windows send their titles and menus to the top panel. If the top panel continues to serve as the title bar of the maximised, non-focused window whilst displaying the title of the focused window, this will be horribly confusing for users. As Dylan said, if users see a set of window controls next to the word 'gedit' then they will naturally assume that those window controls are for gedit.

3. The most reasonable solution appears to be having the titlebar of non-maximised windows display their own menus as in the mock-up I posted earlier. This would keep the panel free for maximised windows to use as a title bar whilst not using any more vertical screen space than currently.

[Launchpad Janitor (janitor)]

This bug was fixed in the package unity - 3.6.8-0ubuntu1

---------------
unity (3.6.8-0ubuntu1) natty; urgency=low

  * New upstream release.
    - crash at the second drag and drop from an unity place (LP: #736704)
    - Compiz crashes with SIGSEGV in nux::GraphicsDisplay::GrabPointer when
      opening the Dash (LP: #737287)
    - Visual Tearing/Rendering Issues with Unity Launcher (LP: #737476)
    - unity-window-decorator crash on unity panel dragout (LP: #740480)
    - unity-panel-service crashed with SIGSEGV in g_type_check_instance_is_a()
      (LP: #694699)
    - compiz crashed with SIGSEGV in nux::BaseTexture::GetDeviceTexture()
      (LP: #692823)
    - the "no result" and "search the web" items need icons (LP: #711199)
    - Resizing with external padding/grab area prevents reaching edge of
      screen (LP: #710356)
    - drag and drop of launcher icons uses microscopic drag icon (LP: #727647)
    - text in places look squeezed (LP: #727799)
    - at-spi-registry consumes most of the CPU and make the system unusable on
      Natty (LP: #729827)
    - migrate_favorites.py crashed with GError in __main__: Bad key or
      directory name: "/desktop/unity/launcher/favorites/app-
      dc++.desktop/type": `+' is an invalid character in key/directory names
      (LP: #737016)
    - Launcher hide state is confusing (LP: #739850)
    - Polish new launcher hide state (part 2) (LP: #740020)
    - launcher icons should expan on super or when entering keynav
      (LP: #741319)
    - Launcher - Dragging a Launcher icon to the Trash should remove the icon
      (LP: #676466)
    - Launcher - Enable dragging and dropping of files & folders to Launcher
      icons (LP: #676549)
    - Dash - Add Dash group header mouseover effect (LP: #689640)
    - unity aborts when you plug in an external monitor (LP: #700757)
    - Keyboard-navigation: focus on launcher remembered (LP: #713340)
    - Launcher Quicklists should always contain the application title
      (LP: #723877)
    - When a maximized window has window on top of it in 'restored state' (not
      maximised) , it is not possible to un-maximized the window by dragging
      the title bar downwards (LP: #723882)
    - When windows open for the first time they should not hide the launcher
      (LP: #723878)
    - UI blocked when expanding a section with more than 2000 items
      (LP: #736059)
    - Change ALT-Tab to bring the target window to the front (LP: #736938)
    - compiz crashed with SIGABRT in __kernel_vsyscall() (LP: #737814)
    - Launcher does not respond to changes in icon theme (LP: #605475)
    - Implement new style scrollbars in Dash (LP: #608124)
    - Closing launcher menu raises window under mouse (LP: #728787)
    - adding url launcher support from the search (LP: #739038)
    - Launcher - Set Launcher 'Hide Animation' to 'Slide only' by default.
      Also introduce subtle fade in effect. (LP: #739567)
    - "Time & Date" settings appears in launcher with empty tooltip
      (LP: #740907)
    - ZeitgeistLog missing implementation of get_property for "connected"
      (LP: #734080)
    - often can't alt-click-dnd to move the focussed dialog (LP: #711911)
    - The Unity P...

[André Oliva (gandreoliva)]

This problems continues in unity-2d.