Sublime Forum

ColorHelper 2.0.0

#33

@legosublime, @kaosmos I am not going to say never, but it also isn’t on roadmap.

First off, ColorHelper is aimed at highlighting colors in more than just web stuff; I’m not a web developer. It is more generalized, but with that said, that doesn’t mean I can’t add that in the future. I realize that web developers are probably my main users. It is setup by default to work with web stuff, but it isn’t set up as web specific plugin.

Second, the way the inline previews currently work, this would be difficult in its current implementation. I currently only scan the current active visible window of a text file. This is done for performance. This is why the colors load when you scroll text into the view. Only the visible text gets colorfied. Yes, everything I have already scanned is cached, but if the variable hadn’t been scrolled into view, the uses of it won’t be colorfied either. If I scanned the entire file in one shot, then it would be more possible, but I have not yet experimented with performance in that kind of setting. As I must insert these colors asynchronously for performance, a lot can happen form when I start processing and inserting colors from the beginning of a file to the end. I will have to experiment with this more.

I also would need to make some major changes internally, which I am planning on making. Currently color types are all hard coded internally. The vision for this plugin was never fully formed when I threw it together. Moving forward I need abstract things a bit more and make stuff more dynamic and more modularized. I envision moving forward that the mechanics of enabling new specified color forms will be exposed to the user (I don’t know yet if that will mean dynamic color lists such as variables though, and I don’t know if I would want to tackle this as an additional separate feature). The current plugin started out as a prototype and has been a growing monster that needs to be architected in a more maintainable way if I am going to add more and more complex features.

Like I said, I’m not going to say never, but I would need to see how my direction and the code evolves. Hopefully, even with its limitations it is still found to be useful.

2 Likes

#34

@kingkeith, yes thank you for highlighting the issue. It is an issue with how sublime triggers events from a popup.

0 Likes

#35

Thanks for pointing me to that, I will try to remember to check the active issues first next time :slightly_smiling:

1 Like

#36

Well, with the release of ST 3119. It looks like I have some more work to do. I like the idea of the rem units which should allow me to ditch my old font size detection and give more maintainable relative sizes in mdpopups (which is a dependency for this plugin). This is good news, but also more work . I guess that is what I get for building stuff around bleeding edge features :slightly_smiling:.

1 Like

#37

@jcberquist no problem.

0 Likes

#38

Oh, definitely useful :slight_smile: and thank you for the quick and very clear answer.

0 Likes

#39

Hi!
Could you help me to clarify installation? I just tried to update ColorHelper, but it displayed the version 2.0.4 what the difference because I wasn’t able to update the version I saw in this preview. Every time the package update to version 2.0.4 not 2.0.0 I did it many times. I’ll appreciate any suggestion.

0 Likes

#40

That seems like a generally bad idea that will results in color schemes and packages fighting each other over CSS selector specificity.

I’ve opened https://github.com/equinusocio/material-theme/issues/920 to try and get the issue resolved.

Generally plugins should do minimal, non-specific CSS to make it look half-decent. You should add a unique id to the <body> tag of your HTML so that specific popups/phantoms can be targeted. Then it is up to the color scheme authors to make it look the way they want.

2 Likes

#41

Have you tried using minihtml directly to generate the color via a background-color applied to a transparent image? If that worked, it would mean you wouldn’t need to generate images on the fly with the various colors.

As of 3119 there is support for colors in hex, hex with alpha, short hex, short hex with alpha, rgb, rgba, hsl and hsla in minihtml. As long as you detect one of those color formats, you should theoretically be able to pass it directly in.

1 Like

#42

This was created before minihtml added such features. Also, I kind of still need to generate to generate images as I need scale images with font_size. My images have checkered board patterns for transparency etc. What looks good and one resolution does not look good at another. So it is a bit more complicated than that.

0 Likes

#43

Please remove this “forcing”, the extra padding is a bug and the theme should control the padding and other css rules. Material Theme will fix this in the next release, after your fix.

1 Like

#44

I understand what you are suggesting. ColorHelper uses a dependency called mdpopups. Keep in mind that I wrote mdpopups before Sublime started generating colors for schemes etc. With that said, mdpopups generates a basic default CSS with more practical styles for existing elements and for elements not yet styled. I just can’t see a practical need for the current giant H1 element with padding in a popup or inline phantom etc.; what I needed in an HTML web page is different than what I need in a popup or phantom.

It approaches it by:

  • creating a reasonable basic/minimal styling as a base.
  • It generates color classes that match a scheme and does minimal colorization (in fact I am scaling back on what I was colorizing before in the next release to be more minimal). But again, this was done before Sublime started generating colors itself.
  • Plugin users are encouraged to use classes on anything they colorize by namespacing their classes because minihtml CSS doesn’t work on this class1 class2, only stuff like this works class1.class2 (maybe this has changed?).
  • Lastly, users can override anything with a user CSS. If they don’t like what a plugin author chose, they can use a custom user default CSS to override their namespaced class element. They don’t like what I chose as the default style, custom user CSS to override the defaults. The user gets to make the final call. I don’t trust the choices of style of every plugin creator/theme creator. Nor do I expect everyone should trust me as well. Nor do I want to argue style choices with with any with every plugin creator. I can override anything in my user folder.
  • Users also get template variables to check different sublime versions in their CSS and other various stuff, and a couple of filters to adjust colors, import other external CSS for different reasons etc. (this was again created before Sublime had or documented their color blending methods etc.)

Anyways, I try to give a basic, reasonable, and common CSS in all my plugins via mdpopups, and then I let the users override any of my choices if they like. I am glad Sublime is being a little better with their defaults, but I still need something a bit more flexible.

1 Like

#45

I have no intentions of removing it at this time as it protects against anyone who might do something similar. Any user that is using a plugin that uses my mdpopups dependency as the ability to override my choices in their own user CSS, so it is not a permanent forcing. I plan on keeping this way for the immediate future.

0 Likes

#46

@wbond On thing I suggest Sublime works on is better CSS rules. If this hasn’t been added currently, things like this should work and will make style much easier: class1 class2{}. Second, I’ve seen issues where I can apply a background color to a block element, and then when I try to apply a background color via the style attribute in an inline child element, the background of the inline element doesn’t apply.

Oh, and borders would be such a help. If I could get borders, when I syntax highlight code I wouldn’t have to apply a different background to a block element and additionally apply backgrounds to spans. to differentiate the regions.

1 Like

#47

Your plugin should not force the css and the appearance of a view. At the moment all the rules inside the html selector are ignored by this plugin. Not only the padding.

0 Likes

#48

You can override the defaults with whatever your theme uses, or you can not use any of my plugins that utilize this. At the very minimum, I can add an option to side step the mdpopups defaults entirely via a template variable, this is a reasonable compromise. A user can still override anything they want, and that is what I like. The user gets the final say, and that will not change.

0 Likes

#49

Please provide a full list of the css selectors used, html tags with the default values, otherwise no one can override the css of this plugin.

0 Likes

#50

Child selectors were added in 3119, and inline element background colors should works fine above block-level background colors. These are both used by the default style for inline error messages.

Borders are on my list of things to implement.

2 Likes

#51

Thank you! I will take a look at this and begin altering how I approach things :slightly_smiling:.

Fantastic!

0 Likes

#52

There is also inline element padding and relative positioning. Plus one of my favorites: border-radius. :grinning: You should definitely check out the docs for minihtml.

While there isn’t background image support yet (for checkerboard), using a rem width/height on a transparent image should help get it sized properly. We should eventually get to the point where generating images will not be required.

2 Likes