Palette Options

[CSM]

Someone showed me an online color picker one day (from somewhere that they copied and ran on their own server). My first question was "Is it Canvas?" and after investigation "No. Fail." which prompted a "Could you even create one in Canvas?" So, you probably know at this point what I spent my time trying to do ...

My final result can be seen here: Canvas Color Chooser
You can drag the mouse inside the single-hue gradient area, as well as click, but because the update process for that area is slightly slower, you can only click inside the hue gradient area.

Now, with that said, I'm also a Widget developer, and save for using new Frame() instead if document.createElement("div") and using onMouseUp instead of onmouseup ... the code is essentially the same! So you can guess what I did ...

Download Palette
It is as simple looking as the online version, and it also resets each time the Widget is loaded (just like the browser). The code for colorbox.js is slightly different (major difference: having to use onMouseDrag instead of the mash of 3 events in the browser). The color js files are the same. They were taken from the latest JwL source and edited to make them more efficient for creating loads of them.

There are already color-chooser based apps on the web and in the gallery, but this is the first I know of to use Canvas!

[g6auc]

It is as simple looking as the online version, and it also resets each time the Widget is loaded (just like the browser).

Very nice, but the widget version has a few blemishes.

When I type data into the fields and press RETURN/ENTER, the data appears to disappear, I assume because the RETURN is not being rejected.

Also, the Hex field will not allow the alphabetic hex digits to be input.

The fields do not update as the other fields are changed.

This on Mac OS X 10.4.11 and K 4.5.2x10A50.

[CSM]

Very nice, but the widget version has a few blemishes.

Thanks. I figured there'd be at least a few, given the more than slight difference between the browser's forms and Y!WE's widgets.

When I type data into the fields and press RETURN/ENTER, the data appears to disappear, I assume because the RETURN is not being rejected.

It should be, I use single line text areas (I set the lines property to 1). I guess I could reject the key-press just in case.

Also, the Hex field will not allow the alphabetic hex digits to be input.

Oops. Yeah, I'll fix that.

The fields do not update as the other fields are changed.

Hm? All fields should update themselves appropriately after enter is pressed in one field. If I tried to update on the key-press, the slowness of updating the hue-gradient field would bite me. However, I'll look into seeing if the fields don't update at all.

[CSM]

Okay, I hope I fixed all the above bugs and uploaded it. Also, because the fields are all updated when you hit enter in one of the fields, that current field may update (and be different) due to rounding/floor errors. So to reduce that, I added a size option, and if you choose "large" the color picker will resize itself to 360 pixels, shifting the rounding errors off of the "hue" value.* The only way to prevent any rounding errors would be a board size of 3600 pixels ... too large for a Widget.

* Before, typing #ff00cc into the hex field would get it changed to #ff00d0, as hue is out of 360, and saturation and value are out of 100 (which the previously default board was a multiple of). With a board size of 360 pixels, the saturation and value will have floor/rounding errors, but the hex will now return what you typed in (or at least it should).

[g6auc]

... and if you choose "large" the color picker will resize itself to 360 pixels, shifting the rounding errors off of the "hue" value.* The only way to prevent any rounding errors would be a board size of 3600 pixels ... too large for a Widget.

...but the hex will now return what you typed in (or at least it should).

Try "#808080". Changes to #7D7D7D.

it would be nice®, if you supplied/assumed the # in the Hex: field, if the user omits it. I've hacked my copy.

[CSM]

Try "#808080". Changes to #7D7D7D.

Maybe I should have said the larger size will make it better, not perfect.

it would be nice®, if you supplied/assumed the # in the Hex: field, if the user omits it. I've hacked my copy.

Okay, I suppose I can add that.

There is a new version up, no changes except to work properly if the "#" is omitted.

[Cicerone Pavaloi]

You can drag the mouse inside the single-hue gradient area, as well as click, but because the update process for that area is slightly slower, you can only click inside the hue gradient area.

Maybe you can add dragging to the hue gradient area if you construct the color gradient using two gradients instead of the nested for loops. All you need is a vertical gradient from the color to white, then a horizontal gradient from black to transparent:

CODE

    function paintColorGradient(ctx, width, height, hue) {
        var rgb = new Color();
        var color = new HSV();
        color.h = hue;
        color.s = 100;
        color.v = 100;

        ctx.save();
        ctx.scale(width / 100, height / 100);
        
        //vertical color gradient
        var grad = ctx.createLinearGradient(0, 0, 0, 100);
        grad.addColorStop(0, color.getRGB(rgb).getCanvasColor());
        grad.addColorStop(1, "#FFF");
        ctx.fillStyle = grad;
        ctx.fillRect(0, 0, 100, 100);
        
        //horizontal black gradient
        grad = ctx.createLinearGradient(0, 0, 100, 0);
        grad.addColorStop(0, "#000");
        grad.addColorStop(1, "rgba(0,0,0,0)");
        ctx.fillStyle = grad;
        ctx.fillRect(0, 0, 100, 100);
        
        ctx.restore();
    }

Note that you also need to set color.v to 100 before drawing the vertical gradient.

Edit:
And better use onMouseDown instead of onClick.

This post has been edited by Cicerone Pavaloi: Oct 27 2008, 12:54 PM

[CSM]

Maybe you can add dragging to the hue gradient area if you construct the color gradient using two gradients instead of the nested for loops. All you need is a vertical gradient from the color to white, then a horizontal gradient from black to transparent.

I originally saw this employed by the image-based versions, I didn't immediately see a way to do it via Canavs. Why is it everyone always has the better idea?

And better use onMouseDown instead of onClick.

I don't see why. If you push down, then release, you trigger the onClick. If you push then drag, you trigger the onDrag ... onMouseDown doesn't improve any of those features.


Your code is faster, and overall looks better at all sizes. You win. The changes are in the update. The mouse-down location is recorded so you can't drag inside the hue area unless your drag originated from inside the strip.

The web version will be updated shortly ...

[Cicerone Pavaloi]

Why is it everyone always has the better idea?

I do tend to think like a graphic designer first, then as a programmer. In this particular case, the designer won.

I don't see why.

Because the average user is familiar with that behaviour. The system color choser reacts on mouse down, the Photoshop color choser too. Probably GIMP too.

The mouse-down location is recorded so you can't drag inside the hue area unless your drag originated from inside the strip.

That is nice, but it should work for hue area too.

[CSM]

Because the average user is familiar with that behaviour. The system color chooser reacts on mouse down, the Photoshop color chooser too. Probably GIMP too.

Fine. onMouseDown calls onClick now (that was easiest).

That is nice, but it should work for hue area too.

That's a feature. Not really ... I fixed it (in here and the web version). Took a bit to figure out what you meant.

[g6auc]

That is a vast improvement. The drag is now usable on the Macintosh, which it was not in earlier versions.

Very nice.

[Cicerone Pavaloi]

onMouseDown calls onClick now

Ok... Let me give you another reason why you should not use onClick (in this particular widget): If I start a drag in the color gradient, but end it over the hue gradient, there is a onClick event that goes to the hue gradient (and the other way around)...

[CSM]

Ok... Let me give you another reason why you should not use onClick (in this particular widget): If I start a drag in the color gradient, but end it over the hue gradient, there is a onClick event that goes to the hue gradient (and the other way around)...

That happens, but it shouldn't work at all! Plus, the onClick is due to the fact that this color chooser was originally non-dragable, but I made it so at the request of BOINCer.

Now I can understand why onDrag isn't an official event listener for the browser ... not having it requires you to handle mouse down events yourself and you don't end up with this sort of [crud]. The differences are still annoying, however, as I definitely have way different code for Y!WE as I do for the browser now (wrt events).

-- Edit --
Both versions updated, the on[cC]lick event was turned into a function, called mouseUpdate which all call instead, and the actual assignment of on[cC]lick to a function was removed.