[launcher] Quicklist's "Quit" doesn't exit certain applications

[Hernando Torque]

To reproduce:

* Open XChat or Banshee with the "Notification Area Icon" plugin enabled,
* Quit XChat/Banshee via its quicklist.

=> The launcher icon suggests that the application isn't running while it still is.

---

* Open Banshee with the "Application Indicator for Banshee" plugin (banshee-extension-appindicator) enabled,
* Quit Banshee via its quicklist.

=> The launcher icon's background is colored, but there are no arrows visible. The launcher then doesn't react to a left-click and Banshee can only be focused by using the "Open New Window" quicklist entry.

---

Desired resolution:

- The quicklist 'quit' option should always exit the application. This include services without a mapped window.
- Applications that are running but do not have a mapped window should still be indicated as running by having a white triangle positioned to the left of their Launcher icon.

[David Barth (dbarth)]

Hmm, so this a gap in how we manage applicatons or services without a mapped window. From the user perspective, it depends if we want to reflect the existence of a running process, vs represent an application as active if it has a window. I think this is still an open question with design. Hence linking to a design bug for the moment.

The issue with the notification area icon, I'd prefer to put aside however. since we will stop supporting the old systray for Natty.

[Paul Sladen (sladen)]

David: choosing sets of applications/process/what-counts might be easier to solve if the idea of setting up Process Groups comes to anything (recent talk intended to improve scheduling, might make it get done).

[MaxNegro (maxnegro)]

I understand that ubuntu is not going to support the systray anymore, but I fear many applications still don't know about that decision. Skype defaults to close to systray, and the same does deluge. I suppose there are more. I suspect that users might get quite confused by this behaviour.

[Alex Launi (alexlauni)]

MaxNegro that is a separate issue, please keep bug comments focused on the issue at hand. (Excuse this deviation...)

[Alex Launi (alexlauni)]

This issue is confirmed, but we need design input to determine how best to fix it.

[Florian Boucault (fboucault)]

Empathy case: bug 667902

[Otus (jan-varho)]

For Rhythmbox with a song playing the Quit button simply fails to do anything.

[Dimitris Papageorgiou (papageorgioud)]

Replace the word quit with a "close all windows" since that's what it does.

[Benchrest (benchrest)]

using Ubuntu Classic Skype icon is missing from the panel so it cannot be shut down either. I think this is the same bug.

[Neil J. Patel (njpatel)]

Send sigquit

[Neil J. Patel (njpatel)]

Erm, set SIG* (whichever one is the right one)h

[mrpotato (estoyhartodeponernombres)]

This bug it's even worse in Pidgin. It doesn't have an indicator (at least the version I'm using -2.7.11) and it keeps active when you close all windows. So the only way to really quit the program is to launch it again from the dock and then hit ctrl+q

[Alberto Mardegan (mardy)]

I'm afraid the only way to fix this bug is to rename the "quit" command to "close" (or "close all windows"), as suggested in comment #8.

Sending SIGTERM leads to other problems:

a) if we send it before closing the application windows, the application will usually terminate without asking for user input in case it has unsaved data (for instance, gedit prompts the user to save the current file only if its window is closed). I'm not sure this is desirable.

b) if we send it after closing the application windows, another inconsistent behaviour appears: for example in xchat:
  1) We close the xchat windows -> xchat prompts the user: "minimize, quit or ignore?"
  2) user chooses minimize -> xchat windows are closed, and xchat stays to the tray
  3) we send SIGTERM -> xchat exits completely, though the user wanted it to run minimized.

[Otus (jan-varho)]

Another way is to fix all applications to properly quit when asked to close all windows.

Where can the Ayatana design for this be found, since it's marked fix released?

[John Lea (johnlea)]

@Otus

"fixed released" in ayatana-designs means that the change has been approved by the design team and handed over to developers. See the status in project "unity" to track implementation.

As nobody has started working on this item yet, feel free to contribute a patch ;-)

[Otus (jan-varho)]

Ok, which change is it that's been approved?

[John Lea (johnlea)]

See 'desired resolution' in the bug description.