New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add completion for dconf #3638

Closed
radomirbosak opened this Issue Dec 11, 2016 · 4 comments

Comments

Projects
None yet
3 participants
@radomirbosak
Contributor

radomirbosak commented Dec 11, 2016

dconf works with a key-value database organized in a tree-like structure. I would be helpful to have completions for the key paths.

e.g.

$ dconf read /org/<TAB>

would suggest

gnome/
gtk/
gnucash/

which can be obtained by running

$ dconf list /org/
@krader1961

This comment has been minimized.

Show comment
Hide comment
@krader1961

krader1961 Dec 11, 2016

Contributor

Patches are welcomed, @radomirbosak. We're happy to answer questions if you need help getting started but a good starting point is to review some of the existing command completion scripts.

Contributor

krader1961 commented Dec 11, 2016

Patches are welcomed, @radomirbosak. We're happy to answer questions if you need help getting started but a good starting point is to review some of the existing command completion scripts.

@faho faho closed this in 4c7baa3 Dec 11, 2016

@faho

This comment has been minimized.

Show comment
Hide comment
@faho

faho Dec 11, 2016

Member

I had a few minutes of free time and an itch to write some completions, so I fixed it. Sorry 😅.

Anyway, it turns out that dconf list results in a very weird experience - you'd do

$ dconf read <TAB>
$ dconf read /org/<TAB>
$ dconf read /org/gnome/<TAB>

and so on just to end up with dconf read /org/gnome/terminal/legacy/schema-version.

Using dump gets around that.

Member

faho commented Dec 11, 2016

I had a few minutes of free time and an itch to write some completions, so I fixed it. Sorry 😅.

Anyway, it turns out that dconf list results in a very weird experience - you'd do

$ dconf read <TAB>
$ dconf read /org/<TAB>
$ dconf read /org/gnome/<TAB>

and so on just to end up with dconf read /org/gnome/terminal/legacy/schema-version.

Using dump gets around that.

@faho faho modified the milestones: fish 2.5.0, fish-future Dec 11, 2016

@radomirbosak

This comment has been minimized.

Show comment
Hide comment
@radomirbosak

radomirbosak Dec 11, 2016

Contributor

Wow, that was fast! Thanks @faho . 👍

I still think though that it makes more sense if the dconf completion was like the file/dir path completion in fish - to complete only one directory at a time.

Consider this scenario: let's say my key which I am looking for is somewhere under /org/gnome/. I don't know which directory I should follow after that, but I would probably recognize it if I saw its name. But after typing

dconf read /org/gnome/<TAB>

I get a lot of keys from /org/gnome/desktop/ which are irrelevant for me and I have to scroll down a lot to reach e.g. /org/gnome/shell/* keys. With dconf list-type completion I would get to choose only from

settings-daemon/
shell/
nautilus/
system/
evince/
evolution-data-server/
desktop/
eog/
terminal/
nm-applet/
evolution/
Totem/
software/

where its (obviously) easier to find the shell subdir

However, I must say that also the full-path completion style has its benefits - if you know the filename/part of the path you can search much easier:

$ dconf /<TAB><KEY_DOWN>location
search: location    
/org/gnome/shell/extensions/openweather/geolocation-provider  /org/gtk/settings/file-chooser/location-mode
/org/gnome/system/location/enabled

I can't say I have a strong opinion about this, but I think the dir-by-dir-type completion is more intuitive for users (as it is used for file/dir path completions). Writing long paths is IMHO well covered by suggestions if the user wants to use them more than once.

Maybe it would be best if both completion styles were available. (I'm not sure how.)

Contributor

radomirbosak commented Dec 11, 2016

Wow, that was fast! Thanks @faho . 👍

I still think though that it makes more sense if the dconf completion was like the file/dir path completion in fish - to complete only one directory at a time.

Consider this scenario: let's say my key which I am looking for is somewhere under /org/gnome/. I don't know which directory I should follow after that, but I would probably recognize it if I saw its name. But after typing

dconf read /org/gnome/<TAB>

I get a lot of keys from /org/gnome/desktop/ which are irrelevant for me and I have to scroll down a lot to reach e.g. /org/gnome/shell/* keys. With dconf list-type completion I would get to choose only from

settings-daemon/
shell/
nautilus/
system/
evince/
evolution-data-server/
desktop/
eog/
terminal/
nm-applet/
evolution/
Totem/
software/

where its (obviously) easier to find the shell subdir

However, I must say that also the full-path completion style has its benefits - if you know the filename/part of the path you can search much easier:

$ dconf /<TAB><KEY_DOWN>location
search: location    
/org/gnome/shell/extensions/openweather/geolocation-provider  /org/gtk/settings/file-chooser/location-mode
/org/gnome/system/location/enabled

I can't say I have a strong opinion about this, but I think the dir-by-dir-type completion is more intuitive for users (as it is used for file/dir path completions). Writing long paths is IMHO well covered by suggestions if the user wants to use them more than once.

Maybe it would be best if both completion styles were available. (I'm not sure how.)

@faho

This comment has been minimized.

Show comment
Hide comment
@faho

faho Dec 12, 2016

Member

It's probably worth noting that I'm not running gnome, so the only thing I have using dconf is gnome-terminal and mate-terminal, which I sometimes use for testing. That means I have a total of 20 keys and don't know how this would feel if I had more. How many keys do you have on gnome?

However, I must say that also the full-path completion style has its benefits - if you know the filename/part of the path you can search much easier:

It's actually even quicker to just type dconf read location<TAB> - we have "fuzzy" (really "infix") completion, so the current token can also appear in the middle.

I still think though that it makes more sense if the dconf completion was like the file/dir path completion in fish - to complete only one directory at a time.

The main issue I have there is that the first part is almost always "/org/", so you end up typing a lot, since you either do "dconf read /<TAB>, pick '/org/', pick the first actually interesting part" or "dconf read /org/<TAB>".

Additionally, I actually started out using dconf list, but that stuff is sooo picky with regard to a trailing "/" (there must always be exactly one) that it was annoying and so I tried a different route. The current code is much easier. Though it's also possible I was just overthinking it.

Maybe it would be best if both completion styles were available. (I'm not sure how.)

This is one of those cases where we should just pick one. If anyone really prefers another, they can override the completion.

Member

faho commented Dec 12, 2016

It's probably worth noting that I'm not running gnome, so the only thing I have using dconf is gnome-terminal and mate-terminal, which I sometimes use for testing. That means I have a total of 20 keys and don't know how this would feel if I had more. How many keys do you have on gnome?

However, I must say that also the full-path completion style has its benefits - if you know the filename/part of the path you can search much easier:

It's actually even quicker to just type dconf read location<TAB> - we have "fuzzy" (really "infix") completion, so the current token can also appear in the middle.

I still think though that it makes more sense if the dconf completion was like the file/dir path completion in fish - to complete only one directory at a time.

The main issue I have there is that the first part is almost always "/org/", so you end up typing a lot, since you either do "dconf read /<TAB>, pick '/org/', pick the first actually interesting part" or "dconf read /org/<TAB>".

Additionally, I actually started out using dconf list, but that stuff is sooo picky with regard to a trailing "/" (there must always be exactly one) that it was annoying and so I tried a different route. The current code is much easier. Though it's also possible I was just overthinking it.

Maybe it would be best if both completion styles were available. (I'm not sure how.)

This is one of those cases where we should just pick one. If anyone really prefers another, they can override the completion.

@faho faho added the release notes label Dec 12, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment