After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 739148 - search: use g_get_system_data_dirs() to discover providers
search: use g_get_system_data_dirs() to discover providers
Status: RESOLVED FIXED
Product: gnome-control-center
Classification: Core
Component: Search
unspecified
Other All
: Normal normal
: ---
Assigned To: Cosimo Cecchi
Control-Center Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-10-24 20:59 UTC by Cosimo Cecchi
Modified: 2014-10-27 20:39 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
search: use g_get_system_data_dirs() to discover providers (6.96 KB, patch)
2014-10-24 20:59 UTC, Cosimo Cecchi
needs-work Details | Review
search: use g_get_system_data_dirs() to discover providers (8.47 KB, patch)
2014-10-26 17:35 UTC, Cosimo Cecchi
needs-work Details | Review
search: use g_get_system_data_dirs() to discover providers (8.43 KB, patch)
2014-10-27 16:48 UTC, Cosimo Cecchi
committed Details | Review

Description Cosimo Cecchi 2014-10-24 20:59:01 UTC
See attached patch
Comment 1 Cosimo Cecchi 2014-10-24 20:59:03 UTC
Created attachment 289296 [details] [review]
search: use g_get_system_data_dirs() to discover providers

Currently, the search panel looks for search providers in
DATADIR/gnome-shell/search-providers. This won't work when providers are
located in a different directory which is still part of XDG_DATA_DIRS,
which is a valid use case and supported by gnome-shell.

This commit refactors the loader code to scan all the directories
upfront in a separate thread.

[endlessm/eos-shell#4049]
Comment 2 Bastien Nocera 2014-10-25 16:55:52 UTC
Review of attachment 289296 [details] [review]:

Is the endless bug available publically? If not, please remove it, if it is, please put the full URL.

::: panels/search/cc-search-panel.c
@@ +572,3 @@
+   */
+  search_panel_propagate_sort_order (self);
+  g_list_free_full (providers, g_object_unref);

Unref in the loop above?

@@ +605,1 @@
+      if (error != NULL)

Need to handle the cancelled case.

@@ +620,3 @@
+        }
+
+      if (error != NULL)

Ditto.

@@ +641,3 @@
+  GTask *task;
+
+  task = g_task_new (self, NULL, search_providers_discover_ready, self);

Looks like the thread isn't cancellable, which is going to make it crash when leaving the panel before the thread has finished the enumeration.
Comment 3 Cosimo Cecchi 2014-10-26 17:35:09 UTC
Created attachment 289357 [details] [review]
search: use g_get_system_data_dirs() to discover providers

--

Thanks for the review - this should address your comments.
Comment 4 Bastien Nocera 2014-10-27 14:51:32 UTC
Review of attachment 289357 [details] [review]:

::: panels/search/cc-search-panel.c
@@ +558,2 @@
+  providers = g_task_propagate_pointer (G_TASK (result), &error);
+  g_clear_object (&self->priv->load_cancellable);

You can't access the user_data before checking that the cancellable isn't cancelled.

@@ +651,3 @@
+        }
+
+    cleanup:

A label inside a for loop is pretty gross. Could you split out the contents of the loop into a separate function so that this sort of construct isn't needed. Even using a macro would probably be nicer than this.

@@ +676,3 @@
+
+static void
+cc_search_panel_dispose (GObject *object)

Can't this be done in finalize() instead? Is there a cyclical reference somewhere?
Comment 5 Cosimo Cecchi 2014-10-27 16:48:15 UTC
Created attachment 289471 [details] [review]
search: use g_get_system_data_dirs() to discover providers

--

Address comments from review
Comment 6 Cosimo Cecchi 2014-10-27 16:50:04 UTC
(In reply to comment #4)
 
> You can't access the user_data before checking that the cancellable isn't
> cancelled.

Fixed, but it shouldn't really matter - see below.
 
> A label inside a for loop is pretty gross. Could you split out the contents of
> the loop into a separate function so that this sort of construct isn't needed.
> Even using a macro would probably be nicer than this.

You're right, code becomes much nicer - fixed.

> +
> +static void
> +cc_search_panel_dispose (GObject *object)
> 
> Can't this be done in finalize() instead? Is there a cyclical reference
> somewhere?

Yeah; g_task_new() will take a reference to the panel itself for the duration of the task, so canceling from finalize() is too late.
Comment 7 Bastien Nocera 2014-10-27 20:23:14 UTC
Review of attachment 289471 [details] [review]:

Looks good.
Comment 8 Cosimo Cecchi 2014-10-27 20:39:04 UTC
Thanks, pushed now

Attachment 289471 [details] pushed as 0a7b552 - search: use g_get_system_data_dirs() to discover providers