So the idea is that some class of application, which opens several independent windows, should not be treated as others? Terminals do not seem to be the only app in that case: Files windows are also unrelated to each other (even if they do no use spatial mode); same with LibreOffice windows.

This problem was first discussed in Bug 650030:
https://bugzilla.gnome.org/show_bug.cgi?id=650030#c8

The problem with all this is that consistency is kind of lost; maybe that's not such an issue, though.

(In reply to comment #1)

With most multi-instance apps, you still don't have that many windows. Terminals are potentially special though, since the number of windows will typically be higher and spawning new windows is much more common.

One possibility might be to have a setting (either in the Terminal preferences or the app launcher context window) to allow specifying the desired behaviour (but defaulting to spawn new window).

To be clear, I am not suggesting that we have a class of applications that behave entirely differently in the launcher. I'm suggesting that special casing an application most non-technical users will never see in order to accommodate advanced/legacy usage may be acceptable.

Created attachment 265844 [details] [review]
appDisplay: Special case terminal launching

Review of attachment 265844 [details] [review]:

::: js/ui/appDisplay.js
@@ +916,3 @@
         let event = Clutter.get_current_event();
         let modifiers = event ? event.get_state() : 0;
+        let terminals = global.settings.get_strv(TERMINAL_APPS_KEY);

That's quite ugly - why not do something like

  let isTerminal = app.get_app_info().get_categories().indexOf('TerminalEmulator') > -1;

(In reply to comment #5)
> Review of attachment 265844 [details] [review]:
> 
> ::: js/ui/appDisplay.js
> @@ +916,3 @@
>          let event = Clutter.get_current_event();
>          let modifiers = event ? event.get_state() : 0;
> +        let terminals = global.settings.get_strv(TERMINAL_APPS_KEY);
> 
> That's quite ugly - why not do something like
> 
>   let isTerminal =
> app.get_app_info().get_categories().indexOf('TerminalEmulator') > -1;

I can't believe I missed that when reading my /usr/share/applications/xterm.desktop. :-(

Created attachment 265862 [details] [review]
appDisplay: Special case terminal launching

(In reply to comment #6)
> I can't believe I missed that when reading my
> /usr/share/applications/xterm.desktop. :-(

If it helps, I don't think I would have thought of this either when it had not been mentioned on xdg-list recently ...

Review of attachment 265862 [details] [review]:

Code looks good now, adding some rationale for the change in the commit message would be nice though.

::: js/ui/appDisplay.js
@@ +48,3 @@
 const PAGE_SWITCH_TIME = 0.3;
 
+const TERMINAL_CATEGORY = 'TerminalEmulator';

The constant looks a bit pointless to me (it's unlikely to ever change, and its only use is right below), but okay.

I'd like to add that I'm unsure about this change - it will get rid of a lot of complaints (I don't recall a single complaint about the launcher behavior that did *not* use a terminal as "randomly picked" example), but it might just create new complaints that the dash can be used to switch applications except for terminals ...

Created attachment 265866 [details] [review]
appDisplay: Special case terminal launching

Thanks! The feedback I've got from the design team was positive, so let's go with this.

Yep, thanks for this Debarshi!

There might be some negative aspects to this change, so let's consider the bug under review. If you have feedback (good or bad) about the change, please post it here.

If you ask me, I'm surprised you designers have accepted such a hacky workaround. :-)

It's hard to imagine terminals are the only applications which need this behavior. What makes them so special? This has been discussed in Bug 650030 already, and IMHO there are several classes of apps which present the same profile as terminals.

Basically, I think we need to distinguish between apps which will only ever have one main window opened (e.g. Rhythmbox/Music, Photos, Documents, Contatcs, Evolution, to some extent Web since tabs replace windows) from those which are in essence multi window. In the latter class, you have terminals, but also word processors, image editors, the file browser, and document viewers. The file browser is in particular very similar to terminals: I very often find myself wanting to open a new instance of Files just to find some file, just like I often need to open a new terminal to run some command quickly.

Let's face it: while it's very natural for single-window apps, the current design is a relative failure for multi-window apps. This is because half the time people will want to reach an existing window, and the other half they will want to open a new window. I think there needs to be a way to do easily both without using hidden goodies like Ctrl+click or drag and drop. This is not an easy problem, see how it works poorly on Windows 7 too (not sure about Windows 8).

Here are a few ideas which work together:
- When hovering over an app icon in the dash, show a + sign (or whatever) allowing to open a new window for this app. Applications could declare in their .desktop file that they are single window to disable this behavior.
- If there's no window of the application on the current workspace, open a new window instead of jumping to the workspace that contains an existing one. I think this is one of the main reasons why power users are so frustrated they request hacks like the current one for terminals.
- Keep the current behavior of raising all windows (or only the more recent) from the current workspace when clicking. But have a visual indication of how many windows are open for this app (so that you know whether there's a risk you won't automatically get the one you think about).
- When hovering over the icon, also show after a short delay a list of open windows for this app (on the workspace, or everywhere?). This would make it easier to choose the correct window than the current right-click thing (especially on touchpads, even more on tablets). The way of presenting the list of windows should also be improved, as the current one is rather basic: maybe hide windows from other apps, and move the thumbnails of the relevant app towards the dash icon (reducing their sizes) so that they can be selected easily?

(In reply to comment #14)

> It's hard to imagine terminals are the only applications which need this
> behavior. What makes them so special? This has been discussed in Bug 650030
> already, and IMHO there are several classes of apps which present the same
> profile as terminals.

From the Git commit log:

    One of the most frequent complaints about our launching behaviour is
    how we handle terminals. Among all MDI applications, the terminal is
    the one that is most likely to have lots of semi-independent windows
    opened at the same time, and spawning new windows is much more common.
    More so, if it does not support tabs.
    
    Therefore, we special case terminal launchers to always create a new
    window. It is an application that most non-technical users will not
    use, so chances of them being confused by any special behaviour is
    expected to be low.

(In reply to comment #15)
> (In reply to comment #14)
> 
> > It's hard to imagine terminals are the only applications which need this
> > behavior. What makes them so special? This has been discussed in Bug 650030
> > already, and IMHO there are several classes of apps which present the same
> > profile as terminals.
> 
> From the Git commit log:
> 
>     One of the most frequent complaints about our launching behaviour is
>     how we handle terminals. Among all MDI applications, the terminal is
>     the one that is most likely to have lots of semi-independent windows
>     opened at the same time, and spawning new windows is much more common.
>     More so, if it does not support tabs.
> 
>     Therefore, we special case terminal launchers to always create a new
>     window. It is an application that most non-technical users will not
>     use, so chances of them being confused by any special behaviour is
>     expected to be low.
Yeah, I see your point, but to me Nautilus is a very similar case. Non-power users deserve a good design for this use case too! ;-)

I don't necessarily think that the Terminal is a "power user" feature, necessarily.

When I was first starting out with Linux, just using it regularly to browse the web and do documents, I had to Google for tasks like "how to connect to a remote printer through a Windows machine" or "how to copy lots of files around" for steps to follow, and a lot of them would start out with "now open the Terminal".

This change just makes me sad.

Agreed with Florian, this is IMO a much worse situation, where there is special-cased inconsistency with the launcher.

Some arguments for reverting this patch:
* Power users are also the ones most likely to know how to get the desired behaviour via an extension
* It isn't necessary with the default terminal emulator gnome-terminal, with its support of tabs.
* Terminal users are necessarily using the keyboard - creating a new window should be as simple as e.g. Ctrl-Shift-N, vs. either a slower mouse action or Win, "te", Enter.

At the very least, can you please provide a dconf key to switch this behaviour, or even better, generalise it to have the special cases (e.g. TerminalEditor) to always launched in a new instance be read from a gconf string?

Milan, interesting suggestions for larger changes to support both switching and launching use cases better, but bear in mind the touch screen use case where hover isn't available.

Thanks for your consideration! ;)

I get your point here but breaking the expected behavior for users of tabbed terminals is not acceptable. While I use two or three terminals myself quite often and the current behavior is kind of strange as well I doubt that breaking consistency will improve the situation.

I have another proposal:

For apps which support multiple instances, instead of just showing the name on the right side when hovering the icon, show a small menu containing a) the titles of all instances and b) a "new window" entry. To put it another way: show what we get on right click (sans "remove from favs") automatically on hover!

Apps which want this behavior would need to declare it by setting a key in the desktop file.

I think this is the only sensible way as it does not break any use case, keeps consistency, makes it a bit easier to spawn multiple instances by and (which is very important IMHO) make it possible to select the correct instance when switching windows. Clicking for both multi and single window apps would do exactly what it does now. There is no downside.

My only fear is that it creates an inconsistency in behavior.  Clicking on the terminal app launches a new instance rather than zooming to an existing one.  Yes, it will remove some complaints, but we are sacrificing inconsistency when doing so.  It seems that it would be better to provide an extension to change this behavior so it can be tailored.  I think it would be a jarring first time experience because the user didn't initiate the behavior change.

Don't get me wrong, I personally would love this because 99% of the time I launch a new terminal, because there is no way that shell will pick the right terminal that I want to focus on and invariably a user will have to use their own method to manage terminals or multi-window apps/utilities.

Milan is correct that our current design doesn't really allow for multi-window applications.  Terminals especially break the idea of an 'app' since it's not an app, it's a window to working directly with the operating system in a spatial manner.

I also think would be inconsistency in behaviour. I learned "GNOME SHELL" know and this will break it.

1. The current behaviour allows for switching between all applications by
   Alt+F2 -> name -> Enter/LEFT_MOUSE
2. The current behaviour allow for opening a new window of all applications by
   Alt+F2 -> name + Ctrl+Enter/Left_MOUSE

Keyboard navigation is one of the things which are absolutely perfect in GNOME3 and changing that will break consistency and workflow. I have to mention that the Ctrl+Enter/LEFT_MOUSE is available since 3.6(?).

I don't see a convenient way to switch between applications, if this is changed. Also, how to prevent "opening a unwanted new windows", another key-combination would be totally weird.

Maybe I should describe typical workflow:

I'm used to open one [terminal | file-browser | web-browser | random ] for one general subject. Within this window I open (maybe a lot) tabs for the different tasks. In case of terminal there is also "screen" ;-)
Other people maybe put on top of this different virtual-desktops, personally I don't use that much. But you can go even further.

GNOME can't know what the user desires.

This change is very disappointing to me as well, I much prefer GNOME 3's app switching behavior and this breaks my workflow for one of my most used apps. Making exceptions and ugly hacks for loud complainers is also a bad precedent to set, I would imagine; if someone wants the GNOME 2 / Windows behavior of application switching there are other ways they can go about it, being "advanced" users and all.

I think this should be done with a shell-extension or just general switch which allows turning off the window-switch/single-instance behaviour. That's why extensions (or settings in general) exist, allowing adaption to the wishes of the users.

This wouldn't break the current usage-convention of the GNOME-Shell. The window-switch and window-creation behaviour would remain intact. Their wouldn't be a weird exception for a single class of applications.

I thought about a big extension which allows for generally turning this [on|off] or special-caseing groups of applications (terminals, file-browser, web-browser, office and so on) in a list. But special-caseing feels bad, it just weird even if it is user-visible.

Most people are either fine with the current behaviour or don't like it at all.

We haven't heard much about this bug since the behaviour was changed; maybe that's simply a result of not many people running shell master.

That said, the point about inconsistency is a valid one, so I think we should revert this change for 3.12.

I also think we should look into using middle click to launch new windows on the current workspace (rather than on a new workspace).

(In reply to comment #26)
> I also think we should look into using middle click to launch new windows on
> the current workspace (rather than on a new workspace).

So middle click should become the same as ctrl-click?

(In reply to comment #27)
> (In reply to comment #26)
> > I also think we should look into using middle click to launch new windows on
> > the current workspace (rather than on a new workspace).
> 
> So middle click should become the same as ctrl-click?

Maybe this should all be in a new bug?

I'd personally prefer middle click to launch on the same window since it's a much easier/quicker action, and I suspect, though I don't know, that it's a much more common action than 'launch on new workspace'.

I'd also argue that the utility for 'launch on new' is minimal - if workspaces=tasks, then if you want to launch new windows of multiple applications on a separate workspace, the quickest way by far is switch to new workspace -> ctrl-click each app (try each way!)

The only thing is, middle click isn't universally available (e.g. laptops) - maybe it'd be better to have ctrl-click and middle click do the same thing (same as in a web browser with links, so it's a familiar pairing), and move the 'new workspace action' elsewhere - context menu maybe?

Created attachment 268804 [details] [review]
Revert "appDisplay: Special case terminal launching"

Having terminal launchers behave differently than any other launchers
is non-obvious and confusing. Remove the special-casing to restore
consistency, we will make the new window action more accessible
instead.
This reverts commit 68faba6bde08a8898941, 4ed0f3e5f0f9d2f7
and 887a21afb97aaa35.

Created attachment 268805 [details] [review]
appDisplay: Open new window on middle-click

The current middle-click action of opening a new window on a new
workspace is a bit peculiar; it is also not overly hard to achieve
the same result by moving a new window to the desired workspace or
selecting a workspace before opening a new window. Just opening
a new window is also a more common action, so having a shortcut
available that doesn't require a modifier is a good idea as well;
change the middle-click behavior accordingly.

Review of attachment 268804 [details] [review]:

LG.

Review of attachment 268805 [details] [review]:

Makes sense.

Attachment 268804 [details] pushed as 812a619 - Revert "appDisplay: Special case terminal launching"
Attachment 268805 [details] pushed as 620e3ce - appDisplay: Open new window on middle-click

How about also having control middle click open a window in a new workspace?  So we don't lose that action.  Currently control middle click does the same thing as middle click.

(In reply to comment #34)
> How about also having control middle click open a window in a new workspace? 
> So we don't lose that action.  Currently control middle click does the same
> thing as middle click.

Yes please. Plus the ability to do the same action (new window in a new workspace) with search then Ctrl+Enter.

(In reply to comment #35)
> (In reply to comment #34)
> > How about also having control middle click open a window in a new workspace? 
> > So we don't lose that action.  Currently control middle click does the same
> > thing as middle click.
> 
> Yes please. Plus the ability to do the same action (new window in a new
> workspace) with search then Ctrl+Enter.

If click or search+Enter shows current open windows, and ctrl-click opens a new window, then ctrl-Enter should open a new window as well. Nothing wrong with having a keyboard shortcut/mouse action for new window in new workspace, but they should be thought out properly!

Thanks for reverting this patch, especially to Allan #26 and Florian #29. It is nice to see, that you hear on your users!


@ William Jon McCann #1:
Please take a look at the already existing extension "Launch new instance" available in the gnome-tweak-tool. When this extensions is turned on, it will always launch a new instance. I think this is merely what you want :-)

I wonder, why nobody of us mentioned this extension in the past.


@ Emmanuel #35:
I'm sorry, but this would also, breaking consistency and keyboard interaction. As Stephen explains, people expect Ctrl+Enter and Ctrl+Click to do the same. The Enter and Left-Mouse-Button share the same meaning in such cases. While nothing is wrong with the idea of a new keyboard-shortcut for such an action.

I'd like to chime into the choir of those who want a shortcut to "open a new instance on a new workspace" back. I normally use many workspaces and having no such shortcut bothers me a lot.

(In reply to comment #38)
> I'd like to chime into the choir of those who want a shortcut to "open a new
> instance on a new workspace" back. I normally use many workspaces and having no
> such shortcut bothers me a lot.

Mmmh, would it help to assign a default shortcut to move-to-last-workspace? "<super>End, <ctrl>Enter" could then be used to get the old behavior back without adding another obscure modifier combination ...

(In reply to comment #39)
> (In reply to comment #38)
> > I'd like to chime into the choir of those who want a shortcut to "open a new
> > instance on a new workspace" back. I normally use many workspaces and having no
> > such shortcut bothers me a lot.
> 
> Mmmh, would it help to assign a default shortcut to move-to-last-workspace?
> "<super>End, <ctrl>Enter" could then be used to get the old behavior back
> without adding another obscure modifier combination ...

Oh, shortcuts like <S-home>, <S-end> for going to first/last workspace would be awesome!

However, <S-home C-RET> seems to me quite the opposite of "without adding [...] obscure modifier combination". Do you mind elaborating about the <C-RET>-part?

This set aside, what is the rationale behind having two similar shortcuts (<C-mouse1>, <mouse3>) now doing the same thing (especially as there are other actions that some people might have integrated into their way of using GNOME)?

(In reply to comment #40)
> Oh, shortcuts like <S-home>, <S-end> for going to first/last workspace would be
> awesome!

Ugh, I would have sworn bug 659288 had landed :-(


> However, <S-home C-RET> seems to me quite the opposite of "without adding [...]
> obscure modifier combination". Do you mind elaborating about the <C-RET>-part?

I meant "<super>End to switch to the last workspace, then <ctrl>Enter (or <ctrl>click or middle-click) to open a new instance". So two consecutive actions rather than a single shortcut.


> This set aside, what is the rationale behind having two similar shortcuts
> (<C-mouse1>, <mouse3>) now doing the same thing

<ctrl>click and middle-click are actually subtly different - the former will keep the overview open, the latter will not. middle-click now does the same as <ctrl>enter (in search/keynav) though, which I don't think is a bad thing: one option is mouse only, the other keyboard only.