Open core-ai-bot opened 3 years ago
Comment by MiguelCastillo Monday Jan 26, 2015 at 17:19 GMT
@
mat-mcloughlin I like the idea. Initially the rules were not restricted to just the editor, then we restricted them to the editor because we didn't want to allow theme authors to mess with the rest of the application because the DOM could change and then themes could potentially be broken.
But I like the opt-in approach. @
peterflynn , do you have any objections to this change?
Comment by MarcelGerber Sunday Feb 01, 2015 at 13:40 GMT
Btw, this was discussed in https://groups.google.com/forum/#!topic/brackets-dev/6_TFeUSUf80.
Comment by MiguelCastillo Sunday Feb 01, 2015 at 14:23 GMT
Oh thanks for the link!
@
mat-mcloughlin I think the use case for this class goes beyond the scope of syntax highlighting, so we should come up with a more generic name. Meaning that adding this class will allow somebody to style the tree, for example. If this is only for syntax highlighting, why do you need to rely on themes though? Couldn't you have your extension load its own css/less and add styling that way? Check out how I do it in ternific - here. You can load up your css file like this, for example.
Let me know what you think.
Comment by MiguelCastillo Sunday Feb 01, 2015 at 14:36 GMT
Thinking about it a bit more, this needs to be thought out a bit more. This actually falls in the theming for the whole tool, which we have a trello card for. This quick one off patch is most likely going to be obsoleted. I don't think we should add this - I don't know how whole editor theming is going to play out.
@
mat-mcloughlin I really suggest adding your own style as I described in my previous post. Let me know if I can help you there.
Comment by MarcelGerber Sunday Feb 01, 2015 at 16:14 GMT
I still think it's a good idea. He tries to match the appearence of his code hints popup with how it'll look like after being inserted into the editor. Also, I wouldn't call it whole-tool themes/schemes/WhateverYouWannaCallIt. In this case, the extension explicitly asks to be styled using themes, while whole-tool themes would do it the other way round, they'd actively apply their styles to the whole Brackets UI.
Comment by mat-mcloughlin Sunday Feb 01, 2015 at 16:37 GMT
Hey, I'll take a look but the point of this is that it would apply the users chosen theme to the code hint popup.
Comment by MiguelCastillo Friday Mar 27, 2015 at 00:16 GMT
@
mat-mcloughlin did you end up resolving your issue?
Comment by mat-mcloughlin Friday Mar 27, 2015 at 09:37 GMT
No I ended up leaving it. Its a nice to have and didn't want to implement a complicated solution until I knew what you were planning regrading implementing this in to core
Comment by MiguelCastillo Friday Mar 27, 2015 at 12:10 GMT
Fair enough. I agree there is value in having this non-intrusive solution that most likely will not interfere with any further work on theming.
Comment by MiguelCastillo Friday Mar 27, 2015 at 12:18 GMT
@
dangoor@
redmunds are you guys ok with this minor tweak to enable folks to accomplish their goals more easily? I think this adds value.
The caveat of course is that any future DOM changes outside of #editor-holder
have a chance of breaking extensions, so we would want to add a h1-bolded disclaimer on this. This is the only reason I have been a bit hesitant about it.
Comment by dangoor Friday Mar 27, 2015 at 13:01 GMT
Since this is opt-in, it seems reasonable to me.
Comment by MiguelCastillo Friday Mar 27, 2015 at 14:01 GMT
theme-override
or another name that is generic... If there are no options to chose from, then we can just go with theme-override
.
Comment by redmunds Friday Mar 27, 2015 at 14:31 GMT
Looks good to me.
The caveat of course is that any future DOM changes outside of
#editor-holder
have a chance of breaking extensions
I don't see how this change has any effect on future DOM changes breaking extensions. Let me know if I'm missing something.
Comment by redmunds Friday Mar 27, 2015 at 14:58 GMT
How about .apply-editor-coloring
, .apply-editor-syntax-coloring
, or .editor-syntax-coloring
?
Comment by MiguelCastillo Friday Mar 27, 2015 at 15:12 GMT
@
redmunds if someone writes an extension that for example styles some part of the file tree using this new class
... And the file tree goes through a change in which a class is renamed/removed or a div is added, then such extension could break because they are writing css rules that target something that changed.
Also, the class name could be more generic. Using that class will enable someone to theme the file tree. At which point .apply-editor-coloring
is no longer accurate.
Comment by redmunds Friday Mar 27, 2015 at 15:28 GMT
@
MiguelCastillo
if someone writes an extension that for example styles some part of the file tree using this new class... And the file tree goes through a change in which a class is renamed/removed or a div is added, then such extension could break because they are writing css rules that target something that changed.
That's the same as it's always been. I guess the point is that by providing this mechanism, we're endorsing these types of extensions so it will be more likely. As you said, we should have a disclaimer that we don't guarantee that this will never change and extension authors should watch for API changes.
Comment by MiguelCastillo Friday Mar 27, 2015 at 15:33 GMT
@
redmunds yeah exactly :) endorsing
is the key.
Comment by mat-mcloughlin Friday Mar 27, 2015 at 15:47 GMT
@
redmunds@
MiguelCastillo is that a yea or nay :)
Comment by MiguelCastillo Friday Mar 27, 2015 at 15:48 GMT
@
mat-mcloughlin its a yea :) just brining everyone up to speed on the implications.
Issue by mat-mcloughlin Monday Jan 26, 2015 at 16:50 GMT Originally opened as https://github.com/adobe/brackets/pull/10468
I've added changed where the theme gets applied so it also applies to any element with the
.force-syntax-highlighting
classmat-mcloughlin included the following code: https://github.com/adobe/brackets/pull/10468/commits