GNOME Bugzilla – Bug 784868
dconf-editor: Apply-button confuses users coming from older versions
Last modified: 2017-08-09 09:55:01 UTC
Hello, I recently upgraded to Debian 9 Stretch with Gnome 3.22.3. Please forgive me if I ticked the wrong version. The last version of Gnome I worked with was 3.14.15 or so and I changed in the settings that I want the directories sorted first. With the update the entry I changed became invalid (which is a mild inconvenience but it is non-the-less). I tried to adjust another entry and were surprised that there is a separate apply-button which I have to press in order to see the effects of the option. This button is not even there in a disabled form if the entry is left untouched. So there is no clue indicating that there are now multiple steps involved in changing an entry. Sincerely Martin B.
Hello, sorry for my late reply. (In reply to Martin B. from comment #0) > I recently upgraded to Debian 9 Stretch with Gnome 3.22.3. Please forgive me > if I ticked the wrong version. That’s a stable version (in the form [major].[minor even].[revision]), so you’re good with that. :·) > The last version of Gnome I worked with was 3.14.15 or so and I changed in > the settings that I want the directories sorted first. > With the update the entry I changed became invalid (which is a mild > inconvenience but it is non-the-less). Dconf-editor is not responsible of what settings are available, it just displays settings exposed by various applications. When a setting appears, changes or disappears, you have to see with the developers of the application that exposes this settings. As Dconf-editor maintainer, I have no role in these changes. For what you’re talking about, the change happened in Files (aka. Nautilus)[1]: looks like Nautilus developers agreed that the “sort-directory-first” option should be consistent with the behaviour of Gtk+ filechooser —something I totally agree with. So you have to change the setting exposed at path “/org/gtk/settings/file-chooser/sort-directories-first” to find back the wanted behaviour. > I tried to adjust another entry and were surprised that there is a separate > apply-button which I have to press in order to see the effects of the option. > > This button is not even there in a disabled form if the entry is left > untouched. So there is no clue indicating that there are now multiple steps > involved in changing an entry. There are now multiple steps involved, yes. Dconf-editor allows editing some settings that could cause some problems to some applications, so I’ll do my best to ensure no dangerous change is made by mistake. That implies a validation in the default settings. In case you don’t feel the need to act safely, I added a setting at path “/ca/desrt/dconf-editor/behaviour” that allows various behaviours. Logically, “unsafe” is quite unsafe, and “safe” should be safe but without confirmation for most keys. Concerning the thing that there is no clue indicating that there are (now) multiple steps (by default), I fail to see exactly the problem. Yes, it’s a change for users that were used to the old interface, but past the first time and discovery, it should be okay, shouldn’t it? Anyway, as I have plans to rework (again and again) the way validation is done, I won’t try to solve specifically this problem, I’ll just keep it in memory. Thanks for your opinions and your bug report. Arnaud B. [1] https://git.gnome.org/browse/nautilus/diff/?h=gnome-3-22&id=73c3c92e4a26e6169d4aa16add38f3247347f446&id2=a3999d6db2977692c5adb4af8551c0d8efe34aea