GNOME Bugzilla – Bug 711833
Did I successfully connect?
Last modified: 2021-06-10 11:05:08 UTC
I connected to the server successfully I think, but there was no indication that I did so, such as a success message or an offer to join a channel.
Hi! I am interested in solving this bug. I am trying to contribute for the first time. What should the solution be? A. Topbar (like gitg) showing upon successful connection to a network B. A simple GTK window upon successful connection.
I believe the connection to the server itself is uninteresting. What matters is the connection to the chat room. So instead of building UI around connecting to servers, I think we need to revisit the 'join a room' interface and allow to maintain servers in there as well.
(In reply to comment #2) > I believe the connection to the server itself is uninteresting. I agree. (In reply to comment #1) > Hi! I am interested in solving this bug. I am trying to contribute for the > first time. > > What should the solution be? > > A. Topbar (like gitg) showing upon successful connection to a network > B. A simple GTK window upon successful connection. Neither of those look very compelling to me - polari tries to restore all previously open rooms on startup, so the expected case would be that you have to click away a couple of dialogs/infobars every time you start the app. So my take would be to address bug 710271 and bug 709846 first, and then use UI like an infobar for the error case.
Yea. We need some connection indicator that would communicate chatroom status (connecting, disconnected). Here's my initial stab at the workflow for connecting to channels: https://raw.github.com/gnome-design-team/gnome-mockups/master/polari/connections.png
(In reply to comment #4) > Yea. We need some connection indicator that would communicate chatroom status > (connecting, disconnected). Ha! First we need to actually keep disconnected rooms open :-) > Here's my initial stab at the workflow for connecting to channels: > > https://raw.github.com/gnome-design-team/gnome-mockups/master/polari/connections.png How should we handle connections that exist but are disabled? Do we need some shortcut to the connection list? Or should we just show all connections and just enable them as necessary?
I just pushed an initial (and incomplete) implementation[0], feedback welcome :-) [0] https://git.gnome.org/browse/polari?h=join-dialog-refresh
(In reply to comment #6) > [0] https://git.gnome.org/browse/polari?h=join-dialog-refresh Looks good to me :)
Created attachment 265769 [details] [review] joinDialog: Update combobox on account changes Currently the connection combobox shows the list of accounts that were available when creating the join dialog. However we will soon allow to add new connections from within the dialog itself, so we need to track changes in the list of available accounts to pick up the additions.
Created attachment 265770 [details] [review] ui: Update connection details dialog Update the UI according to latest mockups: - replace section titles with whitespace - update content margins - make dialog buttons part of the content grid These changes will make it easier to re-use the UI in the join dialog to allow adding new connections directly from within the dialog.
Created attachment 265771 [details] [review] ui: Update join dialog Update the UI according to latest mockups: - use custom titlebar - replace section titles with whitespace - update content margins - make dialog buttons part of the content grid These changes will allow extending the UI to support creating new connections from within the dialog.
Created attachment 265772 [details] [review] ui: Update message-user dialog Update the UI to make the dialog again consistent with the join dialog: - use custom titlebar - replace section titles with whitespace - update content margins - make dialog buttons part of the content grid
Created attachment 265773 [details] [review] connections: Handle creating/updating accounts in details dialog Currently accounts are created/updated by the connection list in response to the details dialog, but we will soon allow to create connections from the join dialog as well, so move the handling to the code that will be shared between both dialogs.
Created attachment 265774 [details] [review] connections: Split out connection details The join dialog will gain an option to create new connections from within the dialog. In order to reuse the existing code from ConnectionDetailsDialog, split out a ConnectionDetails class which can be shared between the two dialogs.
Created attachment 265775 [details] [review] joinDialog: Support adding new connections from within the dialog For IRC which does not have a real presence concept, setting up server connections is a requirement for being able to join a room, but not very interesting on its own; therefore it makes sense to allow users to set up the required server connections when joining a room if necessary, keeping the focus on the primary task rather than requiring them to hunt down the connection editor first.
Created attachment 265776 [details] [review] app: Never disable room menu and join dialog Now that the join dialog allows adding new connections, it no longer makes sense to disable it when there are no active accounts.
(In reply to comment #7) > (In reply to comment #6) > > > [0] https://git.gnome.org/browse/polari?h=join-dialog-refresh > > Looks good to me :) Cool, thanks! Leaving the bug open, as the implementation of the mockups is not quite complete ... Attachment 265769 [details] pushed as 78657fc - joinDialog: Update combobox on account changes Attachment 265770 [details] pushed as 100c572 - ui: Update connection details dialog Attachment 265771 [details] pushed as 29930b6 - ui: Update join dialog Attachment 265772 [details] pushed as 94f3781 - ui: Update message-user dialog Attachment 265773 [details] pushed as c9702fe - connections: Handle creating/updating accounts in details dialog Attachment 265774 [details] pushed as 03765f5 - connections: Split out connection details Attachment 265775 [details] pushed as c83d578 - joinDialog: Support adding new connections from within the dialog Attachment 265776 [details] pushed as d7b5c65 - app: Never disable room menu and join dialog
Created attachment 283955 [details] [review] ui: Select last used account by default in dialogs Connections are currently ordered alphabetically with the first one selected when opening the dialog. While not arbitrary, this does not support users in joining the rooms they want as quickly as possible - remembering the last account used for joining a room and making it persistent has a higher chance of picking the account the user wants, so do that instead of always selecting the first one.
Created attachment 283956 [details] [review] ui: Move initial focus to name entry Since we no longer select a "random" account when opening the join/message dialogs, there's a higher chance that we already selected the correct account and the user can just enter the name and confirm - to make this easier, put the initial focus on the name entry.
Attachment 283955 [details] pushed as b92901f - ui: Select last used account by default in dialogs Attachment 283956 [details] pushed as 6e5543f - ui: Move initial focus to name entry Still missing bits from the design, so not closing quite yet ...
I think the initial experience would benefit from having a default server filled in. irc.gnome.org==GNOME would be my suggestion. Right now we depend on people understanding the concept of IRC servers to start chatting.
I was considering importing empathy's excessive list of IRC networks[0] for entry completion (I refuse to add a combobox or similar for that beast!), but your suggestion sounds a lot simpler ... [0] https://git.gnome.org/browse/telepathy-account-widgets/tree/tp-account-widgets/irc-networks.xml
I think what we have is not enough. I feel like I'm gaffer tape suggesting here, but what about putting a spinner next to the channel name in the headerbar when you're still connecting?
In addition to the spinner in the app menu and the in-app notification?
(In reply to comment #23) > In addition to the spinner in the app menu and the in-app notification? The biggest issue I see is when a previous session is being restored. In-app notifications rarely show up for me in this case (I do sometimes see them). The app menu spinner sounds like it should be enough, but i find it lacking. Either the sidebar, text entry or the headerbar seem like where my focus is when I try typing in the channel that isn't really ready for my input..
*** Bug 755583 has been marked as a duplicate of this bug. ***
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 of Polari, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/polari/-/issues/ Thank you for your understanding and your help.