Hi, thanks for having taken the time to report this regression with details, that will help.

I don’t plan to go back to a treeview-based design, because it has various inherent problems. For example:
 * the complete path isn’t displayed, so it’s easy to edit a different key than the one you wanted, or to lose time searching the name of a key that is located elsewhere;
 * adding information about what is currently browsed is hard to do properly, as adding an infobar of the whole window length isn’t clear about what the information is related (to the current path or the currently selected key, or other), adding one to the keys’ panel looks weird, adding one to the paths’ panel is impossible (not enough space);
 * operations to apply to a complete folder always push to bad design, as setting something in the paths’ panel would result in changes in the keys’ panel; and it’s even worse with recursive operations;
 * because of the difference between focus and selection, it’s easy to change folder using the down arrow when you wanted to select the next key;
 * etc., not talking about the bad accessibility of GtkTreeView itself (bugs related to small mouse target for big screens or touchscreens, and to keyboard navigation).

So I’m confident in that the new design will be really better, notably because it is more flexible (adding functions or helping user in it is easy). That doesn’t mean that this first release with the new design doesn’t have regressions, sadly :·( and even if I tried to avoid them (with bookmarks and keyboard shortcuts).

So, 3.21.92 has been released more or less as you’ve seen (there have been important fixes on the focus, that will avoid scrolling in your use case, and makes keyboard a quite interesting input for browsing keys), and 3.22 will be quite similar next week. I’ll see if I can push some little changes to 3.22.1, but I think I’ll take my time to make 3.24 the most usable release ever. I’ll update this bug report when something new related to that will come.

I fail to see (or maybe I don't want to see!?) how new design is better... :(

Already mentioned thing - missing sidebar, it is harder to navigate. But to me it is not only problem/regression.

It was possible to edit / toggle booleans with one click. Now at best you must right click and then select True / False. Or click to open setting, click to turn off default value, click to select needed value and then one more click to apply changes.

Maybe there must be some extra mode? Advanced? Or 'I know what I am doing'? That would give back sidebar and make it more easier to change values.

(In reply to Alberts Muktupāvels from comment #2)
> I fail to see (or maybe I don't want to see!?) how new design is better... :(

Being “better” is always a quite subjective thing, that depends between others on what you’re used to, what you’re expecting to (be able to) do, and how you’re expecting to do it; not easy to measure.

It’s quite easy to prove the currently proposed workflows are “safer”: you always know what is the current value of the key (whatever its type is), and a transitional value is never applied hiddenly.

The design is also more flexible –thing that is only useful if used, but I consider at least bookmarks like a great improvement (try to think of an UI for bookmarking paths and keys with the 3.18 UI…).

> Already mentioned thing - missing sidebar, it is harder to navigate. But to
> me it is not only problem/regression.
> 
> It was possible to edit / toggle booleans with one click. Now at best you
> must right click and then select True / False. Or click to open setting,
> click to turn off default value, click to select needed value and then one
> more click to apply changes.

There could be no sidebar with the old “editable-key-list-item” UI, and there could be a sidebar with the “click-to-see-more” one (that was the case in 3.20 release). So the problem/regression you are feeling and highlighting here has nothing to do with this bug. Please, when possible, open different bugs for distinct problems. There’s not “one magic design” that I’d apply and would make every people happy, there are just some UI choices made for solving clear problems (like “regression about navigation in related paths”, what this bug is for), that couldn’t and shouldn’t be discussed all at the same time if we want things to improve.

To answer here anyway, True/False is more or less never a good choice to be given in the Gsettings world; True/False/Default is, and that’s what appears in the right click. (“Stick to default”/“Apply current opposite value” would be a baroque solution; I’d like it, but I’d probably be the only one.) And the extra mouse click has more or less no cognitive load (you know exactly what you’re going to see in the popover). So that looks like a good compromise, even without looking at the coherence of the workflows for non-boolean values. Yes, the two clicks needed in the detailed view *are* weird, and there could be an improved way to do here.

> Maybe there must be some extra mode? Advanced? Or 'I know what I am doing'?
> That would give back sidebar and make it more easier to change values.

What you are asking for has nothing to do with an “advanced” mode, it’s an “I-don’t-want-to-change-my-workflow” one, and that is the easier path to a broken application.

I’d like to give various ways to adapt the UI to specific cases/needs/preferences, but that’s a quite big job that has to be carefully designed and will take time to code.

---

About this bug, nothing changed for now in master, but I think I’ve (after multiple tries) found a solution that would allow to close it; a non-intrusive one, so that’s great also for the code maintainability. I just need a little more time; can’t promise, but I’ll do my best for 3.24.

(In reply to Arnaud B. from comment #3)
> (In reply to Alberts Muktupāvels from comment #2)
> > It was possible to edit / toggle booleans with one click. Now at best you
> > must right click and then select True / False.
> 
> To answer here anyway, True/False is more or less never a good choice to be
> given in the Gsettings world; True/False/Default is, and that’s what appears
> in the right click. (“Stick to default”/“Apply current opposite value” would
> be a baroque solution; I’d like it, but I’d probably be the only one.)

In fact, that’s not so baroque, so it’s done. (It needs some keyboard focus fixes and shortcuts, but that will be done before the 3.24 release in March.)

(In reply to Arnaud B. from comment #4)
> (In reply to Arnaud B. from comment #3)
> > (In reply to Alberts Muktupāvels from comment #2)
> > > It was possible to edit / toggle booleans with one click. Now at best you
> > > must right click and then select True / False.
> > 
> > To answer here anyway, True/False is more or less never a good choice to be
> > given in the Gsettings world; True/False/Default is, and that’s what appears
> > in the right click. (“Stick to default”/“Apply current opposite value” would
> > be a baroque solution; I’d like it, but I’d probably be the only one.)
> 
> In fact, that’s not so baroque, so it’s done. (It needs some keyboard focus
> fixes and shortcuts, but that will be done before the 3.24 release in March.)

Thanks!

(In reply to Alberts Muktupāvels from comment #2)
> I fail to see (or maybe I don't want to see!?) how new design is better... :(
> 
> Already mentioned thing - missing sidebar, it is harder to navigate. But to
> me it is not only problem/regression.
> 
> It was possible to edit / toggle booleans with one click. Now at best you
> must right click and then select True / False. Or click to open setting,
> click to turn off default value, click to select needed value and then one
> more click to apply changes.
> 
> Maybe there must be some extra mode? Advanced? Or 'I know what I am doing'?
> That would give back sidebar and make it more easier to change values.

I'm fully agree with you.

Best regards,
Alex.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/dconf-editor/issues/18.