I wanted to add that the reason why I prefer this behaviour is because, when working on a workspace, it's very disturbing to be moved away from this workspace for no apparent reason.

(In reply to comment #0)
> I have tried using the middle-click, but it seems to open a new instance in a
> new workspace (not the current one).

Ctrl-click should do what you want.


> Would it be possible to set default action to opening a new instance in the
> current workspace if there is no window of the said application in the 
> current workspace?

Ultimately that's for the designers to decide, but I don't think so - it would require users to switch to the correct workspace before using the dash for window switching. Having multiple windows of the same application (well, terminals - people only seem to do it with terminals) spread across multiple workspaces is not the primary use case.

> 
> Ctrl-click should do what you want.
>

Thanks for the tip, it does indeed.
 
> Ultimately that's for the designers to decide, but I don't think so - it would
> require users to switch to the correct workspace before using the dash for
> window switching. Having multiple windows of the same application (well,
> terminals - people only seem to do it with terminals) spread across multiple
> workspaces is not the primary use case.

Yes, I understand that it's pretty much a question of preference. In my case, when I'm working on a workspace, I find it very distractive to be "thrown away" of the workspace I'm working on because I forgot that the app I need is already opened elsewhere. And, actually, it happens very often, with temrinals, firefox windows (when I need to quickly search for information about the job I'm doing on this particular workspace), nautilus windows (to browse to a document that I need in this context), gedit windows (to edit a document relative to the context of this workspace) etc... Actually, I think the only cases when clicking on a launcher should move me away from my current workspace is when I click on a long-running background app, like Evolution or Rhythmbox, and that's where Ubuntu's app indicators come very handy, but that's a bit off-topic...

> 
> Ctrl-click should do what you want.
>

This helps me too (been on gnome3 full-time for a good few weeks now, but I still hadn't discovered it).

I'd like to argue that left-clicking on a launcher should always produce the same effect regardless of the state the app is in or the workspace you're on.

Right now it's quite unpredictable: if there's an active window open somewhere it focuses it, even if it was on a different workspace.

While the bug submitter's suggestion would definitely be a improvement, I'd still prefer it to always open a new window on left-click rather than focusing it, even if you're on the right workspace. 

The apps I use most are Epiphany, Terminal, Nautilus, Gedit and Thunderbird, and for all of these (except the last one, Thunderbird) I keep on left-clicking on the launchers thinking it'll open a new window; I'm always surprised if it just focuses an existing open window.

OT - I love the middle-click on launcher functionality ;-)

Yeah, it's very unpredictable and totally different from the behavior of other WM's.

*** Bug 651653 has been marked as a duplicate of this bug. ***

*** Bug 652601 has been marked as a duplicate of this bug. ***

As I point out in bug #652601, this behaviour is dependent on the app.

On an application where multi-window is normal like evince, eog, Nautilus, the terminal, Firefox or LibreOffice, we should open a new window on the active workspace. On applications where multi-instance behaviour is not so normal, like the GIMP, Rhythmbox, Banshee, Evolution, Thunderbird, etc, the application should focus if it's already open & switch workspace.

Obviously, deciding for a given application which of these behaviours is most appropriate is tricky, and is perhaps best left to the application developer/packager. Which would add another interface between WM and applications.

I also noted in bug #652601 that the visual indicator that an application is already open is a little too subtle for me - I didn't know about it until it was pointed out to me.

Cheers,
Dave.

It's true that for some apps we're currently showing meaningless options: New Window doesn't do anything for Evolution, and merely brings Rythmbox to the front. So the Shell would need to know whether apps are single or multi instances (via a .desktop file key?).

OTOH, if you make clicking on the LibreOffice icon always open a new window, that means you no longer can use the launcher as a way to jump to the LibreOffice window (very useful when you only have one window open). I think Windows 7 tries to solve this by showing several small areas next to the launcher, each one representing an open window, and with the window previews that appear when you hover on the button.

While I don't like the current situation - to this day I still click on icons thinking "new window" not "focus on active app" - I am a bit worried about introducing behaviour that is different depending on the circumstances:

- the app is active or not
- you're on another workspace or not
- this app likes multiple instances, while this app doesn't

these are all situations which, if we go by the comments here, would end up with different results. I think it'd be advisable to try to follow the principle of least surprise as much as possible.

Maybe the best solution is simply to have the launcher always create new windows. If the application is a single-window one by design, this is its job to prevent a new window to be launched and present the currently running window instead (rhythmbox already does that for example). In this case (and only this case), when a single-window application asks the window manager to present its main window instead of creating a new one, the main window could also be moved automatically to the currently visible workspace.

This way, by clicking on a launcher icon you never take the risk of being moved away from the workspace you're on. Whether it creates a new window, or present the already running one will only depend on the application's behaviour.

And for navigation, we would exclusively use the overview to reach for windows in the current workspace, or the workspace list on the right to reach other workspaces.

(In reply to comment #11)
> Maybe the best solution is simply to have the launcher always create new
> windows. If the application is a single-window one by design, this is its job
> to prevent a new window to be launched and present the currently running window
> instead (rhythmbox already does that for example).
No, because starting an application introduces a significant delay that would be very frustrating in many cases (even on quite fast computers). Better have the Shell know whether the app is single-instance (from the .desktop file) in the first place.

(In reply to comment #12)
> (In reply to comment #11)
> > Maybe the best solution is simply to have the launcher always create new
> > windows. If the application is a single-window one by design, this is its job
> > to prevent a new window to be launched and present the currently running window
> > instead (rhythmbox already does that for example).
> No, because starting an application introduces a significant delay that would
> be very frustrating in many cases (even on quite fast computers). Better have
> the Shell know whether the app is single-instance (from the .desktop file) in
> the first place.

There doesn't seem to be any delay on my 1 year old laptop when launching rhythmbox while it's already opened... But, if this is really the case, using the .desktop file to define single-window apps seems to be quite a fair  solution.

I also just learnt about strg-left_click in this bugreport. And, like some other users here, I would also prefer if the behaviour of left_click and strg-left_click would be switched. (Probably one could make that customizable?)

@Julien Olivier: I had the same problem especially with terminals. I "solved" it with assigning a shortcut to open terminals. Pressing [F1] now always actually opens a terminal no matter if and where other terminals are.

(In reply to comment #14)

I just "discovered" that, instead of strg-left_click on an icon in the dash, one can just drag the icon onto the window overview to start a new instance of a program.

Probably this feature (such features) should be better communicated to the users. ;-) Because I also learnt it from another bug report rather then while using gnome.

(In reply to comment #15)
> Probably this feature (such features) should be better communicated to the
> users.

Suggestions? It is certainly not an undocumented easter egg[0] ...


[0] http://library.gnome.org/users/gnome-help/stable/shell-apps-open.html.en

Hi, obviously this is not easy. Probably a FAQ with the main differences to Gnome2 and other desktop environments would help, since it's always the same questions people have.

The corresponding entry could look like this:
> How can I start a new instance of a program in the dash?
>> Clicking on the application icon will launch it if it is not running, and will open the last used window of that application if it is already running. To run a new instance of a program no matter if it's already running or not you can either:
- press strg while clicking the icon
- right click the icon and choose "new window"
- drag the icon onto the window overview (e.g. 1cm to the right)
- drag the icon to a particular workspace to open a new window for that application on that workspace
- middle click the icon open a new instance on a new workspace


On the help page you posted and on the CheatSheet[0] there is only this behavior documented:
"You can launch an application in a separate workspace by dragging its icon from the dash (or from the list of applications), and dropping it onto one of the workspaces on the right-hand side of the screen. The application will open in the chosen workspace."

The way more usful feature "dragging the icon onto the window overview" (about 1cm to the right instead across the whole screen) is not documented on both pages. Altough while doing the first one someone would probably figure the 2nd one out. ;-)


This FAQ should be easy to find, probably have a launcher in the dash or the like. Also, have you thought about a short video explaining these kind of features and usability?


Thank you for your time.

[0] http://live.gnome.org/GnomeShell/CheatSheet

*** Bug 670045 has been marked as a duplicate of this bug. ***

*** Bug 662835 has been marked as a duplicate of this bug. ***

See also bug 661207.

I'll add the text from my dupe bug #670045 below:

Modal buttons (i.e. buttons that change their behaviour depending on various
environmental conditions) are often considered harmful as they often leave the
user unsure as to what will happen when they are pressed.

The application launcher buttons in overview mode appear to be an example of
this: when an application isn't running, clicking on its button opens a new
window; but if it is running, clicking on its button raises all the existing
windows belonging to that application.

For example:
1. Clicking on the "Terminal" launcher icon when gnome-terminal isn't running
opens a new terminal window.
2. Clicking on the "Terminal" launcher icon when there are 10 existing
gnome-terminal windows open simply raises all 10 windows at once.

This leaves the user unsure what the outcome of clicking the "Terminal" icon
will be, since they have to consider whether or not there are other Terminal
windows open already.  Arguably, raising 10 existing terminal windows is
unlikely to ever be what the user wants - clicking the Terminal launcher should
consistently do the same thing each time, open a new gnome-terminal window.  If
the user wants to raise a specific window, Overview mode already provides a
consistent interface to do this by allowing the user to click on the
Exposé-style shrunken windows.

This problem is even more apparent with Empathy: Clicking on the Empathy
launcher icon will cause the contacts window to appear, except if any chat
windows are already open they are raised instead and there is no obvious way of
accessing the contacts window again (the answer is to right-click the Empathy
icon and select "New Window", but this is very unintuitive since it is
completely different to the method the user would've used to open the contacts
window originally.

Also, I'll add that I'm not convinced that "single-instance" applications are an exception to the rule.  There is no reason to assume I wouldn't want more than one window open to a application that is traditionally "single instance".

Take, for example, Empathy's contacts window - it is assumed that the user will only ever want one instance of this window open.  If I hit "new window" while the contacts window is open on another workspace, it is _moved_ to the current workspace.  Who's to say that I didn't want a separate contacts window open on both workspaces - I expect "new window" to do exactly that, give me a new window, not move an existing one.

As an example of why the current "new window" behaviour for single-instance apps is bad: I'm working on specific workspace to do a specific job.  If I suddenly need to suspend my work on the current job and work on a different job it is reasonable for me to switch to a new workspace to start the new job.  This means I can open whatever windows I need to perform the second job without affecting what I've already got set up on the first workspace for the first job.  If, however, when I eventually switch back to the first job I find that half the windows I had open have vanished because when I asked for a "new window" on the second workspace it actually moved the window off the first one instead of giving me the new window I asked for, this separation of jobs doesn't work.

*** Bug 704413 has been marked as a duplicate of this bug. ***

This is an old bug, but I wanted to state the news in this:
1. There's an official extension to always launch a new window.
2. In GNOME 3.16, the default behavior depends on the app. Imagine:

Workspace 1: Nautilus.
Workspace 2: gnome-terminal.
Workspace 3: nothing. User focus.

Now click gnome-terminal launcher and it will focus on workspace 2.

Now go again to workspace 3 and click nautilus launcher. Nothing happens.

If I'm not wrong, currently left-clicking the launcher focuses, and middle-clicking (or ctrl+left-clicking) it opens a new window. It's a choice, no problem; mostly when users can override it with a simple extension.

But please please just be consistent. Let the user choose if he wants a new window or not, depending on how he clicks. I cannot remember always which apps work and which don't. I just expect the window manager to do always the same thing after the same input.

Clicking a launcher and waiting without knowing if it is because the app is slow or because it is simply ignoring me is very frustrating -- mostly when it's the 2nd.

(In reply to Yajo from comment #24)
> This is an old bug, but I wanted to state the news in this:
> 1. There's an official extension to always launch a new window.
> 2. In GNOME 3.16, the default behavior depends on the app. Imagine:
> 
> Workspace 1: Nautilus.
> Workspace 2: gnome-terminal.
> Workspace 3: nothing. User focus.
> 
> Now click gnome-terminal launcher and it will focus on workspace 2.
> 
> Now go again to workspace 3 and click nautilus launcher. Nothing happens.
> 

I'm pretty sure you're experiencing a bug there. In gnome 3.20, this behaviour is consistent: if an app is running on a different workspace, and you click on its launcher, you'll always be moved to the workspace where the app runs. I don't like this behaviour but, at least, this seems consistent to me.

Thwat thing I told you in comment #24 is happening to me currently in Fedora 24 with gnome-shell-3.20.2-1.fc24.x86_64.

(In reply to Yajo from comment #26)
> Thwat thing I told you in comment #24 is happening to me currently in Fedora
> 24 with gnome-shell-3.20.2-1.fc24.x86_64.

Well, I don't see it in gnome-shell-3.20.4-0ubuntu1 in Ubuntu 16.10...

(In reply to Yajo from comment #26)
> Thwat thing I told you in comment #24 is happening to me currently in Fedora
> 24 with gnome-shell-3.20.2-1.fc24.x86_64.

My guess: You enabled desktop icons, so there *is* an open nautilus window on the active workspace (the desktop window). In 3.22, the desktop window has been split from the regular file manager application, so this shouldn't be an issue any more.

I tested and you're right. Removing that option from the tweak tools fixed this.

I don't see us doing this. Anything other than consistently switch to the app if it's running or always opening a new window (like the launch-new-instance extension) sounds fairly confusing, in particular when considering apps that don't support multiple windows ...