Colorpicker concept implementation

[Paul Irish]

Just wanted to share this..

Brian Grinsted, hacked up the devtools frontend a bit and created a concept for adding a colorpicker to the devtools:

http://www.briangrinstead.com/blog/chrome-developer-tools-colorpicker-concept

As it's a hacked frontend, it's not really distributable as an extension, but it's worth a look. ;)

_

Paul

Chrome Developer Advocate

[Peter Beverloo]

Cool! That looks really good.

For folks interested in keeping track of implementing an UI for <input type=color> within WebKit, which Web Inspector is likely to adopt, see the following two bugs:

https://bugs.webkit.org/show_bug.cgi?id=29358 "<input type=color> UI"

https://bugs.webkit.org/show_bug.cgi?id=65897 "Implement <input type=color> UI WebKit chromium part"

Best,

Peter

[Brian Grinstead]

Thanks for the mention, and the links. Any idea on how long until
this gets into a nightly build?

I couldn't really figure out how to bundle the colorpicker as an
extension (I went through the docs here:
http://code.google.com/chrome/extensions/experimental.devtools.panels.html,
but the callback seems to expect a JSON like object to create a tree,
not arbitrary HTML). I wouldn't mind spending a little more time
trying to bundle the colorpicker into dev tools if that was something
people were interested in.

Anyhow, the colorpicker (http://bgrins.github.com/spectrum/) is sort
of a polyfill for input type='color' so it might be able to drop in as
a temporary replacement until type="color" comes in. You *should*
just be able to switch <input type='spectrum' /> in the markup to
<input type='color' />. Also, I'm not sure about what features will
be available with the native control, but you can add a pallet of
colors to spectrum (so it would be pretty easy to have all the colors
already used in the page available at the bottom for easy reuse). The
things that are obstacles to doing that are that it uses jQuery (which
may not be that hard to drop if it only had to target Chrome) and
custom color parsing (but I have already built a version that swaps
the parsing out with WebInspector.Color).

Thanks,
Brian

On Oct 11, 1:47 pm, Peter Beverloo <pe...@chromium.org> wrote:
> Cool! That looks really good.
>
> For folks interested in keeping track of implementing an UI for <input
> type=color> within WebKit, which Web Inspector is likely to adopt, see the
> following two bugs:
>
> https://bugs.webkit.org/show_bug.cgi?id=29358"<input type=color> UI"https://bugs.webkit.org/show_bug.cgi?id=65897"Implement <input type=color>
> UI WebKit chromium part"
>
> Best,
> Peter
>
>
>
>
>
>
>
> On Tue, Oct 11, 2011 at 19:41, Paul Irish <paulir...@google.com> wrote:
> > Just wanted to share this..
>

> > Brian Grinsted, hacked up the devtools frontend<http://www.chromium.org/devtools>a bit and created a concept for adding a colorpicker to the devtools:
>
> >http://www.briangrinstead.com/blog/chrome-developer-tools-colorpicker...

[Alexander Pavlov]

Hey Brian,

Thanks for the really nice demo. Looking at the way things have been implemented in WebKit so far, for each platform its native color picker is going to be used for <input type="color"> (and I hear folks love the native Mac color picker so much...) However, one real drawback to the "color" input is that it explicitly does not support opacity (and of course, no uniform UI and, perhaps, a palette in the picker for all platforms). Is there any possibility for the opacity handling to be incorporated into Spectrum?

On Tue, Oct 11, 2011 at 11:45 PM, Brian Grinstead <briangr...@gmail.com> wrote:

Thanks for the mention, and the links.  Any idea on how long until
this gets into a nightly build?

When I asked Keishi Hattori about this task around 3 months ago, he said it was his highest priority, and seeing bug 65897 being actively worked on, I might suggest that it may be a couple of weeks to a month (no guarantees, of course - e.g. should he drop it altogether :))

--
-alexander

[Andrey Kosyakov]

Brian,

On Tue, Oct 11, 2011 at 11:45 PM, Brian Grinstead
<briangr...@gmail.com> wrote:

> I couldn't really figure out how to bundle the colorpicker as an
> extension (I went through the docs here:
> http://code.google.com/chrome/extensions/experimental.devtools.panels.html,
> but the callback seems to expect a JSON like object to create a tree,
> not arbitrary HTML).

Just for the record, extension sidebars support two types of content,
JSON objects that are formatted with the help of inspector's usual
object properties section and HTML pages that are shown in an iframe
(check out the setPage() method:
http://code.google.com/chrome/extensions/dev/experimental.devtools.panels.html#type-ExtensionSidebarPane
and the second example at the top of the page).

That said, it still offers somewhat limited degree of integration, as
you won't be able to interact with the style or DOM editor -- so I
think that for the decent user experience, we ultimately need the
color picker to be a part of the core DevTools.

Best regards,
Andrey.

[Brian Grinstead]

Alexander - Yes, the alpha could be supported very easily. It
basically spits out an HSV that can be augmented with alpha values.
In fact, this is almost exactly what I did in the 10K Apart contest
entry here: http://briangrinstead.com/colorstash/. Would just need to
move the input type="range" into the colorpicker UI. Maybe it could
look something like this? http://jsfiddle.net/bgrins/ge7QS/

Andrey - I agree that it would fit better in the core. What would I
have to do to get a patch accepted? I mentioned dropping jQuery and
using your existing color parsing, I assume both of these would be
necessary, anything else? It looks like there is no hsv parsing in
WebInspector.Color, so I could accept only RGBA and output only RGBA
within spectrum and let the WebInspector.Color handle conversions on
the way in and out. I have the hsvToRgb and rgbToHsv functionality
here: http://bgrins.github.com/TinyColor/docs/tinycolor.html#section-11
which could be used internally.

Thanks,
Brian

On Oct 12, 4:35 am, Andrey Kosyakov <ca...@chromium.org> wrote:
> Brian,
>
> On Tue, Oct 11, 2011 at 11:45 PM, Brian Grinstead
>

> <briangrinst...@gmail.com> wrote:
> > I couldn't really figure out how to bundle the colorpicker as an
> > extension (I went through the docs here:

> >http://code.google.com/chrome/extensions/experimental.devtools.panels...,

> > but the callback seems to expect a JSON like object to create a tree,
> > not arbitrary HTML).
>
> Just for the record, extension sidebars support two types of content,
> JSON objects that are formatted with the help of inspector's usual
> object properties section and HTML pages that are shown in an iframe

> (check out the setPage() method:http://code.google.com/chrome/extensions/dev/experimental.devtools.pa...

[Alexander Pavlov]

On Wed, Oct 12, 2011 at 6:10 PM, Brian Grinstead <briangr...@gmail.com> wrote:

Alexander - Yes, the alpha could be supported very easily.  It
basically spits out an HSV that can be augmented with alpha values.
In fact, this is almost exactly what I did in the 10K Apart contest
entry here: http://briangrinstead.com/colorstash/.  Would just need to
move the input type="range" into the colorpicker UI.  Maybe it could
look something like this? http://jsfiddle.net/bgrins/ge7QS/

Well, my primary concern was exactly the UX decision about the alpha < 1 display (e.g. a color against a checkerboard pattern or something), and the contest entry (the first link) has something similar implemented, and it would be interesting to see a similar approach implemented in the second link solution. I hope we can flesh out a consistent color picker to integrate into the DevTools frontend (it will require at least several people to assess the UI :-)).

--
-alexander

[Brian Grinstead]

Alright, I made a branch to test devtools functionality/css changes
here: https://github.com/bgrins/spectrum/tree/devtools. I have also
updated the jsFiddle here: http://jsfiddle.net/bgrins/ge7QS/4/

Notice the checkered background that shows up as you slide the alpha
range input.

I also made an option that put the checker background behind the
actual picker here: http://jsfiddle.net/bgrins/ge7QS/5/. It is a
little funky because the saturation/value gradients don't use
transparency so the black / white in the corners stay solid. This
would be easy enough to update, but I think this demo is enough to get
the picture. I'm not sure if I like that one as much, since you can't
see the actual color you are picking as strongly, but it does make the
alpha level pretty clear.

I understand wanting UI consistency. I went ahead and grabbed some
colors / borders from the devtools skin to use in those examples - and
we would probably want to have a colorpicker icon that is in a similar
style as the rest of the icons. I would imagine there being two
different swatches next to each other - one for toggling between
formats, and one for opening / closing the colorpicker (which may have
that checkered background, or may just be an icon if we went with the
checker behind the actual picker).

Thoughts?

Brian

On Oct 12, 1:46 pm, Alexander Pavlov <apav...@chromium.org> wrote:
> On Wed, Oct 12, 2011 at 6:10 PM, Brian Grinstead

> <briangrinst...@gmail.com>wrote:

>
> > Alexander - Yes, the alpha could be supported very easily.  It
> > basically spits out an HSV that can be augmented with alpha values.
> > In fact, this is almost exactly what I did in the 10K Apart contest
> > entry here:http://briangrinstead.com/colorstash/.  Would just need to
> > move the input type="range" into the colorpicker UI.  Maybe it could

> > look something like this?http://jsfiddle.net/bgrins/ge7QS/

[Brian Grinstead]

OK, I made some more changes that will hopefully help get this into
the project.

Here is the list of what changed:
* Removed all external dependancies (no more jQuery)
* Changed code formatting and style to match what was already in the
project (based off of WebInspector.Checkbox and other files in the
project)
* Got rid of all the unused options and classes
* No more custom color parsing (except for rgb to hsv and back), and
the input is always RGB in a format that matches
WebInspector.Color.rgb

Here is a demo of the changes: http://jsfiddle.net/bgrins/Bu6sn/. All
the code can be seen here: https://github.com/bgrins/spectrum/blob/devtools/Spectrum.js

What else should I do before creating a patch?

Thanks,
Brian

[Brian Grinstead]

Alright, I have thrown together a concept implementation of this
within devtools_frontend. Here is a link to the zip folder for the
modified devtools: http://dl.dropbox.com/u/185952/devtools_frontend_spectrum.zip
which I was able to run by unzipping and running Chrome with the --
debug-devtools-frontend flag.

I'd like to get some feedback on how UI could work, specifically how
the color picker interacts with the text / color formats. Also, how
should the color format be changed now, since clicking on the swatch
opens a colorpicker? I think right click to let you switch between
formats might be cool. Here is an idea for a right click menu on a
swatch (I apologize for my terrible photo editing ahead of time)
http://dl.dropbox.com/u/185952/rightclick_colorformat.png. Or it
could just be a ctrl+click to switch formats?

Any feedback on the UI for this?
Brian

[pfeldman]

Brian, this looks great. Sorry for the delay. Why don't we start the
formal process of landing this change? You should file a bug at
webkit.org/new-inspector-bug. Then you should create a ChangeLog as
suggested at http://www.webkit.org/coding/contributing.html and attach
your patch. We will perform the formal review from there.

Regards
Pavel

[Brian Grinstead]

I am having some problems building the WebKit project which is making
this patch difficult. I have followed all the instructions here:
http://www.webkit.org/building/build.html and here:
http://trac.webkit.org/wiki/HackingWebInspector, but I am still
getting build errors. Will this work with OS X 10.5? It seems you
need 10.6 for Chromium from this document:
http://code.google.com/p/chromium/wiki/MacBuildInstructions, but I
would think WebKit alone should be able to build, right?

Thanks,
Brian

On Oct 25, 5:18 am, pfeldman <pfeld...@google.com> wrote:
> Brian, this looks great. Sorry for the delay. Why don't we start the
> formal process of landing this change? You should file a bug at
> webkit.org/new-inspector-bug. Then you should create a ChangeLog as

> suggested athttp://www.webkit.org/coding/contributing.htmland attach

[pfeldman]

You could use http://code.google.com/chrome/devtools/docs/contributing.html.

Note that it is temporarily broken - you need to fetch css files from
trac.webkit.org/browser/trunk/Source/WebCore/inspector/front-end
manually and put them into the same folder.

Pavel

[Brian Grinstead]

Pavel,
This is the process I used to create the hacked frontend, but I am now
trying to figure out how to make a WebKit ChangeLog as suggested. It
seems my platform is not supported. Is there a way to generate the
ChangeLog with the instructions here: http://code.google.com/chrome/devtools/docs/contributing.html?

Thanks,
Brian

On Nov 2, 9:50 am, pfeldman <pfeld...@chromium.org> wrote:
> You could usehttp://code.google.com/chrome/devtools/docs/contributing.html.

[pfeldman]

I usually use pure WebKit for that:
1) Get WebKit using svn as described at webkit.org or using git as
explained here: http://trac.webkit.org/wiki/UsingGitWithWebKit
2) Run Tools/Scripts/prepare-ChangeLog --git-commit=HEAD (for latest
git commit) --bug=BUGNUMBER

It'll generate the changelog entry for you.

Regards
Pavel