jQuery Forum

There's been talk of developing a color base plugin that an eventual colorpicker widget would use, similar to how the datepicker refactor will be done in two parts - a date library, and then a datepicker widget. I wonder if we need to consider that in this. One consideration is that it might introduce a depedency between effects and the rest of UI, which we've not had up to this point. For example, it wouldn't make sense for ui.colorpicker.js to depend on effects.core.js. And up to now, no effects.*.js file has depending on any ui.*.js file. But if we created a ui.core.color.js... So the flip side is that we don't want duplication of methods that work with colors in these two areas.
- Richard

How about making those methods public for now, with the explicit
warning that they move to a different file in a later release. That
would work assuming we find a good namespace now that we can keep
later.
Jörn

Both effects and colorpicker need color-management routines, so I
can't see any way to avoid duplication without having a common
library. It would make the whole dependency graph more complicated,
obviously, but why not create utility.*.js files for the date and
color libraries?
-Danny

It's the namespace we have to support, yeah. I'd be ok with the file dependency changing later on.
- Richard

How about $.ui.color for color related utilities, eg. $.ui.color.getRGB?
Date could then be $.ui.date.
Or we make it simpler, just $.color and $.date as the namespace.
Jörn

We could do like the rest of our plugins, and have it live in $.ui, but be accessible directly in $.
- Richard

Hi, I started work on a color library a while back, and it was
intended to fit nicely with jQuery UI or even become part of the
project.
The current work can be found here:
http://github.com/jollytoad/jquery.color
The library is broken down into modules depending on the needs of the user.
There is a parser - adapted from ui.effects in fact, and some
manipulation functions and also a Color object to make more complex
conversions easier - that supports method chaining.
I intend (time permitting) to add some unit tests, demos and docs -
eventually ;)
2009/5/7 Jörn Zaefferer <joern.zaefferer@googlemail.com>:
>
> How about $.ui.color for color related utilities, eg. $.ui.color.getRGB?
>
> Date could then be $.ui.date.
>
> Or we make it simpler, just $.color and $.date as the namespace.
>
> Jörn
>
> On Thu, May 7, 2009 at 2:50 PM, Richard D. Worth <rdworth@gmail.com> wrote:
>> It's the namespace we have to support, yeah. I'd be ok with the file
>> dependency changing later on.
>>
>> - Richard
>>
>> On Thu, May 7, 2009 at 8:40 AM, Jörn Zaefferer
>> <joern.zaefferer@googlemail.com> wrote:
>>>
>>> How about making those methods public for now, with the explicit
>>> warning that they move to a different file in a later release. That
>>> would work assuming we find a good namespace now that we can keep
>>> later.
>>>
>>> Jörn
>>>
>>> On Thu, May 7, 2009 at 1:58 PM, Richard D. Worth <rdworth@gmail.com>
>>> wrote:
>>> > There's been talk of developing a color base plugin that an eventual
>>> > colorpicker widget would use, similar to how the datepicker refactor
>>> > will be
>>> > done in two parts - a date library, and then a datepicker widget. I
>>> > wonder
>>> > if we need to consider that in this. One consideration is that it might
>>> > introduce a depedency between effects and the rest of UI, which we've
>>> > not
>>> > had up to this point. For example, it wouldn't make sense for
>>> > ui.colorpicker.js to depend on effects.core.js. And up to now, no
>>> > effects.*.js file has depending on any ui.*.js file. But if we created a
>>> > ui.core.color.js... So the flip side is that we don't want duplication
>>> > of
>>> > methods that work with colors in these two areas.
>>> >
>>> > - Richard
>>> >
>>> > On Thu, May 7, 2009 at 7:29 AM, Jörn Zaefferer
>>> > <joern.zaefferer@googlemail.com>

Mark's color library looks interesting. Is there a demo or docs
anywhere to explain exactly what this does?
It looks like there are some static preset palettes of standard colors
which might come in handy for our color pickers. How are those
currently used?
Do you know if there are color utilities that can adjust hue, color
saturation, value and contrast? For example, if i passed in a hex
value like #3366cc, could it be cool to ask for one step darker or a
10% more saturated version. We were discussing the idea of adding a
lever to themeroller to globally tweak the colors of a whole theme at
once by simply dragging sliders for hue, saturation and maybe value
(light > dark). This would make it really fast to take a green theme
and shove it to blue or red with just a single slider, like in
Photoshop. To do this in Themeroller, we'd just loop through the hex
value inputs and pass them to this utility and say 'shift the hue
values by 6%' and the TR would take care of the rest.
_t

2009/5/7 Todd Parker <fg.todd@gmail.com>:
>
> Mark's color library looks interesting. Is there a demo or docs
> anywhere to explain exactly what this does?
Sorry, not much in the way of this yet - not had the time - but there
is some experimental stuff here:
http://test3.internal.adaptavist.net/~mgibson/
Take a look at the colour picker demos - unfortunately the dialog demo
is a bit broken at the minute - but some bit works - it's mainly just
the layout that is broken.
There are some 'surface' widgets there too that you may find useful -
for a Hue slider/wheel and a Saturation-Value square or triangle
(invisible triangle! not had chance to create an image for it yet).
> It looks like there are some static preset palettes of standard colors
> which might come in handy for our color pickers. How are those
> currently used?
The palettes can be used by the parser, and I use them in my
experimental colour picker.
> Do you know if there are color utilities that can adjust hue, color
> saturation, value and contrast? For example, if i passed in a hex
> value like #3366cc, could it be cool to ask for one step darker or a
> 10% more saturated version. We were discussing the idea of adding a
> lever to themeroller to globally tweak the colors of a whole theme at
> once by simply dragging sliders for hue, saturation and maybe value
> (light > dark). This would make it really fast to take a green theme
> and shove it to blue or red with just a single slider, like in
> Photoshop. To do this in Themeroller, we'd just loop through the hex
> value inputs and pass them to this utility and say 'shift the hue
> values by 6%' and the TR would take care of the rest.
There are currently analogous and complementary functions that take a
hue offset.
(hue, saturation and value are normalized to the range 0..1 throughout)
eg: $.color.HSV.analogous([0.5,0.5,0.5], 0.2)
You can chain methods and convert between colour spaces using the
$.Color object:
eg: $.Color('#f00').method('analogous')(0.2).to('HEX')
This parses '#f00', fetches the $.color.HSV.analogous function,
converting to HSV along the way, then calls the returned method with a
hue offset of 0.2 and finally converts back to a hex value!
This allows you to put mutation functions in the most appropriate
colour space and have the Color object perform the necessary
conversions internally.
> _t
>
> On May 7, 9:11 am, Mark Gibson <jollyt...@gmail.com> wrote:
>> Hi, I started work on a color library a while back, and it was
>> intended to fit nicely with jQuery UI or even become part of the
>> project.
>>
>> The current work can be found here:
>>
>> http://github.com/jollytoad/jquery.color
>>
>> The library is broken down into modules depending on the needs of the user.
>> There is a parser - adapted from ui.effects in fact, and some
>> manipulation functions and also a Color object to make more complex
>> conversions easier - that supports method chaining.
>>
>> I intend (time permitting) to add some unit tests, demos and docs -
>> eventually ;)
>>
>> 2009/5/7 Jörn Zaefferer <joern.zaeffe...@googlemail.com>:
>>
>>
>>
>> > How about $.ui.color for color related utilities, eg. $.ui.color.getRGB?
>>
>> > Date could then be $.ui.date.
>>
>> > Or we make it simpler, just $.color and $.date as the namespace.
>>
>> > Jörn
>>
>> > On Thu, May 7, 2009 at 2:50 PM, Richard D. Worth <rdwo...@gmail.com> wrote:
>> >> It's the namespace we have to support, yeah. I'd be ok with the file
>> >> dependency changing later on.
>>
>> >> - Richard
>>
>> >> On Thu, May 7, 2009 at 8:40 AM, Jörn Zaefferer
>> >> <joern.zaeffe...@googlemail.com> wrote:
>>
>> >>> How about making those methods public for now, with the explicit
>> >>> warning that they move to a different file in a later release. That
>> >>> would work assuming we find a good namespace now that we can keep
>> >>> later.
>>
>> >>> Jörn
>>
>> >>> On Thu, May 7, 2009 at 1:58 PM, Richard D. Worth <rdwo...@gmail.com>
>> >>> wrote:
>> >>> > There's been talk of developing a color base plugin that an eventual
>> >>> > colorpicker widget would use, similar to how the datepicker refactor
>> >>> > will be
>> >>> > done in two parts - a date library, and then a datepicker widget. I
>> >>> > wonder
>> >>> > if we need to consider that in this. One consideration is that it might
>> >>> > introduce a depedency between effects and the rest of UI, which we've
>> >>> > not
>> >>> > had up to this point. For example, it wouldn't make sense for
>> >>> > ui.colorpicker.js to depend on effects.core.js. And up to now, no
>> >>> > effects.*.js file has depending on any ui.*.js file. But if we created a
>> >>> > ui.core.color.js... So the flip side is that we don't want duplication
>> >>> > of
>> >>> > methods that work with colors in these two areas.
>>
>> >>> > - Richard
>>
>> >>> > On Thu, May 7, 2009 at 7:29 AM, Jörn Zaefferer
>> >>> > <joern.zaeffe...@googlemail.com>

2009/5/7 Mark Gibson <jollytoad@gmail.com>:

Hi Mark -
This is some very cool stuff. I was able to play with the dialog demo
(nice, using framework classes):
http://test3.internal.adaptavist.net/~mgibson/colorpicker/demo2.html
And it has a lot of the features I was hoping to build into our color
picker such as:
- Named sets of color presets
- History of recent color swatches
- Photoshop-style picker (not the circular Farbtastic one which is
hard to use)
The addition of the related colors is very, very cool and really
useful when putting together a palette.
This also gives me the idea of using these calculations to make a
Photoshop-style variations display of colors to let people move in
increments darker, lighter, more saturated and less saturated from the
currently selected swatch. Imagine the selected color as a big block
in the center with narrower bars
- above (lighter version)
- below (darker)
- to the left (less saturated)
- to the right (more saturated
You could even add 4 more blocks for the diagonals (darker + more
saturated) if you wanted to get fancy. This would be a slick way to
shift colors around.
I took some of these ideas and updated the designs for our color
picker here:
http://jqueryui.pbworks.com/ColorPicker
Please help us out by fleshing out the color library planning page
with links to your code and at least a high level list of features you
think this library should have (a lot of what you said above)
http://jqueryui.pbworks.com/Color-Library
_t

2009/5/8 Todd Parker <fg.todd@gmail.com>:

Just a quick update on the Colour Library.
I've started the documentation, can be found here:
http://www.adaptavist.com/display/free/jQuery+Colour+Library
(feel free to sign up and comment)
and updated the links on pbworks.
I've also rearranged the repository, added Makefile to concat it all,
and added QUnit framework for the unit tests - although not had much
time to write many tests yet:
http://github.com/jollytoad/jquery.color
- Mark
2009/5/8 Mark Gibson <jollytoad@gmail.com>:

Hi Mark -
This is looking really good. I really hope to get a color picker based
on this together this year.
Keep us up to date on your progress and thanks for moving this along.
_t