(In reply to comment #0)
> When the focus is on the app icon, the user should have the ability to press
> Alt-F4 to close the app. 
> 
> OS X provides this, one can press Command-Q during app switching.

Sounds like a nice feature to me, though I don't agree with the proposed shortcut: Per default, Alt-F4 closes a window, while Ctrl-q is the usual way of closing an application. So despite the risk of being accused of shameless OS X plagiarism, I still think we should use the latter ;)

An implementation should probably wait for the GApplication stuff settling down though.

It's fine to call shell_app_quit now, and assume the implementation will get better over time.

(In reply to comment #1)
> (In reply to comment #0)
> > When the focus is on the app icon, the user should have the ability to press
> > Alt-F4 to close the app. 
> > 
> > OS X provides this, one can press Command-Q during app switching.
> 
> Sounds like a nice feature to me, though I don't agree with the proposed
> shortcut: Per default, Alt-F4 closes a window, while Ctrl-q is the usual way of
> closing an application. So despite the risk of being accused of shameless OS X
> plagiarism, I still think we should use the latter ;)
> 
> An implementation should probably wait for the GApplication stuff settling down
> though.

Similarly, OS X allows hiding an app while Alt-Tab dialog is shown and this is useful as well. Since hiding is also an issue here, I have created a bug report on that one as well: https://bugzilla.gnome.org/show_bug.cgi?id=620270

This is again basically useful for decluttering the workspace, but unlike quit, this will allow the user to stash away currently unused applications' windows. Shall I open a new bug report for that one, or can these two be combined here?

> I don't agree with the proposed
> shortcut: Per default, Alt-F4 closes a window, while Ctrl-q is the usual way of
> closing an application. So despite the risk of being accused of shameless OS X
> plagiarism, I still think we should use the latter ;)
> 


Ctrl-q is more logical, but Alt-F4 is more convenient. User holds the Alt button during Alt-Tabbing, so maybe Alt-Q. But in that case, it would conflict with the usual gnome shortcut Ctrl-q. 

But we might get away with saying: This is the Alt-Tab dialog, so the prefix is always Alt here. :)

Created attachment 162486 [details] [review]
[appSwitcher] Add shortcut to quit application

Allow to quit the currently selected application by hitting Ctrl-q,
similar to the OS X switcher.

(In reply to comment #2)
> It's fine to call shell_app_quit now, and assume the implementation will get
> better over time.

Duh - stupid me.


(In reply to comment #4)
> Ctrl-q is more logical, but Alt-F4 is more convenient. User holds the Alt
> button during Alt-Tabbing, so maybe Alt-Q. But in that case, it would conflict
> with the usual gnome shortcut Ctrl-q. 
> 
> But we might get away with saying: This is the Alt-Tab dialog, so the prefix is
> always Alt here. :)

Sounds like a good suggestion to me - as releasing Alt would close the popup, using Ctrl-q actually becomes Alt-Ctrl-q, which is a pretty awful shortcut.

I still used Ctrl-q for the current patch until further design input - changing the shortcut is trivial though, the hard part is updating the icon list ...


Also, the patch does only deal with the appSwitcher popup, not the window thumbnails - for the latter, we'll probably want two shortcuts, one for closing the selected window and another one for closing its app.

Created attachment 162487 [details] [review]
[appSwitcher] Add shortcut to quit application

(In reply to comment #4)
> But we might get away with saying: This is the Alt-Tab dialog, so the prefix is
> always Alt here. :)

Mmmh, this patch uses Alt-q. It is waaaaaay more convenient, but I'm not sure that's a good thing after all - the popup already has bindings for TAB, w, a, s and d, which makes hitting Alt-q accidentally pretty likely ...

Created attachment 162488 [details] [review]
[appSwitcher] Add shortcut to quit application

Wooops, wrong patch

Review of attachment 162488 [details] [review]:

Overall looks good and seems to work fine, there is a inconsistency between the commit message and a bug though.

::: js/ui/altTab.js
@@ +242,3 @@
             else if (keysym == Clutter.Down || keysym == Clutter.s)
                 this._select(this._currentApp, 0);
+            else if (keysym == Clutter.q)

So you lied in the commit message ;) ... this is not Ctrl-q but actually Alt-q

@@ +978,3 @@
+    },
+
+    _onDestroy: function() {

You'd have to destroy the thumbnail box too (in case it is present).

Just open two terminal windows and close gnome-terminal using Alt-q and see what happens.

(In reply to comment #6)
> Created an attachment (id=162487) [details] [review]
> [appSwitcher] Add shortcut to quit application
> 
> (In reply to comment #4)
> > But we might get away with saying: This is the Alt-Tab dialog, so the prefix is
> > always Alt here. :)
> 
> Mmmh, this patch uses Alt-q. It is waaaaaay more convenient, but I'm not sure
> that's a good thing after all - the popup already has bindings for TAB, w, a, s
> and d, which makes hitting Alt-q accidentally pretty likely ...

Hmm... good point. 
Hitting q instead of a or w is quite easy ...

Note that w/a/s are just "easter eggs" that Dan added because arrow keys didn't work within Xephyr.

(In reply to comment #10)
> Note that w/a/s are just "easter eggs" that Dan added because arrow keys didn't
> work within Xephyr.

Yeah but I use them all the time because they are easier to reach with the same hand than the arrow keys (for the arrow keys you need your second hand at least on almost all keyboards)

it seems to me like the existence of this feature in OS X is just a workaround for the fact that in OS X you very very very frequently end up with apps still running after you're done with them (either entirely accidentally, or because you intentionally left it running after closing its last window "just in case") and then it's not until some time later, when you're Alt-Tabbing to another app, that you notice that the earlier app is still running and using up memory that you didn't intend it to be using.

Created attachment 162841 [details] [review]
[appSwitcher] Add shortcut to quit application

(In reply to comment #8)
> So you lied in the commit message ;) ... this is not Ctrl-q but actually Alt-q

My, evil me ... yup, changed the shortcut, forgot the commit message :(

Comment on attachment 162841 [details] [review]
[appSwitcher] Add shortcut to quit application

Parts of this patch are needed regardless of whether or not we keep the Alt-q behavior: it's already possible for a window or app to go away while the switcher is up (eg, if you tell an app to quit, and then immediately do Alt-Tab, but it takes the app a second or two to save its state and exit). It would be good to split out the "dealing with things going away" parts from the Alt-q parts.

(We don't need to deal with things being added, since we used a cached list of apps and windows, although we *could* if we really wanted to...)

>+            else if (keysym == Clutter.q)
>+                this._appIcons[this._currentApp].app.request_quit();

>+            else if (keysym == Clutter.q)
>+                this._appIcons[this._currentApp].app.request_quit();

you don't need to do it twice, just put it before the _thumbnailsFocused split, along with grave and Escape.

>+    removeItem: function(index) {
>+        let item = this._items.splice(index, 1);
>+        item[0].destroy();
>+    },

this is maybe tolerable for the app-randomly-unexpectedly-exited case, but if we're actually supporting Alt-q, it seems like we ought to tween here rather than abruptly removing the icon.

Actually... it's probably even worse for the the app-randomly-unexpectedly-exited case, since the user isn't expecting the icon to disappear in that case, and so will have even less context as to what just abruptly changed...

How about something a bit different. Instead of having a keyboard shortcut we
could have a close button [x] hovering over the upper right of the applications
icon in the alt-tab switcher that is similar to the close button on the windows
when you go into the activities switcher.

In the last few weeks I've noticed a few times where I was alt-tabbing and realized there was an app there that I forgot to quit.  It would indeed have been nice to take that opportunity to do so.  Alt+Q seems to be the better choice to me.

First, sorry for not updating that patch - I got stuck handling destroyed windows and moved on to other stuff :(

I'll get to it eventually, promise!


(In reply to comment #16)
> In the last few weeks I've noticed a few times where I was alt-tabbing and
> realized there was an app there that I forgot to quit.  It would indeed have
> been nice to take that opportunity to do so.  Alt+Q seems to be the better
> choice to me.

Once we handle stuff going away during Alt-tab, it is easy to add the shortcut. I just wanted to mention that this feature will conflict with the request in bug 625649, so we'll have to decide what's more important to us.

Finally, what happened to this request? Is it implemented? rejected? postposed?

I'm using gnome 2.91.93 in Archlinux, and, well, I really think that would be nice to have this alt+q shortcut in the alt-tab popup.


regards and congratulations for the upcoming release ;)

Do we still want this?

(In reply to comment #19)
> Do we still want this?

Yes!

Absolutely!

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

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

Yes yes yes!

BTW,

(In reply to Florian Müllner from comment #6)
> Mmmh, this patch uses Alt-q. It is waaaaaay more convenient, but I'm not
> sure that's a good thing after all - the popup already has bindings for TAB,
> w, a, s and d, which makes hitting Alt-q accidentally pretty likely ...

What about the user having to press Q twice, with the app icon starting to wobble and the background turning red and an X in  of the corner on the first time?

Also (forgot to ask, can't edit), Alt-Tab and the Alt-WASD doesn't do anything for me, but seems cool.

Im not a coder, but its a shame that after five years this feature is still not implemented. Take example from Openbox

Hiya Denis, I think it is one of those things where other things have taken more priority.  Clearly there are people who want this including core GNOME people.  The first step might be to talk with designers on how best to implement this with  the current design of GNOME.  It might even be worthy of an extension.  If you want to help champion this, please visit #gnome-design and bring up the bug.  You might not get an immediate reply, but something will happen. :)

FWIW, I've been taking a look to this one and, surprisingly, Florian's patch still applies quite nicely on the current codebase.

I still can see a few issues, specially when closing apps with the windows' thumbnails open, so I'll try to iron those out before proposing a review.

In the meantime, here is the WIP branch: https://git.gnome.org/browse/gnome-shell/log/?h=wip/msanchez/620106

Created attachment 364956 [details] [review]
[appSwitcher] Add shortcut to quit application

Allow to quit the currently selected application by hitting Alt-q,
similar to the OS X switcher.

Created attachment 364957 [details] [review]
altTab: Use arrow functions for callbacks

Created attachment 364958 [details] [review]
switcherPopup: Handle removal of items from SwitcherPopup

This will be mainly useful for closing apps from the applications
switcher, but can be implemented generically enough to select the
nearest existing item after removal if there's any, or destroying
the popup's actor otherwise.

Specifically for the apps switcher, doing this also removes the need
of having to manually either update the current app in AppSwitcher
and highlight it, if there are still any items after the removal, or
simply destroy the AppSwitcher otherwise. Besides, calling _select()
in the handler for item-removed makes sure that the list of thumbnails
in the switcher is always closed, if open, when quitting the app.

Created attachment 364959 [details] [review]
altTab: Ensure no undefined objects are referenced after quitting an app

Add a few extra checks to prevent hitting undefined items when destroying
the list of thumbnails (if any) and selecting a new application after
quitting an application right from the switcher.

@Florian, @anyone: I think this is ready for review. I started porting your patch on top of the latest master and then only a few additional fixes seem to be needed to have it working.

Please let me know what you think. Even better, test it! :)

Does this also work with Windows+Tab? What happens if either of those are redefined?

(In reply to Bastien Nocera from comment #34)
> Does this also work with Windows+Tab?

I assume you mean the "Switch Windows" operation, in which case the answer is "no, it doesn't". But I can't see why I could not extend the set of patches to cover that as well

> What happens if either of those are redefined?

The way this has been done has been by checking whether the user has pressed the Q key while in the "Switch applications" mode, which you enter with whatever keybinding you have defined[1], so it works regardless of whether you have redefined them or not: as long as you press the Q key while in that mode, you request the app to quit.

[1] https://git.gnome.org/browse/gnome-shell/tree/js/ui/altTab.js?id=6e3178d5b6f070599f918acdc290caed9f29e37c#n159

Created attachment 365019 [details] [review]
altTab: Add also a shortcut to close windows from the WindowSwitcher

This allows closing windows pressing Q while operating the window
switcher popup, similar to what has been done for the apps switcher.

Awesome, Mario. Hopewell this will get approved. Thank you

Found this ticket today while going through my TODO list. @Florian, is there anything else I can do to get this one moving?

Ping? @Florian, let me know if you want me to move this one to gitlab and propose a MR there, thanks

Closing this bug after migrating it to gitlab, where it should be easier to do the review of the multiple-patch changeset.

Let's continue in https://gitlab.gnome.org/GNOME/gnome-shell/issues/23

Quick note here to let people know this has landed in master:
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/16