Switch to external color library about colorjoe

[bebraw]

one-color clocks in at fewer bytes than your current color module, and I think it even has more features.

Yup. By a quick glance the API looks nice. I'm happy about CMYK support too. LAB and XYZ don't hurt either.

If you think this might be a good direction I can make the switch for you.

This is definitely a good direction and I welcome it. I'm currently implementing a HSL picker. This results in some minor changes to the structure of the project. I'll let you know when I'm done with that so you can go ahead with your work. :)

[Munter]

Cool.

I have actually made some highlevel color picker components for a work project that I can't reuse the code for. On that project is discovered that is was possible to abstract the 1d-pickers, or sliders, to a simple subclass of a slider. Basicly all you need is to give it a correct styling and have it know what color channel it is manipulating. I made it so all components knew the complete color object (all channels), and just emitted the new color with their respective channel on change.
This basicly means you can do a 1d slider and the only thing that changes across all the possible channels you might implement are two configuration options. This is including the alpha channel.

The same architecture is possible for the 2d pickers, allthough you have to configure x- and y-axis seperately and configure them as pairs.

But it really makes the code very compact and reusable for when new color spaces arrive.

[bebraw]

Hi,

Just did the restructuring. I split up the architecture a little bit. The picker is invoked like this now: colorjoe.(, , []). are a set of things that are visible on the UI in addition to the actual picking area. These include currentColor, fields and hex at the moment. See index.html for a proper example.

The arch handles change events ie. quite nicely. Ie. if the user manipulates a main slider or an extra, it propagates the changes automatically. There is only one gotcha that is related to my color lib. In some cases it gives different hex output given some hex input. This means the keyboard input can be a bit glitchy at times. I believe integrating your library might remedy this.

We probably need to think about alpha in some separate issue. It definitely would be nice to add a proper support for that.

It should be safe to proceed with your work now. Let me know if you bump into something weird and I'll look into it.

[Munter]

Sounds good.

I'll of course need to take a closer look at your changes, but I don't think supporting alpha channel will be a problem at all.
I will probably have time to look at this tomorrow or monday.

About the integration of my color lib. Do you have any preference on how to depend on externals libs? I prefer using npm myself, and since one-color is already an npm package that should be easy. Alternatives are submodules or simply copying the build source in directly. I don't recommend the last option.

[bebraw]

I'll of course need to take a closer look at your changes, but I don't think supporting alpha channel will be a problem at all. I will probably have time to look at this tomorrow or monday.

Ok. Take your time.

About the integration of my color lib. Do you have any preference on how to depend on externals libs? I prefer using npm myself, and since one-color is already an npm package that should be easy. Alternatives are submodules or simply copying the build source in directly. I don't recommend the last option.

I guess npm would be a good pick. I set up an initial package.json. Just plug your dep(s) there. You'll need to modify grunt.js as well to get the build work ok after this.

[bebraw]

I ended up doing the work myself. Feel free to review. Mostly it was pretty straight-forward.

It would be nice if you could make one.color support AMD. It would help if you could accept hexes without hash and without proper padding (ie. #ABCD). I added issues for these.

I guess I'll add CMYK field support next, tweak certain things a bit and push out a stable release.