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 694975 - Fix moving when mixing sorted and unsorted providers
Fix moving when mixing sorted and unsorted providers
Status: RESOLVED FIXED
Product: gnome-control-center
Classification: Core
Component: Search
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Cosimo Cecchi
Control-Center Maintainers
Depends on: 694974
Blocks:
 
 
Reported: 2013-03-02 01:31 UTC by Giovanni Campagna
Modified: 2013-04-02 19:48 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
search: don't keep the last panel last in the sort order (1.59 KB, patch)
2013-03-02 01:32 UTC, Giovanni Campagna
reviewed Details | Review
search: fix moving unsorted applications (4.56 KB, patch)
2013-03-02 01:32 UTC, Giovanni Campagna
reviewed Details | Review
search: don't keep the last panel last in the sort order (1.79 KB, patch)
2013-03-04 16:23 UTC, Giovanni Campagna
committed Details | Review
search: fix moving unsorted applications (4.79 KB, patch)
2013-03-10 18:03 UTC, Giovanni Campagna
committed Details | Review

Description Giovanni Campagna 2013-03-02 01:31:44 UTC
If you reset GSettings, or set to [], and then go to the search panel and try to move a provider that is not sorted explicitly, you'll see it jump at the beginning if moving up, and somewhere in between if moving down.

The patches here include a semantic change that needs coordination with gnome-shell. See bug 694974.
Comment 1 Giovanni Campagna 2013-03-02 01:32:12 UTC
Created attachment 237771 [details] [review]
search: don't keep the last panel last in the sort order

Previously, we kept the last panel in the configured order last,
after non configured ones. This created sort orders that did not
reflect the visual order, and caused problems when moving.
Comment 2 Giovanni Campagna 2013-03-02 01:32:25 UTC
Created attachment 237772 [details] [review]
search: fix moving unsorted applications

Search providers can either have an explicitly configured sort order,
or be in the default alphabetical order based on their name.
Previously, when moving we would always assume that all providers had
a sort order, so moving an unsorted provider would put at the top.
The right thing to do, instead, is to walk the list in visual order
and assign an appropriate sort order, that is then flushed to gsettings.
Comment 3 Bastien Nocera 2013-03-04 12:40:05 UTC
Review of attachment 237771 [details] [review]:

"when moving". When moving what? Please be more explicit, explain which sort of sort orders would be created in those cases.
Comment 4 Bastien Nocera 2013-03-04 12:42:56 UTC
Review of attachment 237772 [details] [review]:

I'd need far more coffee to review that.

::: panels/search/cc-search-panel.c
@@ +250,1 @@
+  /* For simplicity, first set all sort orders to the previously visible state,

"For simplicity's sake, set all sort orders to the previously visible state first,"
Comment 5 Giovanni Campagna 2013-03-04 16:23:52 UTC
Created attachment 238009 [details] [review]
search: don't keep the last panel last in the sort order

Previously, we kept the last panel in the configured order last,
after non configured ones. This would assign the last panel
a sort order in the hash table that would place it in the middle,
but visually sort it last, and that caused problems when moving
it (it would jump into an apparently random position in the middle,
according to the sort ID, and would move the nearby provider too).
Comment 6 Bastien Nocera 2013-03-05 10:57:52 UTC
Review of attachment 238009 [details] [review]:

"This would assign the last panel a sort order"
should be:
"This would assign a sort order to the last panel"

Looks fine to commit after that.
Comment 7 Bastien Nocera 2013-03-05 11:11:39 UTC
Review of attachment 237772 [details] [review]:

::: panels/search/cc-search-panel.c
@@ +262,2 @@
     {
+      idx = 1;

Explain the value here.

@@ +265,3 @@
+    }
+
+  while (last_good_app != target_app)

I don't like these sort of while loops. Can you make this into a for loop?

I also don't like the pointer comparison when the original app-info is lost in code.
Comment 8 Giovanni Campagna 2013-03-10 18:02:17 UTC
(In reply to comment #7)
> Review of attachment 237772 [details] [review]:
>
> @@ +265,3 @@
> +    }
> +
> +  while (last_good_app != target_app)
> 
> I don't like these sort of while loops. Can you make this into a for loop?
> 
> I also don't like the pointer comparison when the original app-info is lost in
> code.

Uhm... I can't think of another way to put it. A for() would have weird conditions, because the comparison is in app ids, but the advancement is in a list.
Comment 9 Giovanni Campagna 2013-03-10 18:03:02 UTC
Created attachment 238536 [details] [review]
search: fix moving unsorted applications

Search providers can either have an explicitly configured sort order,
or be in the default alphabetical order based on their name.
Previously, when moving we would always assume that all providers had
a sort order, so moving an unsorted provider would put at the top.
The right thing to do, instead, is to walk the list in visual order
and assign an appropriate sort order, that is then flushed to gsettings.

Anyway, before committing the first patch, I'll wait to change
the sort order in gnome-shell too.
Comment 10 Bastien Nocera 2013-03-11 09:55:41 UTC
Review of attachment 238536 [details] [review]:

Looks fine.
Comment 11 Cosimo Cecchi 2013-04-02 18:11:20 UTC
Review of attachment 238009 [details] [review]:

See https://bugzilla.gnome.org/show_bug.cgi?id=694974#c5 - I think we should do this. Up to you to decide whether only in master or in 3.8 as well.
Comment 12 Giovanni Campagna 2013-04-02 19:47:55 UTC
Attachment 238009 [details] pushed as 3969c81 - search: don't keep the last panel last in the sort order
Attachment 238536 [details] pushed as 1627fdd - search: fix moving unsorted applications

I'm pushing to master and gnome-3-8, because this was approved
by Bastien before the branch, and because I believe it is worth to fix in 3.8,
with new apps featuring a search provider.