[haiku-development] Re: Colors!

  • From: John Scipione <jscipione@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Thu, 3 May 2012 12:54:14 -0400

On Thu, May 3, 2012 at 3:32 AM, Stephan Aßmus <superstippi@xxxxxx> wrote:

> Looking at the code, the SwatchGroup class from Icon-O-Matic would be a
>> better base to create an updated BColorControl than the ColorPickerView
>> in Colors! since ColorPickerView has a bunch of other stuff like HSV RGB
>> boxes and the eye dropper that aren't really needed in BColorControl.
>> Also SwatchGroup is around the right dimensions.
> The color picker (click the big swatch) included in I-O-M is based on
> Colors!. In retrospect, I probably should not have removed the dropper
> feature.

Perhaps so, but, I understand why you may have wanted to not include it. It
can come back in version 2.0 :)

> In any case, I've applied some heavy optimizations and also fixes to the
> Colors! code. From memory, I've optimized the gradient creation in the main
> color area and similar problems. IIRC, Colors! used to draw the color area
> in a separate thread because it was so extremely slow. But that's what you
> get for using BView::StrokeLine() for each single pixel.

What do you mean used to? From

fUpdateThread = spawn_thread(ColorField::_UpdateThread, "color field update
thread", 10, this);

Looking at that code it does appear that you made some changes to the way
the ColorField is drawn especially in the _UpdateThread() method referenced
above, most likely to speed up drawing. Meanwhile I have updated the views
in Colors! including ColorField to utilize the layout APIs. So we have each
made different improvements separately, funny how that works.

> It may be worthwhile to merge both code bases. You probably did your own
> share of improving the code. It could be nice to add the dropper and swatch
> features back to the I-O-M version, but making them optional, such that the
> swatch field can be turned off in I-O-M (programatically), but on in
> Colors!, once the code shared again. AFA sharing the code... there may be a
> place in the private shared area, which is sort of a staging area for
> eventual public APIs. After all, the code is already in the Haiku tree,
> just locked away in I-O-M. In that sense, it wouldn't make a big difference
> if Colors! became part of Haiku.

Whether or not we want to put the code in the Interface Kit or not it would
probably be a good idea to merge the improvements from the 2 codebases
together into some new classes that can be used by both apps, we could
stick the result in src/kits/shared for now until the code is ready to go.

John Scipione

Other related posts: