GNOME Bugzilla – Bug 305518
find a location easily with a text field
Last modified: 2005-07-01 12:45:07 UTC
in the weather applet, some locations are not directly under their country, but are located under a regionan area, so to find it you need to know it's regional location; it not very easy to find. Take the example of Stuttgart, I had to find it under Baden-Wurttemberg. I think this could improve using a text field that could filter the treeview following the text entered. The other way could follow what gconf-editor do.
There's already type-ahead search ... so I don't see why some extra search function is needed.
I tried the type-ahead but you need to expand the treeview. and you should know in which subsection is located the city you search. Not an optimal behaviour.
I will accept a patch to implement this. The obvious way with the existing UI is to have a text box you can type in, with a Next button that appears when there are more matches. Alternatively, perhaps we should rethink the UI for selecting location to make it a little more obvious.
Meanwhile the UI guys are thinking on a better way for selecting locations, I'm currently working on a location finder in the current tree. I will post it as soon as I've got it finished (currently the find works but it needs some GUI love) It's my first contribution to GNOME so I will apreciate some feedback and corrections about coding and style, so be prepared :P
Created attachment 48369 [details] [review] Proposed patch
The patch looks good, but I think there are some issues: + do { + gtk_tree_model_get (model, iter, GWEATHER_PREF_COL_LOC, &aux_loc, -1); + n_childs = gtk_tree_model_iter_n_children (model, iter); + + if (g_ascii_strncasecmp (aux_loc, location, len) == 0) { + return TRUE; + } + + if (gtk_tree_model_iter_has_child (model, iter)) { + gtk_tree_model_iter_nth_child (model, &iter_child, iter, 0); + + if (find_location (model, &iter_child, location, FALSE)) { + /* Manual copying of the iter */ + iter->stamp = iter_child.stamp; + iter->user_data = iter_child.user_data; + iter->user_data2 = iter_child.user_data2; + iter->user_data3 = iter_child.user_data3; + + return TRUE; + } + } There is a leak here. The aux_loc variable should be freed in every loop iteration and when you are breaking the loop too. +static void +find_entry_activated (GtkButton *button, GdkEventKey *event, gpointer data) The widget that received the signal is not a GtkButton but a GtkEntry. I think it's better to use the changed signal of the GtkEditable interface instead of the key-release-event. + if (gtk_tree_selection_count_selected_rows (selection) >= 1) { + gtk_tree_selection_get_selected (selection, &model, &iter); + } else { + gtk_tree_model_get_iter_first (model, &iter); + } I think you should always start searching at the top of the tree, because in this way you will be able to delete the text and start searching again. + gtk_box_pack_start (GTK_BOX (pref_find_hbox), gw_applet->pref_find_entry, FALSE, FALSE, 0); The entry should be expandable. Thanks for the patch :-)
Created attachment 48382 [details] [review] Proposed patch (reviewed)
Marking with high priority so that I don't lose this bug. I'll try and review this tonight.
This patch appears to be malformed. Any chance of getting an updated one?
Never mind. Fixed it up with `rediff`. 2005-07-01 Esteban Sanchez <esteban@steve-0.com> * gweather.h (struct _GWeatherApplet): Added pref_find_entry and pref_find_next_btn * gweather-pref.c: (gweather_pref_create): Added a find bar to the location page. Fixed bug #305518