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

Opening preferences brackets.json in split view along with default preferences #11307

Closed
wants to merge 33 commits into from

Conversation

nethip
Copy link
Contributor

@nethip nethip commented Jun 24, 2015

With this PR, upon choosing Debug > Open Preferences file, preferences file brackets.json will open in the second pane of split view while the default preferences will load in the left-pane. The default preferences are generated on the fly by iterating through all valid preferences and writing into the default preferences file, defaultSettings.json created inside brackets preferences folder. Here is the work card for the same

This is the sample screenshot of how the split view looks like.

image

I am going to add unit tests for these. Meanwhile I would like to get some eyes on the changes and also make some code changes based on the review comments.

@sprintr @marcelgerber @abose Please review this when you get a chance.Thanks!

cc @ryanstewart

Pending Tasks

  • Add unit tests: Adding unit tests to this PR is not straight forward as we are using shell apis for this PR and they are not working with our unit test framework. I have added a waffle card to track this specific task.

nethip added 21 commits June 11, 2015 16:39
…e left pane and user preferences file brackets.json in the right pane. Also moved the code from PreferencesManager to DebugCommands extension.
…xisting instances of defaultPreferences.json before deleting the existing instance of defaultPreferences.json."
@@ -48,6 +51,12 @@ define(function (require, exports, module) {

var KeyboardPrefs = JSON.parse(require("text!keyboard.json"));

// default preferences file name
var DEFAULT_SETTINGS_FILENAME = "defaultSettings.json";
Copy link
Contributor

Choose a reason for hiding this comment

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

We really only use the term "preferences", so we should do so here, too.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure! will do this change.

@marcelgerber
Copy link
Contributor

When I just tried this branch, I noticed that Debug > Open preferences file no-ops when you're not in Split View and none of the files is already open.

@nethip
Copy link
Contributor Author

nethip commented Jun 24, 2015

@marcelgerber That was quick 😄 Thanks for starting to test this! I just checked. My bad. I pushed some bad change in one of the last commits that is causing this. For now to see what it looks like, be in the split view and then try Debug > Open Preferences File. I will check the code and push in a fix. Thanks!

… Changed typeof(var) == "undefined" var === undefined. And changed defaultSettings.json to defaultPreferences.json
@nethip
Copy link
Contributor Author

nethip commented Jun 24, 2015

@marcelgerber I have addressed the code review comments and updated the PR. Also I have fixed the bug with opening defaultPreferences and brackets.json in split view. Could you take a look at it and let me know if anything else needs to be changed?

prefType === "boolean" ||
prefType === "string" ||
prefType === "array" ||
prefType === "object") {
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we should use an array of supported preference types here and just check whether or not prefType is in it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure! will do that.

…e keys in a sorted order. Also added a new preference to give an opportunity to people to either display the user preferences on the right side or the left.
@nethip
Copy link
Contributor Author

nethip commented Jul 6, 2015

@sprintr I have changed the for() to forEach(). Also now I am sorting the keys.
@mackenza This PR is now updated with a new preference to display the preferences either on the right side or the left side. Please check it out and let me know if this looks fine.

@marcelgerber Let me know if the changes look good to you. I could then rebase this entire branch to a very limited no of commits before we merge this to master.

@mackenza
Copy link
Contributor

mackenza commented Jul 6, 2015

@nethip I get an error trying to open up the split view with your last changes:

image

Console says:
Uncaught TypeError: Cannot read property 'removeView' of null in view/MainViewManager.js:810

@sprintr
Copy link
Contributor

sprintr commented Jul 6, 2015

@nethip I am also facing the issue @mackenza reported above, so am not able to try it out. You may add default values of closeTags prefs as well here like you did for jslint.options

…t in with the preference change that allows users to specifiy the pane in which the user preferences need to be open. Also added default values to closeTag attribute.
@nethip
Copy link
Contributor Author

nethip commented Jul 6, 2015

@mackenza @sprintr Thanks a lot guys for trying out this PR and letting me know about the issue. This kind of crept in with the addition of the new preference to display the user preferences either in the first-pane or second-pane. I now have updated my branch with the fix. Also I have added default values of closeTags. Could you take the latest changes and checkout the feature and let me know if you guys see anything fishy. I really appreciate you guys taking some time in trying this feature out. Thanks!

@sprintr
Copy link
Contributor

sprintr commented Jul 7, 2015

@nethip 🆒 Works just as expected. 👍 for making the new layout default. The opening/closing/restoring layout scheme issue can be skipped for the moment, it looks more like an extension idea.

@nethip
Copy link
Contributor Author

nethip commented Jul 9, 2015

Since this needs to make into 1.4 we would want to send the strings for translations. I would like to know if there any parts of this PR that needs to be worked on. Or are we good to go with this change, in which case I will go ahead and merge this change.

@marcelgerber @sprintr @abose @mackenza @

@@ -279,9 +283,11 @@ define(function (require, exports, module) {
* @param {{startLine: number, endLine: number}=} range If specified, range of lines within the document
* to display in this editor. Inclusive.
*/
Copy link
Contributor

Choose a reason for hiding this comment

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

Please add "@ param options" in comments for the function.

@rroshan1
Copy link
Contributor

Currently, the comments at the beginning of defaultPreferences.json looks untidy when opened in split view,
current
I would suggest a cleaner
changed

@rroshan1
Copy link
Contributor

@nethip Everything else looks good from my side. 👍
I have run unit tests and scenario tests and all have passed.
I can merge it once the comments are addressed.

"DESCRIPTION_FONT_SIZE" : "Change font size; e.g, 13px"
"DESCRIPTION_FONT_SIZE" : "Change font size; e.g, 13px",
"DESCRIPTION_OPEN_PREFS_IN_SPLIT_VIEW" : "False to disable opening preferences file in split view",
"DESCRIPTION_OPEN_DEFULT_PREFS_IN_FIRST_PANE" : "False to open preferences in right pane/bottom pane",
Copy link
Contributor

Choose a reason for hiding this comment

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

spelling error... should be DESCRIPTION_OPEN_DEFAULT_PREFS_IN_FIRST_PANE

@mackenza
Copy link
Contributor

@nethip I am really not crazy about the preference name for whether the editable window is left or right.

alwaysOpenUserPrefsinSecondPane is a real mouthful and semantically questionable. A simple fix might be to remove the "always". It's not needed. We don't have it in the other preference related to this: openPrefsInSplitView so I feel it's redundant.

So, in the interest of getting this feature merged, I propose we simply go with:

openUserPrefsInSecondPane (notice I also camel-cased the I in In

"DESCRIPTION_FONT_SIZE" : "Change font size; e.g, 13px",
"DESCRIPTION_OPEN_PREFS_IN_SPLIT_VIEW" : "False to disable opening preferences file in split view",
"DESCRIPTION_OPEN_DEFULT_PREFS_IN_FIRST_PANE" : "False to open preferences in right pane/bottom pane",
"DEFAULT_PREFERENCES_JSON_HEADER_COMMENT" : "/*\n * This is a read-only file with the preferences supported by brackets. \n * Use this as a reference to modify your own preferences file(brackets.json)\n * opened in the right-hand pane. \n * Refer to https://github.com/adobe/brackets/wiki/How-to-Use-Brackets#preferences \n * for more information on how to use preferences inside Brackets.\n */",
Copy link
Contributor

Choose a reason for hiding this comment

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

now that we have a preference for which pane the default prefs opens in, we cannot say opened in the right-hand pane. I suggest:

opened in the other pane.

@nethip
Copy link
Contributor Author

nethip commented Jul 10, 2015

@mackenza I agree with you on changing the preference name. Just did it. Also changed the description variable name along with other string changes.

@rroshan1 I incorporated your changes as well.

@marcelgerber
Copy link
Contributor

There's still a merge conflict.

@nethip
Copy link
Contributor Author

nethip commented Jul 10, 2015

@marcelgerber I am on it. Looking into the merge conflict!

@nethip
Copy link
Contributor Author

nethip commented Jul 10, 2015

@marcelgerber I have created another PR which is basically a rebase of this PR, as this PR has some 30 odd commits. Would you mind having a quick look and merging it. Thanks!

@nethip
Copy link
Contributor Author

nethip commented Jul 10, 2015

@marcelgerber Here is the new PR with the rebased commits.

@nethip
Copy link
Contributor Author

nethip commented Jul 10, 2015

Since there are other PRs that are dependent on this I have gone ahead and merged other PR. Please feel free to call out any specific pieces of code that need to be reworked on. I will make sure that is addressed.

A big thank you to @marcelgerber @sprintr @mackenza @abose @rroshan1 for providing valuable feedback because of which this PR is in a very good shape. Thanks!

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.

7 participants