Created attachment 154535 [details] [review]
[Overview] Don't activate workspace when more than one window is open

Comment on attachment 154535 [details] [review]
[Overview] Don't activate workspace when more than one window is open

reviewing the patch to get it off the patch queue, but this needs ui-review before being committed

>+                                            if (this._metaWorkspace.list_windows().length <= 2) {

you should look at this._windows.length instead, and you need a comment explaining why "2" (because you're counting the desktop window too).

Created attachment 155489 [details] [review]
[Overview] Don't activate workspace when more than one window is open

Fixed up patch

I think we talked about this on IRC but for the record.  This seems like a nice change.  The primary goal of the Workspace view is to pick windows.  Picking a workspace is only a side-effect of picking a window.  It is unnecessarily costly to miss clicking on a window and have an unwanted result.  So, this sounds like a good solution to me.

I'd add that in the event that we remove icons from the desktop we may also want to extend this to cover workspaces without windows as well.  But for now there is still a reason to "pick" empty workspaces.

Comment on attachment 155489 [details] [review]
[Overview] Don't activate workspace when more than one window is open

Pushed as 2016e08

I believe this needs reconsideration.

I have first used gnome-shell today, so my thoughts could be representative of how a new user responds to the new desktop. Also, I primarily use OS X, so my thoughts could be biased through how this is done on OS X.

First of all, the approach OS X and gnome differs in displaying the workspaces is different in that the primary aim in os x is choosing the workspace while here you claim that it is selecting the windows. However, the fact that the first separation the user sees is at the workspace level suggests that primarily we are selecting workspaces here. Otherwise, you could list the window previews from all the spaces with no distinction.

So, being unable to select a workspace is frustrating. Being able to select an empty one introduces an inconsistency. So it is like two mistakes in succesion.  It should be either all or none, the user shouldn't be expected to think: here i have apps so i can't select the workspace or here I have an empty space so I can select it.

I dpn't know what the optimal solution is however maybe I can suggest some workarounds. First of all, disabling selecting an empty space is out of consideration. Current situation is good. Otherwise one should drag to a disabled space to enable it, which would be very counterintuive.

Then, if we still disable selection of the background in nonempty spaces, then the background should be dimmed. This. Is how OS X does this. When one enables the spaces view, if one chooses to see the window previews ordered the background is dimmed so the user knows it can't be selected.

Another option is to reenable selection of the background. This would make the behavior consistent. To overcome the issue the bug reporter reported, we could implement safety regions around windows, so that clicking to a small area out of the window still counts as having clicked inside the area.

(In reply to comment #6)
> I believe this needs reconsideration.
> 
> I have first used gnome-shell today, so my thoughts could be representative of
> how a new user responds to the new desktop. Also, I primarily use OS X, so my
> thoughts could be biased through how this is done on OS X.

Hi,

Well you come with expectations you had from an other system (OS X) so everything that is different from OS X seems weird / strange to you at first, you should use the shell for some days before judging its concept (i.e you have to get used to it).
 
> First of all, the approach OS X and gnome differs in displaying the workspaces
> is different in that the primary aim in os x is choosing the workspace while
> here you claim that it is selecting the windows.

Well the primary goal here *is* to select windows.

> However, the fact that the
> first separation the user sees is at the workspace level suggests that
> primarily we are selecting workspaces here. Otherwise, you could list the
> window previews from all the spaces with no distinction.

No, workspaces are used to group windows, just showing all windows without distinction would render the whole workspace concept useless.

> So, being unable to select a workspace is frustrating. Being able to select an
> empty one introduces an inconsistency. So it is like two mistakes in succesion.
>  It should be either all or none, the user shouldn't be expected to think: here
> i have apps so i can't select the workspace or here I have an empty space so I
> can select it.

Well what does selecting a workspace actually mean?
Selecting an non empty workspace would result into selecting the focused window on said workspace, so how is this different from selecting the window directly.

We currently changed it that it only selects the workspace when there are *no* windows on it (not one as this bug suggests), so it is not really inconsistent
(when there are windows you can select them, when there aren't there is not much to select so you basically go to the desktop on this workspace).

> I dpn't know what the optimal solution is however maybe I can suggest some
> workarounds. First of all, disabling selecting an empty space is out of
> consideration. Current situation is good. Otherwise one should drag to a
> disabled space to enable it, which would be very counterintuive.

Yeah disabling it for empty ones would be indeed bad.

> Then, if we still disable selection of the background in nonempty spaces, then
> the background should be dimmed. This. Is how OS X does this. When one enables
> the spaces view, if one chooses to see the window previews ordered the
> background is dimmed so the user knows it can't be selected.

This one would make sense, as it would make the windows (which are mostly bright), stay on a dark background and therefore easier to spot. 
Needs input from the designers though.

> Another option is to reenable selection of the background. This would make the
> behavior consistent. To overcome the issue the bug reporter reported, we could
> implement safety regions around windows, so that clicking to a small area out
> of the window still counts as having clicked inside the area.

This would just make it confusing ... as you'd have to "hunt" for working vs. non working spaces.

Created attachment 162404 [details]
Screenshot of OS X Expose with Dimmed Background

Notice how the unclickable background is dimmed, and the window under the cursor is glowing (blue).

OK, I agree that the most plausible solution is dimming the background in nonempty workspaces. I don't have my mac with me, so I'm attaching a screenshot I have found on the web showing how OS X does this. I don't remember if this is the behavior in the latest case, I may get some screenshots if you like from my mac later on.

As the screenshot shows, one additional enhancement is to glow the window the cursor is on, that might be implemented as well.

Also, on a second thought, I also agree that the slight inconsistency might not create too much confusion for users as by default, there is only one space, and probably users with more than one space are more computer savvy and won't be confused by the current decision.

D'oh I forgot to reopen the bug.

I'm not sure why the bug has been reopened but yeah having the background be dimmed slightly seems like a good idea.  New bug?

(In reply to comment #12)
> I'm not sure why the bug has been reopened but yeah having the background be
> dimmed slightly seems like a good idea.  New bug?

Having discussion in a closed bug seemed odd to me; but yeah this should really be a separate bug.

Closing again; Ustun please file a new bug.

OK, I have filed a new bug for dimmed background and glowing windows:

https://bugzilla.gnome.org/show_bug.cgi?id=620433