GNOME Bugzilla – Bug 658988
message tray vs empathy window
Last modified: 2021-07-05 14:12:06 UTC
There are some strange interactions between the empathy window and the tray chat. The two that really jump at you are: * I get both when I start a chat * closing the window removes the conversation from the tray
(In reply to comment #0) > The two that really jump at you are: > * I get both when I start a chat This sounds like bug 657249. > * closing the window removes the conversation from the tray So, what's the behaviour and lifecycle you expect tray conversations to have? I don't believe I've ever seen this spelled out; the behaviour just kind of haphazardly accumulated. At present, we have: • When the local user double-clicks a contact in the Contact List, or starts a chat with them from Gnome Contacts, both a tray conversation and an Empathy window open. (I believe currently the former pops up at you; it could be changed to just quietly appear in the tray, or not appear in the tray at all.) • When you receive an incoming message and no conversation is currently open, a tray conversation appears. • Clicking in the body of a tray conversation opens an Empathy tab, and leaves the tray conversation open. • Closing an Empathy tab closes the corresponding tray conversation. As an implementation detail, the presence or absence of a tray conversation corresponds 1–1 with the presence or absence of a Channel object on D-Bus. This needn't necessarily be the case (cf. Empathy, which happily keeps tabs open when you disconnect and the Channel objects all disappear; it's a smidge harder to see how opening conversations works when you're disconnected but there's another question).
I just stumbled upon bug 657278 which really boils down to the same question, I think.
In general the way the Message Tray is supposed to work is that each item is the "background" task for a front-end app. Usually a real app. Take Rhythmbox for example. When Rhythmbox is started it is weird to show both the main RB window and a tray item for it. That doesn't make sense and causes the user to be conflicted. With one big caveat: the chat is now a service in a way that music is not. In the case of Chat we don't have a good story in part because we don't have https://live.gnome.org/Design/Apps/Chat. But in the near term we can do better than we currently do with Empathy. The app for chat until we design the new Chat app is Empathy. It is the foreground version of the shell's Message Tray chat. When the Empathy window for a specific conversation is in the foreground we should not see the background Tray version. However, when I don't see the conversation window I expect to get notifications for updates to that (ongoing) conversation. These messages should remain in the Tray until I see them and then for a certain amount of time after that (to be determined) at which point we deem the conversation to have lapsed. Unless the conversation is pinned to the Tray. The difference between Music and Chat here is, as mentioned above, that Chat is a service. We don't sign the user out when the chat app/window is closed. Similarly we shouldn't deem the current ongoing conversation to be finished. Especially since that isn't indicated or expected on the other end of the conversation. That said we do need a way to ignore further updates to a conversation. My mom is really a pain sometimes. We often disagree on when a chat is over. It would be best to have a way to not be notified of updates to the conversation. Again "conversation" being a time limited scope. So, basically closing the chat app window should move all further interaction to the Tray until the conversation is complete.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.