Ctrl-W is not consistent with Epiphany & Terminal

[jlnr]

When only one tab is open in Files, Ctrl+W does not close the window, but instead opens the home folder again. I think that Epiphany's/Terminal's behavior is more intuitive here - Ctrl-W with only one open tab closes the window.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/54896551-ctrl-w-is-not-consistent-with-epiphany-terminal?utm_campaign=plugin&utm_content=tracker%2F65602118&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F65602118&utm_medium=issues&utm_source=github).

[jeremypw]

If the design team is in agreement this is easily changed.

[danirabbit]

We previously decided against this because Ctrl + W is the close tab shortcut, not the close window shortcut. If your intent is the close the window there is another shortcut for that. But changing this would mean that we're trying to be clever and assume your intent instead of following what you told the computer to do.

For example, if your intent is simply to close all of your open tabs so that you have a clear "workspace" and you mash Ctrl + W and then suddenly Files quits, this looks like a crash and does something different from what you told Files to do (Close tabs).

[cassidyjames]

So, this is actually a bug with Terminal and Epiphany. 😉

[jlnr]

There's some consistency behind Epiphany's/Terminal's behavior: If you press Ctrl+W when only one tab is open, the window closes. <=> If you press Alt+F4 when only one window is open, the application quits.

Other apps like Scratch/Code and most "workbench apps" (where mashing Ctrl+W is especially common) don't close the window when the last tab is closed (or dragged out from the tab bar). Instead, they display an empty state screen with an empty/hidden tab bar, which ignores further Ctrl+W presses and typically makes it easy to get started with the next project.

Files is an outlier because it neither closes the window, nor does it display an empty state screen. It immediately re-opens a new tab with the home folder. In a way, this is also a guess at what the user wants to do next; it could also keep the last tab open, or show a list of recent locations as an empty state screen.

I don't think either behavior is unreasonable here, but I feel that changing Files to match Epiphany/Terminal would make the OS both more internally consistent and more compatible with muscle memory from third-party apps (all browsers seem to work like Epiphany now -- and I would guess that browsers are where most people learn how to use tabs).

This is the best case I can make for changing this :)

[jeremypw]

Elementary apps are supposed to restore their state at close when reopened. If the last tab has been closed what is intended to be restored? In fact Terminal restores the tab that was closed which seems illogical. It seems more logical for closing the last tab to put the app in a sensible "initial" state. In the case of Code then there is a sensible "no document" state but that is not the case for Files or Terminal. Showing the user home directory is not an unreasonable default state, however.

[artemanufrij]

@jeremypw first thing what I do after fresh install is to disable tab restoring for all apps. currently it's not possible disable it for code. It was the reason for me for switch to another editor.

[jlnr]

@jeremypw Terminal's restoration behavior is both practical and logical in my opinion: If you close the last tab of the last window, the tab will not be restored later, because you really meant to close the tab -- closing the window is only a side effect of that. However, if you close Terminal other than by closing all tabs (most common for me: by rebooting) and then relaunch it, the previous tab(s) will be restored.

I'm a big fan of tab/state restoration, but I still prefer the "Terminal model" (closing the window along with the last tab), and I think the two are perfectly compatible. I can't compare with Epiphany right now without losing my precious tab collection :)

Definitely food for thought, though. I agree that the home folder is a good default state, I just don't expect it to be reopened immediately when I close the last tab.

[jeremypw]

@jlnr: For me, closing the last tab in Terminal does restore that tab when you reopen the app. When you say "the tab will not be restored later", what does happen and what do you expect? Have you turned off tab restoration in settings?

[jeremypw]

It does seem reasonable that at least Terminal and Files have the same behaviour as they are both show one folder per tab. But I am not sure what that behaviour should be.

[jeremypw]

It would be interesting to know what proportion of users turn off tab restore (or would like to if they knew how).

[jeremypw]

@artemanufrij : Have you opened an issue in Code? It seems inconsistent have this setting in some apps and not others.

[artemanufrij]

@jeremypw we could start a survey on G+

[jlnr]

Regarding state preservation of the last tab, this is what I see in Terminal (and I don't remember changing any settings):

1. Launch Terminal
2. cd Pictures
3. Press Shift+Ctrl+W, or middle-click the tab, or click the (x) in the tab
4. Launch Terminal again
5. I see one tab in the home folder (initial/default state)

vs.:

1. Launch Terminal
2. cd Pictures
3. Click the (x) in the window header, or quit Terminal via the context menu in Plank
4. Launch Terminal again
5. I see one tab in ~/Pictures (tab restored)

[artemanufrij]

@jeremypw yes. https://github.com/elementary/code/issues/162

[jeremypw]

@jlnr That is not what I experience (using Terminal master compiled and installed on Juno) - are you on Juno or Loki?

I am using the default settings.

[jlnr]

Ah sorry, I am still on Loki and hadn't tested these steps in my Juno VM, that probably explains the difference. I prefer the Terminal behavior in Loki. Epiphany on Juno still behaves the way I've described it: the last tab is not restored if it was explicitly closed.

[jeremypw]

@artemanufrij : I did not realise this was a closed, "Won't Fix" issue in Code. This being so, a survey may be interesting but would not necessarily influence elementary design.

[mahajanudit]

I agree with jlnr and others that Ctrl + W with last tab open should be intuitive. Currently the way it refreshes to home in an instant looks a bit buggy. Also, many apps, not just Gnome apps, but even outside of gnome or even linux for example web browsers, firefox and chrome have this behavior. Ctrl+w is much more habitual then Alt+F4 and most users are used to it. We also need to think of what users generally do, most users spend their majority time in web browsing (given we want avg user to come to linux) so the behaviour should be consistent. These are my 2 cents

[eljefuri]

I am in agreement (as a user) that this current behavior of reloading the home window is quite strange. I expect it to close Files if it is on the last tab. For what it's worth I don't think that every application that features tabs should necessarily have identical behavior, but this at least mirrors my expectations coming from macOS and most browsers.

[sprite-1]

Sorry for butting into this discussion and this is slightly off-topic but here's a compromise I can think of for people who want their tabs restored and those that want a clean slate whenever they open an app. I'd just like to preface this by saying I'm one of the people whose first move after finding out about the tab restore feature is to find out how to disable it on both Terminal and Files.

Anyway, my suggestion is to make the default behavior be to start fresh but use this button to easily restore previous session. That way it caters for both use cases.

[jeremypw]

@sprite-1 An interesting idea but I doubt the default behaviour will be changed as it is a key part of elementary design principles that apps open fast and restore their state. There an open PR #823 that stops tabs being restored if History is off in the Privacy settings but some questions are outstanding on this behaviour and may be too blunt an instrument for some even if easier than fiddling with dconf settings.

[sprite-1]

@jeremypw I'll understand if the default behavior will not be changed to this but at the least, give us a flag we can toggle in dconf editor for it 👼

[jeremypw]

You can change the restore tabs behaviour by changing io/elementary/files/preferences/restore-tabs setting with dconf-editor or the commandline.

[sprite-1]

I've set that option long ago 👍 but what I meant is the option to restore the previous session without it being forced on me everytime I open the app

[jeremypw]

OK. We are rather constrained by the embargo on new widgets in the Files interface but your suggestion may work.

[jeremypw]

Of course if History is off in settings, then the session will not be remembered and cannot be restored anyway.