ColorHelper 2.0.0

[prmaple]

I think I’m pretty sure that’s not CH’s fault now. I remember that when CH 2 was first released, when the color tile was placed on the right of the color text, the tile was a perfect square. I just tried cloning the repo and going through 2.0.0 - 2.0.4, none of them give me perfect square anymore.

I then tried the default monokai color scheme:

So it’s not just material theme either.

BTW the phantom with the default monokai color scheme looks especially weird, so I tried another one:

I guess something in 3120 or 3119 broke it for me.

[facelessuser]

Try changing your font size. I’ve seen images look funny at certain font sizes, but then fine at others.

[prmaple]

Try changing your font size. I’ve seen images look funny at certain font sizes, but then fine at others.

Nah, didn’t do the trick

[kingkeith]

I then tried the default monokai color scheme:

what about trying the default theme as well?

[prmaple]

what about trying the default theme as well?

Doesn’t seem to make a difference… sigh

Anyway:

I remember that when CH 2 was first released, when the color tile was placed on the right of the color text, the tile was a perfect square.

I guess something in 3120 or 3119 broke it for me.

[facelessuser]

@prmaple, I don’t think you are alone. I have brought this to @wbond attention yesterday that sometimes images in phantoms and popups get clipped or distorted. I noticed this in recent builds, but putting together a case that is reproducible on multiple machines is hard. I am seeing slight issue clipping in ScopeHunter on one of my machines, but not the other. I have had someone report they were seeing issues in ColorHelper on the first instance of inline images, but not the rest (I have not been able to reproduce that and now it has disappeared on his machine). You are having this issue, but no one else is. I do think there is something wrong, I just don’t know how to make it reproducible and prove it.

[prmaple]

Just tested on my old laptop, same situation.

Again posting my spec:
Both machines are on Windows 10, one with UHD screen, the old one 3200x1800.
Sublime 3120, ColorHelper 2.0.4
The situation happens on all color schemes I’ve used.
I’ve also tried modifying the scaling factor (My normal valueis 250%), doesn’t make a difference.

[facelessuser]

@prmaple Apparently my windows machine was not up to date and I was still on 3118. I upgraded to 3119 and now I have distorted images like you have. So this is a bug in Sublime Text.

[facelessuser]

I meant 3120. Sublime doesn’t seem to notify people about 3120. But when I upgraded, I got the issues.

[facelessuser]

I have the issue on 3119 as well. It is Windows specific.

[prmaple]

now I just need to wait for ST to fix it! Yay!

[facelessuser]

I know. 3119 is a huge improvement in the CSS engine. It has better inheritance and such. You can actually use .class1 .class2, so you can actually use divs as wrappers for styling specific stuff. But, with so much good stuff, comes bugs. Inline background colors don’t line up right. Weird Windows image distortion etc. Despite the bugs, I am very excited about minihtml getting some love.

With all that said, it works great on my Mac, just wished it worked better on my Windows box.

[kingkeith]

Mdpopups 1.9.0

I had the same problem this morning - I think Package Control's dependency logic is flawed - my solution was just to go Packages -> Browse Packages, delete the mdpopups folder and restart ST, to force it to download the latest version.

Satisfy Dependencies does nothing again

• ST ver.: 3120
• Platform: windows
• Arch: x64
• Plugin ver.: 2.1.0
• Install via PC: True
• mdpopups ver.: 1.9.1
• markdown ver.: 2.6.6
• pygments ver.: 2.1a0
• jinja2 ver.: 2.8

in the console after running Package Control: Satisfy Dependencies:

Package Control: All dependencies have been satisfied

lies! I guess if this is going to be a common occurrence, you might want to take a look at the Package Control code @facelessuser and fix it once and for all

[wbond]

I’ve resolved a few PC issues recently, and have a few related to dependencies (including looking into why upgrades aren’t happening) left before I cut the next beta.

[facelessuser]

lies! I guess if this is going to be a common occurrence, you might want to take a look at the Package Control code @facelessuser and fix it once and for all

Man, I don’t have time for that .

Even easier, I’m just going to start telling people to remove mdpopups, then run Satisfy Dependencies. It will update for sure then . But it looks like @wbond is on it.

[kaosmos]

@facelessuser and @Equinusocio
I wrote to you both since I’m sure which one is the right man for the job

I used pretty extensively CH with my fav theme (Material Theme, ofc) and now I’m wondering if it is possibile to modify a behavior that seems hard coded.

The color thumb appears just before the color name/code, e.g.:

when you modify a color this sort of visual glitch happens:

Not a big deal but it annoys your visual focus on the string you are currently writing, I believe it would be better if the thumb appears after the color code.

I guess it depends on the actual CSS of the phantoms which is chosen in part by CH and in part by MT (as you wrote before in the thread) but I’m pretty noobish about sublime plugin/themes so… is there a way for me to change the position of the thumbs or it is something that depends on some changes to the packages?

[facelessuser]

@kaosmos, the position of the preview is not related to CSS, but is a hard coded choice I made in the ColorHelper code. I think when I first did it, I had it after, but now I do it before. Currently I only offer the default display of the preview.

[kaosmos]

@facelessuser thank you for the very fast answer!
I think it is slightly better (usability-wise) to have it after but (of course) I can absolutely cope with it.
Just in case I take some time to study and I change it, do you accept pull requests on this kind of things?

[facelessuser]

The problem is that some like it before and some like it after. I either need to support both, or one way. I like the current method because the color is actually within the text region containing the color text and simplifies logic. Putting it after places it outside the text region of the color. I also like that in situations where you have multiple color keys, regardless of the whether you use rgb or hex or whatever, the previews line up nicely.

It is really a personal preference thing. I’m certain there are convincing arguments to do it either way. The question is more, do I want to support multiple ways, and I am not sure if I do or not.

[kaosmos]

I see your points and fully understand them.
But still I’m hoping that you change your mind about it