Created attachment 152144 [details] [review]
Move window to current workspace before activating it

Another option would be to switch to the workspace and active the window on it.

But the current state "just do nothing", feels broken if you are using the shell (not sure how moblin handles that).

(In reply to comment #0)
> So fix it by bringing the window to the workspace before activating it.

I am not happy with doing this, if I place a window on a workspace, I want it to stay there :) Metacity used to do this, a full discussion of how we ended up with the current behaviour can be found in in bug 482354.

> Another option would be to switch to the workspace and active the window on it.

This is what Moblin does.

Created attachment 152214 [details] [review]
Switch to workspace before activating a window on a different workspace

Fix it by switching to the window's workspace before activating it.

Created attachment 152216 [details] [review]
Switch to the window's workspace before activating it

Changed the patch to not change the behavior for transient windows (i.e they get moved to the current workspace like)

I think switching the user's workspace is pretty poor behavior unless the user does something where it is clear that doing it will switch workspaces. And if Metacity (and other window managers) do one thing and we do something else, expecting applications to show restraint in how they use gtk_window_present() seems unlikely to me.

This also isn't really a solution because before the indicated code portion, we have:

  if (XSERVER_TIME_IS_BEFORE (timestamp, window->display->last_user_time) &&
      can_ignore_outdated_timestamps)
    {
      meta_topic (META_DEBUG_FOCUS,
                  "last_user_time (%u) is more recent; ignoring "
                  " _NET_ACTIVE_WINDOW message.\n",
                  window->display->last_user_time);
      meta_window_set_demands_attention(window);
      return;
    }

So, if the app gets focus denied because the user is actively interacting with a different window, we'll get into the demands-attention state *anyways*. The conclusion to me is that we need handling of the demands attention state in gnome-shell. What's I'd like to have as preparation for design work on this is for someone to go through various common applications used with GNOME and look at:

 - When they call gtk_window_present[_with_time](), or otherwise send _NET_WM_ACTIVATE
 - When they end up with the demands-attention set. This can also happen when a window is focus denied when it attempts to show an initial window; it doesn't necessarily mean that the window explicitly tried to activate.

Then we can design something that is based upon what the app is doing from an end-user point of view, rather than designing something that is based upon when the application sends _NET_WM_ACTIVATE.

(In reply to comment #6)
> I think switching the user's workspace is pretty poor behavior unless the user
> does something where it is clear that doing it will switch workspaces.

Like trying to activate a window that is on another workspace?
We currently do the same for starting (already running) apps.

(Trying) to start an app is not "clear that doing it will switch workspaces." .. but this is a different issue.

> And if
> Metacity (and other window managers) do one thing and we do something else,
> expecting applications to show restraint in how they use gtk_window_present()
> seems unlikely to me.

Well other window managers assume that demands-attention isn't ignored (i.e you have a panel or a dock which indicates that).

> This also isn't really a solution because before the indicated code portion, we
> have:
> 
>   if (XSERVER_TIME_IS_BEFORE (timestamp, window->display->last_user_time) &&
>       can_ignore_outdated_timestamps)
>     {
>       meta_topic (META_DEBUG_FOCUS,
>                   "last_user_time (%u) is more recent; ignoring "
>                   " _NET_ACTIVE_WINDOW message.\n",
>                   window->display->last_user_time);
>       meta_window_set_demands_attention(window);
>       return;
>     }
> 
> So, if the app gets focus denied because the user is actively interacting with
> a different window, we'll get into the demands-attention state *anyways*.

Oh! You are right I missed this, but there is a difference between an app that opens a window and tries to steal focus and an app that switches to a window at the users request.

> The
> conclusion to me is that we need handling of the demands attention state in
> gnome-shell. What's I'd like to have as preparation for design work on this is
> for someone to go through various common applications used with GNOME and look
> at:
> 
>  - When they call gtk_window_present[_with_time](), or otherwise send
> _NET_WM_ACTIVATE
>  - When they end up with the demands-attention set. This can also happen when a
> window is focus denied when it attempts to show an initial window; it doesn't
> necessarily mean that the window explicitly tried to activate.

OK, one of those apps is pidgin.
When you have a conversation window open and try to open it again it brings that window to foreground instead of opening a new one (which makes sense), if it is on another workspace the wm sets a demands attention hint and so the user knows that the window is on a different workspace and can change to it.

But when using the shell it ends up like:
1) window is on the same workspace -> fine
2) window is on a different workspace -> clicking on it is a nop (which to the user looks like something is broken); and the user has to switch search for the window by himself. (which does not make any sense at all from a users pov).

I can't think of many apps that do try to do this.

Firefox when configured to always open a new tab instead of a new window when opening urls.

Firefox's download window (when already open it does try to active it instead of opening a new one).

Dunno what spatial nautilus does .. does it reopen the window if you are on a different workspace?

> Then we can design something that is based upon what the app is doing from an
> end-user point of view, rather than designing something that is based upon when
> the application sends _NET_WM_ACTIVATE.

The wm already knows if it has denied the active due to focus stealing prevention so it is not like it is guessing what to do.

Anyway I do agree that ignoring demands-attention like we do now is broken to begin with; but trying to fix this ended up in arguments like "apps shouldn't demand anything". That's why I tried to fix it this way as compromise, but yeah your arguments against it do make sense.

That being said I am out of ideas, so I leave this up to the designers to decide what to do (where what != ignore ;) ).

Argh... I should pay more attention to the design document it says:

-------------

      1. A notification should be displayed in the Message Tray saying something like
          "AppFoo is ready."
      2. A notification should be displayed in the Message Tray saying something like
          "WindowBar is ready."
      3. A notification should be displayed in the Message Tray saying something like
          "TabName is ready."
      4. Should not happen.
      5. A notification should be displayed in the Message Tray saying something like
          "AppFoo requests your attention" before the application window is displayed. If the
          notification is dismissed then the application window is implicitly closed.
      6. A notification should be displayed in the Message Tray saying something like
          "WindowBar requests your attention" before the window is displayed. If the
          notification is dismissed then the window is implicitly closed.
In each case where a notification is displayed, clicking on the notification should display the
application or window.

-------------

So it is already specified how it should be done in gnome-shell.

And it is already being worked on.

Should I close this bug?

*** This bug has been marked as a duplicate of bug 610594 ***