GNOME Bugzilla – Bug 588243
Pre-defined IRC channel list is way too long
Last modified: 2010-08-26 12:03:38 UTC
When creating a new IRC account, the list of defaults intimidating and most seem very obscure. Furthermore, we may not want to associate ourselves with a few of them (eg, 2600net, which I believe is mostly about warez). At the risk of sounding like "640k ought to be enough for anybody", how about something like: * Freenode * GIMPnet * Debian servers * Ubuntu servers * EFNet * <some other ones I don't realize are actually popular> We would need to be careful to do this in a way such that we won't break existing accounts if it's no longer in the default list. If we already copy the details upon account creation, we should be fine, of course.
The list of servers comes from xchat. But I agree we should clean it a bit. Also the current UI does not scale well. I hate scrolling GtkMenu.
Yeah, I imported them from Xchat. Removing some from the presets list shouldn't break existing accounts, the code can deal with that. Do you have any heuristic and/or resources we could use to determine the list of networks we should keep?
(In reply to comment #2) > Yeah, I imported them from Xchat. Removing some from the presets list shouldn't > break existing accounts, the code can deal with that. > > Do you have any heuristic and/or resources we could use to determine the list > of networks we should keep? > Popularity seems like the best metric. I'd just go with the top N popular networks according to this: http://searchirc.com/networks (see the right side and note that each group is non-cumulative). Maybe N should be 15 or 20? And it may be worthwhile to add a comment into the file pointing to this justification and the stats page above.
Travis: sounds like a good idea to me. Would be nice too to check the servers used by FOSS projects: GNOME: GIMPNet Ubuntu/Telepathy: FreeNode ...
I'm a big fan of find-as-you-type as a way to browse massive lists. Maybe the Network: picker should become a button you press which opens a new dialog, looking something like: +------------------------------------+ | Select a network: | +------------------------------------+ | [ Search... ] | | Freenode /|\| | OFTC | | | ... | | | ... \|/| | [ Add ] [ Edit ] [ Remove ] [ Use ]| +------------------------------------+ (IANAUID.)
I like that idea. I like it so much that I implemented it :) It's pretty awesome thanks to the live-search support. http://git.Collabora.co.uk/?p=user/cassidy/empathy;a=shortlog;h=refs/heads/irc-widget-588243
Created attachment 168714 [details] [review] http://git.Collabora.co.uk/?p=user/cassidy/empathy;a=shortlog;h=refs/heads/irc-widget-588243 libempathy-gtk/Makefile.am | 4 + libempathy-gtk/empathy-account-widget-irc.c | 405 +-------------- libempathy-gtk/empathy-account-widget-irc.ui | 78 +--- .../empathy-irc-network-chooser-dialog.c | 557 ++++++++++++++++++++ .../empathy-irc-network-chooser-dialog.h | 70 +++ libempathy-gtk/empathy-irc-network-chooser.c | 357 +++++++++++++ libempathy-gtk/empathy-irc-network-chooser.h | 61 +++ libempathy/empathy-irc-network-manager.c | 34 ++ libempathy/empathy-irc-network-manager.h | 2 + libempathy/empathy-irc-network.c | 16 + libempathy/empathy-irc-network.h | 4 + 11 files changed, 1129 insertions(+), 459 deletions(-)
first review (only testing it, no code review yet) I get many criticals. it happens when the live search is cleared with the backspace key and not with escape: (empathy-accounts:3597): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed after a search (searched then cleared the search) no entry is selected. the result is: when closing the dialog (either by hitting escape or pressing close) also the accounts dialog closes and following assertion fails: ERROR:empathy-irc-network-chooser.c:126:update_server_params: assertion failed: (priv->network != NULL) apart from that, imho the ui is not that intuitive. since I have to select a server and then hit the close button. I would prefer something like "select" or "choose". When the title would be something like "choose an IRC network" it would be more intuitive to have a choose or select or apply button. I would prefer to have the choose, select, apply button separated from the add, remove, edit buttons, since they have a very different purpose. what do you think of two rows of buttons? the add, edit and remove buttons are immideately below the treeview and the select, apply, choose button is one row below. Just a proposal.
(In reply to comment #8) > first review (only testing it, no code review yet) > > I get many criticals. it happens when the live search is cleared with the > backspace key and not with escape: > (empathy-accounts:3597): GLib-GObject-CRITICAL **: g_object_unref: assertion > `G_IS_OBJECT (object)' failed I can't reproduce this any more. Maybe it has been fixed as a side effects of my new commits? Can you retry please? > after a search (searched then cleared the search) no entry is selected. the > result is: when closing the dialog (either by hitting escape or pressing close) > also the accounts dialog closes and following assertion fails: > ERROR:empathy-irc-network-chooser.c:126:update_server_params: assertion failed: > (priv->network != NULL) Good catch. Now can't close the dialog if there is no network selected. > apart from that, imho the ui is not that intuitive. since I have to select a > server and then hit the close button. I would prefer something like "select" or > "choose". When the title would be something like "choose an IRC network" it > would be more intuitive to have a choose or select or apply button. I changed the title of the dialog and the label of the button. > I would prefer to have the choose, select, apply button separated from the add, > remove, edit buttons, since they have a very different purpose. what do you > think of two rows of buttons? the add, edit and remove buttons are immideately > below the treeview and the select, apply, choose button is one row below. Just > a proposal. I'll test and see how it looks.
I think I fixed all the issue you raised on IRC. I'll attach another diff.
Created attachment 168739 [details] [review] http://git.Collabora.co.uk/?p=user/cassidy/empathy;a=shortlog;h=refs/heads/irc-widget-588243 libempathy-gtk/Makefile.am | 4 + libempathy-gtk/empathy-account-widget-irc.c | 403 +------------- libempathy-gtk/empathy-account-widget-irc.ui | 78 +--- .../empathy-irc-network-chooser-dialog.c | 601 ++++++++++++++++++++ .../empathy-irc-network-chooser-dialog.h | 70 +++ libempathy-gtk/empathy-irc-network-chooser.c | 357 ++++++++++++ libempathy-gtk/empathy-irc-network-chooser.h | 61 ++ libempathy/empathy-irc-network-manager.c | 34 ++ libempathy/empathy-irc-network-manager.h | 2 + libempathy/empathy-irc-network.c | 16 + libempathy/empathy-irc-network.h | 4 + 11 files changed, 1172 insertions(+), 458 deletions(-)
From a non-code point of view two (related) things remain open: - when searching, selecting, and closing the search, it scrolls to the wrong position! I suspect that you use the path from the search and apply it to the original model. When I'm searching and select the third result, then close the search the third entry from top (somewhere around "a") is selected. - deleting does not work while searching, the only thing that happens is that the search closes, which would be fine if I would already be at the last search position, but thats issue #1
another thing I noticed: when deleting one network, it jumps over the next one instead of selecting the next one.
Review of attachment 168739 [details] [review]: I think I found the three issues I mentioned earlier. Can you please fix it and test if it resolves the issues. Apart from those three issues the branch looks fine ::: libempathy-gtk/empathy-irc-network-chooser-dialog.c @@ +348,3 @@ + gtk_widget_hide (priv->search); + + network = dup_selected_network (self, &iter); the search has to be hidden after the selected network has been duped, otherwise always the first network will be deleted, because hiding the search seems to cause the treeview to select the first element. @@ +358,3 @@ + + /* Select next network */ + if (gtk_tree_model_iter_next (GTK_TREE_MODEL (priv->store), &iter)) gtk_list_store_remove already sets the iter to the next valid row or invalidated if the last row was deleted, this causes the "jumping over the next element" behavior @@ +412,3 @@ + + /* Select first matching network */ + if (gtk_tree_model_get_iter_first (GTK_TREE_MODEL (priv->filter), the first matching network should only be selected if empathy_live_search_get_text is not empty. related to the problem when deleting a network.
(In reply to comment #12) > From a non-code point of view two (related) things remain open: > - when searching, selecting, and closing the search, it scrolls to the wrong > position! I suspect that you use the path from the search and apply it to the > original model. When I'm searching and select the third result, then close the > search the third entry from top (somewhere around "a") is selected. fixed. > - deleting does not work while searching, the only thing that happens is that > the search closes, which would be fine if I would already be at the last search > position, but thats issue #1 fixed. (In reply to comment #14) > @@ +358,3 @@ > + > + /* Select next network */ > + if (gtk_tree_model_iter_next (GTK_TREE_MODEL (priv->store), &iter)) > > gtk_list_store_remove already sets the iter to the next valid row or > invalidated if the last row was deleted, this causes the "jumping over the next > element" behavior I tried and it doesn't select anything :\
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.