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 730867 - Option to sort folders first is not retained
Option to sort folders first is not retained
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: Preferences
3.12.x
Other Linux
: Normal normal
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
: 735174 742100 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2014-05-28 08:37 UTC by smot
Modified: 2014-12-30 01:09 UTC
See Also:
GNOME target: 3.14
GNOME version: ---


Attachments
Removed broken synchronization of GTK+ setting 'sort-directories-first' (1.54 KB, patch)
2014-07-11 15:11 UTC, Emil Tullstedt
none Details | Review
Fix the sort-directories-first setting handling (1.95 KB, patch)
2014-09-01 18:57 UTC, Matthias Clasen
committed Details | Review

Description smot 2014-05-28 08:37:54 UTC
Using Ubuntu Gnome 14.04 with Gnome Shell updated to 3.12 after fresh install.

Select Nautilus (a.k.a. Files) Preferences, then check "Sort folders before files".

Option is not saved on closing the form, and the option is ignored.
Comment 1 António Fernandes 2014-05-29 16:55:11 UTC
Thanks for the bug report. I can reproduce in nautilus 3.12.2 (Fedora 20 + GNOME 3.12 COPR) as well as nautilus from git master (jhbuild).

It is worth noting that changing this option does take effect on the file chooser dialog.

Reverting commit 004db388fa8a4e784ee3ec5f31b811aaf6a30c4d (see bug 728513), this bug is not reproducible. [0]

Looking at the code and GSettings API docs, I believe this bug was indeed introduced by that patch. According to the docs, "If you bind the same property twice on the same object, the second binding overrides the first one." [1].

If my understanding of this is not completely mistaken, when the Preferences dialog is created, it will first "get" the value from the nautilus own GSettings key, but then the second bind overrides the first, so any changes to the checkbox will be "set" to gtk+ key only. This may explain why changing the option is ignored by nautilus (the nautilus view listens for changes of nautilus own key, which is never changed) but not by the file-chooser, and also why, when reopening the Preferences window, the checkbox is reset to nautilus key value.

I don't know how to fix this but I hope this information is useful.

[0] https://git.gnome.org/browse/nautilus/commit/?id=004db388fa8a4e784ee3ec5f31b811aaf6a30c4d
[1] https://developer.gnome.org/gio/unstable/GSettings.html#g-settings-bind
Comment 2 Ralph Plawetzki 2014-06-30 08:18:35 UTC
I can see this issue as well in current nautilus 3.12-2-1 (Arch x86_64).
https://bugs.archlinux.org/task/40837
Comment 3 Emil Tullstedt 2014-07-11 15:11:31 UTC
Created attachment 280517 [details] [review]
Removed broken synchronization of GTK+ setting 'sort-directories-first'

Reverting '004db38' to solve bug 730867.

This will cause bug 728513 to be re-opened.
Comment 4 António Fernandes 2014-08-27 09:15:11 UTC
*** Bug 735174 has been marked as a duplicate of this bug. ***
Comment 5 Michal Kovarik 2014-09-01 12:39:08 UTC
same issue with nautilus-3.13.90-1.fc21.x86_64 on Fedora.
Comment 6 Matthias Clasen 2014-09-01 18:57:58 UTC
Created attachment 285055 [details] [review]
Fix the sort-directories-first setting handling

Sadly, we can't bind two settings to the same object property,
so use a manual handler for the :notify::active signal instead.
Comment 7 Cosimo Cecchi 2014-09-01 19:29:53 UTC
Review of attachment 285055 [details] [review]:

Thanks, looks good.
Comment 8 Matthias Clasen 2014-09-01 20:33:31 UTC
Comment on attachment 285055 [details] [review]
Fix the sort-directories-first setting handling

Attachment 285055 [details] pushed as 5e4e82c - Fix the sort-directories-first setting handling
Comment 9 António Fernandes 2014-12-30 01:09:24 UTC
*** Bug 742100 has been marked as a duplicate of this bug. ***