Skip to content
This repository has been archived by the owner on Sep 6, 2021. It is now read-only.

Move descriptions to their preferences #11201

Merged
merged 1 commit into from
Jun 12, 2015

Conversation

sprintr
Copy link
Contributor

@sprintr sprintr commented Jun 2, 2015

All the descriptions of the preferences have been moved to their preferences and we no longer have data.json 😄

@@ -39,7 +39,16 @@ define(function (require, exports, module) {
Strings = brackets.getModule("strings"),
ThemeManager = brackets.getModule("view/ThemeManager"),
_ = brackets.getModule("thirdparty/lodash"),
data = JSON.parse(require("text!data.json")),
data = {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe also add a comment stating what this data is used for.

@abose abose added this to the Release 1.4 milestone Jun 2, 2015
@abose
Copy link
Contributor

abose commented Jun 2, 2015

Fixes part of #11200

prefs.definePreference(PREF_PREFER_PROVIDERS, "array", []);
prefs.definePreference(PREF_PREFER_PROVIDERS, "array", [], {
description: Strings.DESCRIPTION_LINTING_PREFER,
values: ["JSLint", "JSHint"],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should not specify value.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it could autocomplete with the registered linters? That would be cool.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it could be done, I guess. My point, though, it should not have default in the property definition (there's no default for this pref).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I will add that.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to be clear: what I am asking you to do is to remove line 617. Hinting on registered plugins is not necessarily needed for this PR.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you could just go ahead and remove this line (and also squash commits if you like), I could merge this PR in.

@marcelgerber marcelgerber self-assigned this Jun 3, 2015
@sprintr
Copy link
Contributor Author

sprintr commented Jun 5, 2015

@abose @marcelgerber I think it is ready for merging in.

@sprintr sprintr force-pushed the move-prefs-description branch 2 times, most recently from ae95113 to 79e0895 Compare June 5, 2015 21:02
* Returns an array of the IDs of providers registered for a specific language
*
* @param {!string} languageId
* @return {Array.<string>} Names of registered providers.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be {?Array.<string>}.
Or maybe it should return an empty array on the null case.


PreferencesManager.definePreference("codehint.TagHints", "boolean", true);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is codehint.TagHints is removed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is still there, I added description to it.

@sprintr sprintr force-pushed the move-prefs-description branch 2 times, most recently from d382851 to 52d1ed2 Compare June 6, 2015 08:59
_ = brackets.getModule("thirdparty/lodash"),
data = JSON.parse(require("text!data.json")),
languages = LanguageManager.getLanguages(),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should also listen to the LanguageManager events languageAdded and languageModified (?).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could do the same for the list of themes by listening to ExtensionManagers' statusChange event.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

statusChange gets fired every time an extension gets loaded. We would need an event that is fired only when an extension gets installed/uninstalled, so we can update our preferences data.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it makes a big difference to have this once instead of calling it when getting the list of hints?

You are already doing it for the code hint providers. So I think we can do something similar for both languages and themes.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can check if the AppInit.appReady has been called, after that we can update our preferences, theme data on each statusChange event.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIK, all extensions are loaded after appReady has been called.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not the ones you install after that, we need another event for that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marcelgerber I gave this a shot but since statusChange event is fired before the theme gets registered, ThemeManager.getAllThemes() still provides the old list of themes. But it works for getting code hints from newly installed extensions.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marcelgerber @TomMalbran Theme hints are not cached anymore, that should fix the issue of themes. Languages will still use languageAdded event.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sprintr I still don't see the point of having a cache of something that could be grabbed at the point of getting the hints like it is done with the code hint providers. getLanguages copies the object, but since you will have to iterate through the list eventually to create the ui, should be fine to get them on getHints when you actually need them. And the same goes for the themes, and maybe even the preferences. Seems easier than keeping a copy that needs to be synched.

function getProviderIDsForLanguage(languageId) {
if (!_providers[languageId]) {
return [];
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marcelgerber It now returns empty array.

@marcelgerber
Copy link
Contributor

Merging. Thanks @sprintr.

marcelgerber added a commit that referenced this pull request Jun 12, 2015
Move descriptions to their preferences
@marcelgerber marcelgerber merged commit cc0bb85 into adobe:master Jun 12, 2015
@sprintr sprintr deleted the move-prefs-description branch June 12, 2015 19:34
@abose
Copy link
Contributor

abose commented Jun 15, 2015

@sprintr the jasmine unit tests suite is failing after this PR merge commit. with the following error
Uncaught Error: Module name "language/CodeInspection" has not been loaded yet for context: _
Usually its a good idea to run the unit tests suite to catch errors like this :)

@sprintr
Copy link
Contributor Author

sprintr commented Jun 15, 2015

@abose Debugging this right now. Seems a tricky one.

@sprintr sprintr mentioned this pull request Jun 15, 2015
@abose
Copy link
Contributor

abose commented Jun 16, 2015

Thanks @sprintr for the fix.
@marcelgerber Usually we go through a pass of unit tests, integration and extension tests as baseline(+additional test cases) before merging any pull requests. 🚕

@marcelgerber
Copy link
Contributor

@abose I'm sorry. I've looked through all the changes and, well, I didn't expect unit test failures as all this PR changed is the added descriptions and one newly added function.
I'll be more careful the next time.

@abose
Copy link
Contributor

abose commented Jun 16, 2015

@marcelgerber No probs :) We also used to do the same thing until we noticed that in some cases even minor changes could sometimes cause a ripple. So just stuck to doing the basic smokes just before merge.

@marcelgerber marcelgerber mentioned this pull request Jun 23, 2015
6 tasks
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants