GNOME Bugzilla – Bug 600695
RFE: address empathy bad behavior for disabled accounts
Last modified: 2018-05-22 13:50:33 UTC
If an account happens to be disabled and I indicate I want to join a channel/room affiliated with it, it ignores my request. I would rather one of the following to happen instead, in order of most-desired to least-desired behavior: Account is disabled, user indicates they want to join a room affiliated with that account: - Account is enabled automatically and user is allowed to join the room. - Dialog pops up saying, 'That room is affiliated with disabled account foo@bar.org. Would you like to enable the account and join the room now? (Yes / No)' - Dialog pops up saying, 'That room is affiliated with disabled account foo@bar.org. You need to go to your account preferences and re-enable the account before you can visit this room.' Original bug: https://bugzilla.redhat.com/show_bug.cgi?id=532074
I think I'd prefer the second solution.
What should happen if connecting an account fails after enabling it, due to any of the many possible errors? Should the dialog not get destroyed immediately and maybe a spinner be shown on it while connecting it and propose a 'reconnect' on faliure along with the error?
That sounds like a good idea yeah.
Created attachment 179446 [details] [review] Confirming dialogs to enable/connect a disabled/disconnected account. This patch contains confirmation dialogs to enable/connect a disabled/disconnected account whose affiliated chat room is wished to join. If an account has a connecting error after this, then they will become visible on the GtkInfoBar above the roster as usual so no problem there.
Oops, I didn't notice your response over my last comment before working on this. If this one's not satisfactory (though it seems to work nicely) i'll make the persistent dialog mentioned above.
I felt persistent dialogs might look ugly and unnecessary in case there are many favorite rooms and 'Join Favorites' is clicked and took this approach. Branch for this patch : http://gitorious.org/glassrose-gnome/empathy/commits/enabling-account-for-joining-chatroom-if-disabled-600695
Review of attachment 179446 [details] [review]: I think I'd display the account icon in the dialog. That's a convenient way to quickly identify an account. We like verbs on buttons in GNOME. It should be [Cancel] [Connect and Join] or something instead of yes/no. I'm wondering if this would look better as a contact list infobar rather than a dialog, but we can change later if needed. ::: src/empathy-main-window.c @@ +1260,3 @@ + return; + } + join_chatroom (chatroom, gtk_get_current_event_time ()); You should pass the time when the "join" event has been triggered. @@ +1269,3 @@ + join_fav_account_sig_ctx *ctx; + GtkWidget *dialog; + gint response; ctx and response should be defined in the block where they are used. @@ +1277,3 @@ + enabled = tp_account_is_enabled (account); + + if (enabled && tp_account_get_connection_status (account, NULL) == Please store the result of get_connection_status() in a variable. It would make things easier to read.
I liked on the idea of having info-bars and have changed my branch to accommodate them. There are some touches needed still but I wanted to have your say on the direction. http://gitorious.org/glassrose-gnome/empathy/commits/enabling-account-for-joining-chatroom-if-disabled-600695 In this approach, I have mapped EmpathyChatrooms to infobars. But there was another bug (I guess) which was causing the favorite EmpathyChatroom objects to be deleted and new ones created without the user making any change (adding or removing from favorite rooms list). This caused me to stop and ask. There were G_FILE_MONITOR_EVENT_CHANGES_DONE_HINT type events generated on the file which would be saving the favorite rooms, out of nowhere. Thus, if such an event is generated between 2 successive clicks for the same chat-room, a new infobar is created and the older ones become function-less. Is what I have noticed an actual bug needing treatment or design decision already known to you? If a planned design then I am going wrong somewhere and need your advice.
Your branch does't apply on top of master. I'm not convinced we should have an infobar in the contact list. If any, it should be in the chat-window infobar, but that means we should create it before having the channel, which may involve some none trivial design changes.
Empathy is always changing, so changes are not a problem. :) Oh my branch's second patch is in a file that has been substantially changed in the master. If just the 1st patch is tried, I am sure, it'll work, but as you said about having infobars in chatrooms, I should work over it afresh. I still feel that the problem where disconnected chatrooms are destroyed and recreated by the chatroom manager out of the blue when G_FILE_MONITOR_EVENT_CHANGES_DONE_HINT type events occur, will still cause a problem and the shown disconnected chatrooms will become unstable. Is that an actual error? The order of the favorite chatrooms is also changed in Room menu's menuitems whenever this happens( https://bugzilla.gnome.org/show_bug.cgi?id=642087 ).
-- 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/140.