Closed adqm closed 3 years ago
Also, apologies if cleaning up my code is more work than just implementing these things yourself :slightly_smiling_face: I'm having fun, anyway...
I also implemented #50 since it was related (except that remote eyedroppers currently don't change color as they move around, which I think is OK). If you want to scrap this high-level approach to #14, I think that piece is easily separable.
I finally got to working on this, merged it with the latest Cocreate, and changed the interface to something I'm happier with:
opacity:0
instead of display:none
so that <input>
color selector shows up in a useful place (not the top-left corner).input
event instead of change
event, so color change is immediate.It's all a little weird in dark mode (color selection interface isn't inverted, but everything else is), but it's functional, and I think this is good to deploy now.
This is a hacky attempt at implementing #14. I'm not sure if it's actually what's we want, and this approach differs a little from what you described in #14. Happy to discuss the high-level approach, but I figured it would be easier to do that with a working prototype than with just an idea (I've tested on Chromium 81.0.4044.138 and Firefox 77.0.1 on GNU/Linux). High level outline is below, along with some questions and concerns.
This changeset adds two new pieces:
a "custom color" square that you can use to pick a new color. when clicking on this square:
if the custom color square is already selected (or if no custom color has yet been chosen), then it opens a color picker.
if you previously chose a custom color but currently have something else selected, this just selects the old custom color again (if you want to choose a new color, you have to click again)
an "eyedropper" tool that allows switching to other colors that exist on the whiteboard
when moving around, the color of the eyedropper icon changes to match the color that will be chosen if you click.
clicking on an element switches to the drawing tool, with that element's color, regardless of whether it was a built-in color or a custom color (in the latter case, it also updates the custom color square to match the new selection)
clicking in empty space switches back to the drawing tool but does not change the selected color
A couple of concerns:
Is this approach (not remembering all custom colors, but rather allowing the eyedropper to grab arbitrary colors from the image) OK? Personally, I think I like it better than having a separate way of remembering old custom colors (since they're already "remembered" as part of the image), but...
The eyedropper icon, unfortunately, looks very similar to the pencil icon. If we stick with this approach, we might want to look for an icon from a different source...
How should we style the custom color square to make it clear that it's a custom color square, and not just another color? I thought about giving it a slightly different border, or putting a checkerboard background on it at the start, or adding some text, or....but I'm not sure that anything feels particularly great...
Right now this uses the browser's color picker (via
<input type="color">
). That's nice because it's native, but it does mean that different browsers have different UI for picking colors. Maybe we want to bring in a nice JS color picker (like this one?) instead, to provide a uniform experience, rather than using the built-in thing.There are almost certainly cleaner ways to do just about everything I did. Please don't show the 6.009 students this code :slightly_smiling_face: