settings-view
settings-view copied to clipboard
Unify core and package settings
This came up in the discussion around #277 - it would be interesting to have the Settings pane contain all the package settings as well, and use a fuzzy-finder to filter down to what you need. I would like to keep the individual package meta / settings pages still, to allow something like #90 to be supported down the road, but there seems to be value in a single, global, searchable settings page. Failing that, at least some kind of global search that then allows the relevant package settings to be found and opened (a la the OS X System Preferences search box)
cc @maxbrunsfeld @simurai
:+1:
I've so far found it difficult to locate particular settings since I first have to know/find the package containing it. Fuzzy search across all settings would be rad.
I have to agree with this request.
To demonstrate best practice, attached are Mac and Chrome screenshots
Is this issue "just" for a global page for all settings, or also for search in all (plugin) settings? Or is there/should there be a separate bug for that?
@rbu It's really for both, although this may end up getting implemented in multiple PRs.
@mnquintana, thanks for the information. Just to weigh in: I care for "search in all settings" much more than "all settings in one dialog". Thanks you for this!
Both search in all settings and show all settings in one place should happen. Sooner rather than later.
Sooner rather than later.
Right now we're working on the issues in this list, but this is could be plausible to attempt in the fall. If anyone is interested in working on it before then I think a good place to start is to wireframe out how the search interaction might work in the settings view and think about how the current views in settings might have to change. (I think this is more of a UX problem than a matter of writing code)
[Included from https://github.com/atom/atom/issues/8941 for reference, minor editing]
Since there are many bytecode languages out there (Java, python, ...) one would naturally want to hide the bytecode files from what Atom has as a "Package Explorer". This is a task that many users would like to perform. Currently, this requires changing the Core settings as well as the tree-view package settings. The problem here is that a) tree-view is not an obvious name and b) one does not expect it to be treated, from the GUI perspective, as one of the 78 non-core standard packages of Atom.
This is a GUI design issue and I think it can cause frustration and waste serious time for the average user. It certainly did for me.
The approach need not be all-or-nothing. Some "popular/critical" settings should be more accessible, for example, being mirrored in sections of a "General Settings" pane, that would begin with a "Core Settings" section.
I think that a complete unification is too much. It still does not address the package name issue. How would someone guess the tree-view? If you expose just a few packages, it would at least be easier to locate.
+1.
As an interim solution, package-settings let’s you quickly search and bring up the settings for a particular package, but again you have to know (roughly) the package name and also this clutters up the command palette even more.
Maybe some of the code can be gleaned from it though…
I think it is a good approach. This is similar the web search, where you can search for anything from a single spot. You can consider adding a droplist, like they have on Amazon.com, for the user to select a category for his search.
Regarding the naming issue, I would try out aliases. The publisher of the package can have some presets, possibly limited to 2-3, and the user can change them if he likes.
+1
This would be helpful even for a single package, but a global one would be even better. Search against the title
and description
of settings of all installed packages that are not of type object
.