GNOME Bugzilla – Bug 599184
Add ability to close a muc window without leaving it
Last modified: 2018-05-22 13:47:28 UTC
This probably requiere some improvement in the spec.
*** Bug 601238 has been marked as a duplicate of this bug. ***
*** Bug 575094 has been marked as a duplicate of this bug. ***
(In reply to comment #0) > This probably requiere some improvement in the spec. I wonder how much trouble this would be considering the MUC isn't located in the dbus system... It would be an huge UI improvement for the IRC part of empathy to get this working though...
I believe the user experience for this should be: -Allow rooms to be added to the contact list. -Have it show the #channel if you are joined. -BOLD the channel if there's chat waiting to be read -Blink the channel and give an alert if your nickname is said in chat I believe all the puzzle pieces for making this happen is there. Just needs to be put together. I.e. nothing new to be designed.
Brian: Sounds interesting, even beyond just IRC, into MUC... have a more consistent behavior like chats. If you could be "in" a room without having a window open, you'd have a queue of messages you could open later, and then scroll back and see what happened. Very strongly +1.
Bug #601162 is about putting rooms in the contact list. There are few issues to solve here: - What should we do when the muc windows is closed? We currently leave the rooms, if we change that behaviour I expect to see lot of confused people. - If we keep the current behaviour how can we close a muc window without leaving channels? Having a setting could *maybe* make sense but then how do we leave a room if we have configured empathy to not leave rooms when closing the window. By closing the *tab*? - How would we display rooms once their window have been closed but we are still in it? Using the contact list could make sense. Having a "Room" special group could do it. - We need to be able to show at least these different states: a) We are *not* in the room (assuming we want to display favorites rooms as well). b) We are in the room but have read all the messages c) We are in the room and there are unread messages d) We are in the room and there are unread messages addressed to us We could do something like: a) display the name of the room greyed b) display it normally c) display it in bold d) display it in bold + blink the "new message" icon (as we do for pending 1-1 chat messages). Nick: any smart idea here? Any feedback is welcome.
*** Bug 601162 has been marked as a duplicate of this bug. ***
My real issue with this behavior is that of several chats being tied to a single server connection. When I close the window, I really want the server connection to go away, just like a traditional IRC client. When I connect to the server, I want that window to show up. Then, closing/opening tabs should leave/join channels respectively, but closing the *window* becomes a different behavior than closing each of the tabs in sequence. (In particular, an IRC bouncer-proxy can allow the client irc connection to disconnect, but maintain a presence in each room). That said, maybe the issue is more about being able to *hide* chats instead of closing them. I'd like to be in a number of channels, whether they're IRC or xmpp MUC or MSN or something else.... but I don't neccesarilly want it to be front-and-center all the time. I'd like to be able to throw a chat room, or a whole window full of chats, into a hidden state somewhere. That way I it's out of the way, but I'm still there if people look for me, and I still get notifications if my nickname is mentioned.
My 50 pence from #empathy, broken down into a hypothetical 30 pence piece and two 10 pence pieces: • conversation window tabs already resemble contact list entries. So if MUCs end up in the roster, their visual representation in the various states should be very similar/the same in both places. • relatedy, I would like contacts' status messages in conversation windows. • relatedly, you know how MUCs' topics are shown in conversation windows? ... :) My inexplicable 10 Australian cents I found in my pocket yesterday: Leave group chats: (o) when I close the tab or window. ( ) only when I choose “Leave chat” from the menu. | Conversation | Contact Edit Tabs Help | ... | | ... | | -------------------- | | Leave chat | | Close Ctrl-W | +----------------------+ IANAUID
(oh yeah and why is there a Contact menu in my group chats?)
I agree with Jeremy's second paragraph. My issue is less clutter on the screen while being able to idle in MUC's. -use contact entries as channel entries, if you're in the channel it shows as online, if you're not in the channel it shows as offline. This would remove the need for the favorite chat room menu, we'd assume favorite chat rooms are the ones put on the contact list. Non favorite channels wouldn't show up in buddy list but act as we currently have it, where the window shows, and upon closing it removes you from channel. Please let me know of any other use cases that may cause problems and I'd be happy to offer my opinion on it. Also, the people who would be working on this feature, I would like some hands on experience with the empathy code, and if it's alright I'd like to work with you on implementing this feature.
*** Bug 628245 has been marked as a duplicate of this bug. ***
Related to bug 591756, which requests a confirmation dialog on closing a MUC. Maybe that dialog should have an option to "hide" the chat, or should just hide by default anyways.
I had a conversation regarding this particular bug with the usability team which thought better of it and came up with <a href="https://gitorious.org/gnome-design/gnome-design/blobs/master/mockups/empathy/conversation-view.png">this</a> mock- up for chat window. This mock-up simplifies the UI. It requires major redesigning which will automatically address this bug and many related ones and will move them into WONTFIX category. Again, in addition we can have separate "Rooms" group to keep chat-rooms organized and for rooms, in case of members being shown as icons on the top(as shown in this PMUC), we should have another scrollable tree-view for holding them on the right end of the chat window as their number could get quite large.
Chandni: Could you clarify what this UI is supposed to represent? 1) Is it replacing the entire "contact list" window with this new sort-of-tabbed interface? 2) It's a little awkward to have the window title vary depending on what's selected inside it? 3) No seperate windows for chats anywhere? Maybe allow "detaching" of internal dialogs, sort of how xchat allows it? 4) Is there a tracking bug for this redesign and its implementation, as well as these and other issues? Looks like a bold change, that might be quite powerful, if I understand it right :)
(In reply to comment #15) > Chandni: Could you clarify what this UI is supposed to represent? > Allan has updated the link above with a rethought version of it which is precisely annotated. > 1) Is it replacing the entire "contact list" window with this new > sort-of-tabbed interface? > yes > 2) It's a little awkward to have the window title vary depending on what's > selected inside it? > I agree, if the selected conversation is highlighted as shown > 3) No seperate windows for chats anywhere? Maybe allow "detaching" of internal > dialogs, sort of how xchat allows it? > can be done, using gdk drag-n-drop interfaces but avoiding it was the reason to create this design anyways. > 4) Is there a tracking bug for this redesign and its implementation, as well as > these and other issues? > except this one, i don't know > Looks like a bold change, that might be quite powerful, if I understand it > right :)
Tbh I'm tempted to put this on hold until we have a clearer idea of what an hypothetical Conversation app would look like: https://live.gnome.org/Hackfests/IMContacts%20Social2011/Tasks/ConversationDesignBrainstorming
*** Bug 661183 has been marked as a duplicate of this bug. ***
*** Bug 667842 has been marked as a duplicate of this bug. ***
now i have a question the bug reported 2 years ago but until now no one fixed it! why?
Bijan: Please read the "No obligation" part of https://bugzilla.mozilla.org/page.cgi?id=etiquette.html . Patches are welcome.
(In reply to comment #20) > now i have a question > the bug reported 2 years ago but until now no one fixed it! > > why? Mostly because we still don't have a good design for this. If some designer wants to give it a try I'd be happy to help him.
Ok what is your mean from design. i think (might not true) it is a clear issue you just need to add an option that unshow the window also you can use my idea in https://bugzilla.gnome.org/show_bug.cgi?id=667842 thanks for your feedback
My 5 cents: I think those many feature requests was inspired by Pidgin which supports this feature. It works this way: - An user add a chat as a special contact into his rooster. In settings for the new contact she can choose to auto-join or "Remain in chat after window is closed." Screenshot: http://i.imgur.com/AILKk.png - The user must enter the room either by manual or auto-join to be in the chat. - Given "remain in chat" option, the user stays in the chat until she leaves the chat ultimately -- disable the account for chat, shutdown pidgin or using /quit command - The chat works normally although no window is shown: * the user is present in the chat * all messages are logged * after opening the chat window, all logged messages from the current session are shown -- there is no difference if window was shown or hidden * if somebody mentions the user, the notification is shown The proposed redesign of Empathy might be very cool. However, it would be too big change to satisfy the need for Pidgin's feature. Although Empathy doesn't support chats as special contacts, there is concept of favorite rooms: http://i.imgur.com/ayM7v.png Another option to favorite rooms could be added which would have the same meaning as "Remain in chat" from Pidgin: http://i.imgur.com/Or3fN.png Semantics of the option should be the same as in Pidgin.
Thanks for the explanations. I have a few concerns so I'd like to get some input from designers before considering implementing this: - I'm not a fan of making the contact list treeview code even more complicated (it's already a real pain) to display rooms as well. Especially now that we are considering to make it simpler (see bug #669484) - In GNOME 3 the Shell is responsible of displaying the chat notifications but it currently only support private chats, not group ones. We may have to add room support if we want to display notifications. Actually I'm wondering if this wouldn't fit better with the vague 'Conversation' app plan we already discussed: https://live.gnome.org/Hackfests/IMContacts%20Social2011/Tasks/ConversationDesignBrainstorming
(In reply to comment #25) Agree that this feature would require a conversation list - if you close a conversation window there needs to be a way to get back to it, and there needs to be a place you can go to see the status of your various conversations.
Maybe fits in with bug #631945?
Similar bug in telepathy: https://bugs.freedesktop.org/show_bug.cgi?id=24614 And downstream ubuntu: https://bugs.launchpad.net/libtelepathy/+bug/732688
This is still an issue in the new Polari world: - Connect an IRC account in Polari - Channels are handled by Polari - Close Polari - MC redispatches the channels to empathy-chat - "WTF I don't want these channels here" -> close the window - All the channels have been left :( That's because Empathy calls tp_channel_leave_async() when destroying the chat. I can't think of any way to fix that without breaking the "non proxy" mode, as in this case we do want to leave the channel when closing the window. Maybe the solution is just to add an Account specific "IRC bouncer" boolean option?
Humm actually this may not even be enough to fix this problem. Assuming we close the channel without leaving, it will be respawned by Idle and re-dispatched by MC invocating Polari or gnome-chat. Maybe Polari should enable and connect IRC accounts when starting and disabling them when leaving. That would be closer to the usual IRC client behaviour but will kinda break the "accounts are clients agnostic" model in Telepathy.
(In reply to comment #30) > Humm actually this may not even be enough to fix this problem. Assuming we > close the channel without leaving, it will be respawned by Idle and > re-dispatched by MC invocating Polari or gnome-chat. Let's turn this around. Why do you want to stay in the channel, with no UI presented to you? My best guess is one of these: * I don't really want to stay connected to my bip/bouncer, but I do want the bip/bouncer to stay in the channel on my behalf. I'll pick up my messages later. -> -either- (a) Polari should disconnect from IRC without leaving the channels (cf. https://bugs.freedesktop.org/show_bug.cgi?id=70427) -or- (b) something should pass the frequently-proposed "this is a bip/bouncer" flag to Idle, resulting in Close() not actually leaving; and Empathy/Polari should be careful to only call tp_channel_leave_async() if the user has expressed a positive intention to *leave*, and not just because they're disconnecting or have closed a window (c): variant of (b): in fact, now I think about it, one possibility is for Close() to *always* work in "this is a bouncer" mode, with the channel not respawning until someone actually says something - at which point maybe an Approver could be configured to either do a notification-bubble immediately, or keep quiet until someone says something highlight-worthy, depending how interested we are in this particular channel. * I want to stay connected, but I only want notifications when something "interesting" happens (a PRIVMSG or a mention of my nick / something else I have a highlight for) -> -either- (c) see (c) above -or- (d) Polari should DelegateChannels() to whatever separate process is responsible for those notifications > will kinda break the "accounts are clients agnostic" model in Telepathy Telepathy does what UIs need. If UIs need something different, we can change Telepathy. Having said that, large parts of the point of Telepathy (and particularly Mission Control) are that it shares a connection between multiple clients, and that it abstracts across similar concepts in distinct protocols (like IRC channels vs. XMPP rooms). If Polari doesn't want either of those, we need to know what benefit it *is* getting, so we can make sure that's preserved by whatever solution we come up with.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/empathy/issues/131.