settings-view icon indicating copy to clipboard operation
settings-view copied to clipboard

Unify core and package settings

Open thedaniel opened this issue 10 years ago • 13 comments

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

thedaniel avatar Dec 16 '14 01:12 thedaniel

:+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.

davefp avatar Jan 19 '15 18:01 davefp

I have to agree with this request.

danielo515 avatar Feb 13 '15 07:02 danielo515

To demonstrate best practice, attached are Mac and Chrome screenshots

screen shot 2015-02-18 at 11 39 18 am screen shot 2015-02-18 at 11 38 42 am

fulldecent avatar Feb 18 '15 16:02 fulldecent

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 avatar Apr 29 '15 14:04 rbu

@rbu It's really for both, although this may end up getting implemented in multiple PRs.

mnquintana avatar Apr 29 '15 15:04 mnquintana

@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!

rbu avatar May 01 '15 12:05 rbu

Both search in all settings and show all settings in one place should happen. Sooner rather than later.

Zireael07 avatar Aug 18 '15 14:08 Zireael07

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)

thedaniel avatar Aug 18 '15 17:08 thedaniel

[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.

chav-n avatar Sep 25 '15 14:09 chav-n

+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…

danielbayley avatar Feb 22 '16 15:02 danielbayley

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.

chav-n avatar Feb 23 '16 07:02 chav-n

+1

KiYugadgeter avatar Jun 04 '16 01:06 KiYugadgeter

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.

stevenzeck avatar Apr 06 '18 18:04 stevenzeck