Seems one could break the color selector down into a couple of possibilities:
1. Discrete set of color values 2. A color range Either of these could be presented using a number of layouts, such as square, spiral, or line gradient, and a number of item renderers (maybe for discrete values only). So I can identify some properties such as: - layout - width - height - color range start and color range end, or - color values (array) - item renderer Then we can provide a useful collection of layouts and item renderers for mimicking some UIs found in popular programs or OSs. On Mar 11, 2012, at 6:00 PM, Duane Nickull <du...@uberity.com> wrote: > The MX color picker was okay but very hard to use on mobile. Even if you > scale it, it is hdd to predict the expansion of colors based on horizontal > vs. vertical. To be honest, I like your idea. The colour class logic is > very simple (getColor, setColor). The UI component maybe needs a rethink? > I purposely used sliders but found myself wishing I had pad more > attention in class to RGB nuances. > > Let me work on an idea and I'll chuck it back. > D > > > ---------------- > President/COO Überity Technology Corporation > Adobe LiveCycle ES & Enterprise Specialist > Blog | http://technoracle.blogspot.com > Twitter | @Uberity @duanechaos > > > > > > > On 12-03-11 3:51 PM, "Justin Mclean" <jus...@classsoftware.com> wrote: > >> Hi, >> >>> Having thought about the CP's for a while, I came to an opinion. I used >>> to think that the uber-does-everything color picker was probably the >>> best >>> idea. >>> >>> My gut feeling is having a few different colour classes might be the >>> ultimate answer and let users pick which ones they want. >> >> Perhaps a colour picker with plug in style colour selectors would be the >> way to go? >> >> I also don't see any issue with a spark colour picker that's works in the >> same way (as far as the user is concerned) to the mx colour picker until >> we come come up with something better. >> >> Thanks, >> Justin > >
