Done.

Thanks for these references! It's amazing to me that good ideas spontaneously pop up from different sources. I like the simplicity of your interface, and I also like R.M.'s compactness.

With your comment I was encouraged to post an update. You can see it at the top of the post.

Cool !

I was going to build exactly the same thing this weekend (or probably the following one...). But for my application I need it mixed with the Opacity duality.

In my mind, that means:

• three "color" bars
  • the one you have, on the top, for the color setting
  • a black one on the bottom, for the Opacity setting, which will end up being kind of in grayscale, eventually with the checker (chess squares) underneath, as an option to a white background.
  • the blend of both in the middle (and here, the checker makes more sense)
• the Opacity setting is done exactly the same way you have done for the colors, but in order to fit into the interface, the sliders are flipped down (and obviously, there's no color slider, but just a simple 1D slider). But you should be able to add multiple control points as you have done for the color counterpart.
• so that we can set an opacity at exactly the same value of a color setting, or not, some sort of snapping to the counterpart sliders can be of great help (something that can be activated or not). In this way, when you are sliding an Opacity control point, it can snap to existing color control points, and vice versa.
• Since this is useful for technical stuff, I think that it is important to be able to specify exact values. Have you though on adding an access to an InputField (or Control)? I know that you can edit them by hand, on the code / input parameters, but having this functionality makes it more convenient for what I will explain latter (function generation).
• The output of the opacity would need to fit into the different needs of the WL:
  • together with the color information, inside the Blend, as a fourth/alpha channel
  • separated from the color information, as a function compatible with the OpacityFunction format
  • etc. (I don't know if there are other pertinent ways of feeding this into the WL; anyone?)
• with the addition of the opacity information, I think that an option to have a single function as an output, with its behaviour depending on the value of a single parameter ("Blend", "BendAndOpacity", "OpacityFunction", etc), can be of great help, avoiding the copying and past of the interface results, since we could then use it on a delayed option or inside a Dynamic content:
  • with the "Blend" or "BendAndOpacity", this function generates a static content (a Blend[something]);
  • with the "OpacityFunction", this function generated another function usable like the following OpacityFunction->colorBlenderFunction["OpacityFunction"].

As you can see, I was/am seriously thinking on doing it... It is actually a small component I need for a presentation I'm preparing for a local WRI event.

Are willing to give it a try!

For example, you can use output from the colorBlender with the Blend function to create color functions, such as

Blend[{{0,Red},{1,Blue}},x]

which would output a color blend that depends on the value of 'x'. With this format, you can create color maps like you would with ColorData functions, such as

Plot3D[Exp[-x^2 - y^2], {x, -2, 2}, {y, -2, 2}, ColorFunction -> (ColorData["TemperatureMap"][#3] &)]

could become instead

Plot3D[Exp[-x^2 - y^2], {x, -2, 2}, {y, -2, 2}, ColorFunction -> (Blend[{{0, Red}, {1, Blue}}, #3] &)]