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

Logic to make sure scrollbar processing only happens in the editor space... #8493

Closed
wants to merge 23 commits into from
Closed

Logic to make sure scrollbar processing only happens in the editor space... #8493

wants to merge 23 commits into from

Conversation

MiguelCastillo
Copy link
Contributor

.... Also fixed issue with scrollbar regex.

#8482

@MiguelCastillo
Copy link
Contributor Author

cc @dangoor @peterflynn @TomMalbran

Guys, so the issue is actually a regression I introduced when I removed parts of the scrollbars regex in order to make jslint happy. :/ The warnings in the regex are back, but the regex is working as expected again. Not sure what to do about the warnings, so any help would be nice :)

@MiguelCastillo
Copy link
Contributor Author

BTW, I added the dark class to DOM in the element where platform exists...

@TomMalbran
Copy link
Contributor

To make JSLint happy you can either try to escape ^ (which does not always work) or just add regexp: true to the list of JSLint directives so that it stops complaining about it.

@peterflynn
Copy link
Member

We use regexp: true in a few other files, so it's definitely fine to do that. The motivation behind that warning seems to be specific to cases where you're using regexps to validate form fields, so it isn't useful to us here.

@MiguelCastillo
Copy link
Contributor Author

@peterflynn @TomMalbran I knew that! :D Thank you guys

.then(function (cssContent) {
$("[class|=platform]").toggleClass("dark", theme.dark);
Copy link
Contributor

Choose a reason for hiding this comment

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

why not just set this on body?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah will change that. I was trying to keep this in the spirit of the platform- issue we were discussing yesterday. But body is definitely my preference to.

Copy link
Contributor

Choose a reason for hiding this comment

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

There's a subtle issue here. If options.theme is undefined, then theme.dark will be undefined rather than false. Changing the line in the Theme constructor like so will fix it:

this.dark        = options.theme !== undefined && options.theme.dark === true;

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah I will change that to be air tight, but the toggleClass will behave the same either way.

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 change from one light theme to another light theme, it would toggle the dark class to dark on the second one...

Copy link
Contributor

Choose a reason for hiding this comment

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

Easier:

this.dark = (options.theme && options.theme.dark) || false;

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah that will work too... options.theme at that point couldn't be undefined because it would have already crashes when in loadPackage.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

And at the point !!options.theme.dark would be sufficient

@dangoor
Copy link
Contributor

dangoor commented Jul 22, 2014

Hmm, @peterflynn's comment from yesterday evening suggesting that we move the dark theme scrollbars into core because they're finicky makes me wonder about something. If we move them into core, when you turn off custom scrollbars and you're using a dark theme, it will actually revert not to system scrollbars but the default dark scrollbars that Brackets provides. That's probably okay, but would be confusing if the Theme Settings dialog says "Use system scrollbars" rather than the current "Use custom scrollbars" as in #8384

@dangoor
Copy link
Contributor

dangoor commented Jul 22, 2014

That comment I just put probably belongs in #8384 rather than here. I think the change here will be fine for allowing custom scrollbars in editor themes.

…is found. Also added coercion to make theme.dark always be a boolean
@@ -87,7 +87,7 @@ define(function (require, exports, module) {
this.file = file;
this.name = options.name || (options.title || fileName).toLocaleLowerCase().replace(/[\W]/g, '-');
this.displayName = options.title || toDisplayName(fileName);
this.dark = options.theme && options.theme.dark === true;
this.dark = !!options.theme.dark;
Copy link
Contributor

Choose a reason for hiding this comment

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

is it possible that options.theme could ever be undefined? This will give an error. In fact, it does in the tests (which don't run now).

@MiguelCastillo
Copy link
Contributor Author

@dangoor, closing this one in favor of #8505. That has a normal history line

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.

8 participants