Bug 85353

I think this may have to do with trying to avoid generating colours close to the plot background colour in the data wizard.

Speaking of curve colors, there is one thing that I always found strange: if I plot 4 curves in 4 graphs (i.e. 1 curve per graph) why should they have different colors ? I think it only makes sense to autodifferentiate curve colors (and possibly width/linestyle) inside a same graph.

Yes, it might be a good idea to move the kst colour sequences into each 2dplot object.  The problem is that a curve can be in multiple plots though, which might lead to more confusion (same curve, different colours).

I do not think it is so common to have the same curve in multiple plots, and if so 1) the user can choose its color manually if he gets confused, 2) when there are many curves in a same graph it is mostly for comparison purposes within this graph so that the confusion with the same curve in another graph seems improbable to me.

CVS commit by netterfield: 

Attempt to fix color selection stuff.  Colors are more different, and a better
attempt at avoiding background colors has been implemented.

CCMAIL: 85353-done@bugs.kde.org


  M +2 -1      kst/curveappearancewidget.ui.h   1.14
  M +32 -15    kst/kstcolorsequence.cpp   1.6
  M +30 -27    kst/kstcurvedialog_i.cpp   1.60
  M +4 -6      misc/Kst Colors   1.2


--- kdeextragear-2/kst/kst/curveappearancewidget.ui.h  #1.13:1.14
@@ -11,4 +11,5 @@
 #include <qevent.h>
 #include "kstlinestyle.h"
+#include "kstsettings.h"
 
 bool CurveAppearanceWidget::showLines()
@@ -131,5 +132,5 @@ void CurveAppearanceWidget::comboChanged
 void CurveAppearanceWidget::reset()
 {
-  reset(KstColorSequence::next());
+  reset(KstColorSequence::next(KstSettings::globalSettings()->backgroundColor));
 }
 

--- kdeextragear-2/kst/kst/kstcolorsequence.cpp  #1.5:1.6
@@ -35,5 +35,5 @@ static KStaticDeleter<KstColorSequence> 
 
 QColor KstColorSequence::next() {
-  bool shift = false;
+  int dark_factor;
 
   if (!_self) {
@@ -43,28 +43,45 @@ QColor KstColorSequence::next() {
   if (_self->_ptr >= _self->_count * 2) {
     _self->_ptr = 0;
-  } else if (_self->_ptr >= _self->_count) {
-    shift = true;
-  }
-
-  if (shift) {
-    return _self->_pal->color(_self->_ptr++ % _self->_count).dark();
   }
+  dark_factor = 100 + 50* _self->_ptr/_self->_count;
 
-return _self->_pal->color(_self->_ptr++);
+  return _self->_pal->color(_self->_ptr++ % _self->_count).dark(dark_factor);
 }
 
 QColor KstColorSequence::next(const QColor& badColor) {
-  QColor suggestedColor = _self->next();
+  QColor suggestedColor;
   int sugH, sugS, sugV;
   int badH, badS, badV;
   suggestedColor.getHsv(sugH,sugS,sugV);
   badColor.getHsv(badH, badS, badV);
+  double r1, h1, f1, x1, y1, z1;
+  double r2, h2, f2, x2, y2, z2;
+  double dc;
 
-  while (1 - 1 / (sqrt((sugS*sin(sugH)-badS*sin(badH))*(sugS*sin(sugH)-badS*sin(badH)) +
-                       (sugS*cos(sugH)-badS*cos(badH))*(sugS*cos(sugH)-badS*cos(badH)) +
-                       (sugV-badV)*(sugV-badV))) < 0.8) {
+  // make sure that the new color is not close to badColor.
+  // to do this imagine HSV as defining a cone.
+  // The distance from the point of the cone is R = V / 255
+  // Angle of rotational symetry is Theta = H * 2PI/360
+  // The 2nd angle is phi = S*(PI/4)/255
+  // a color is acceptable if |C1-C2|>dcMin
+
+  r1 = badV/255.0;
+  h1 = badH*M_PI/180.0;
+  f1 = badS*M_PI/4.0/255.0;
+  x1 = r1*sin( h1 )*sin( f1 );
+  y1 = r1*cos( h1 )*sin( f1 );
+  z1 = r1*cos( f1 );
+  do {
     suggestedColor = _self->next();
     suggestedColor.getHsv(sugH,sugS,sugV);
-  }
+    r2 = sugV/255.0;
+    h2 = sugH*M_PI/180.0;
+    f2 = sugS*M_PI/4.0/255.0;
+    x2 = r2*sin( h2 )*sin( f2 );
+    y2 = r2*cos( h2 )*sin( f2 );
+    z2 = r2*cos( f2 );
+    dc = sqrt( ( x1-x2 )*( x1-x2 ) + ( y1-y2 )*( y1-y2 ) + ( z1-z2 )*( z1-z2 ) );
+  } while ( dc < 0.3 );
+
   return QColor(suggestedColor);
 }

--- kdeextragear-2/kst/kst/kstcurvedialog_i.cpp  #1.59:1.60
@@ -218,4 +218,6 @@ bool KstCurveDialogI::new_I() {
   curve->Point.setType(_curveAppearance->pointType());
 
+  if (_curvePlacement->existingPlot() || _curvePlacement->newPlot()) {
+
   KstViewWindow *w = dynamic_cast<KstViewWindow*>(KstApp::inst()->findWindow(_curvePlacement->_plotWindow->currentText()));
   if (!w) {
@@ -250,4 +252,5 @@ bool KstCurveDialogI::new_I() {
     }
   }
+  }
 
   if (haveEx) {

--- kdeextragear-2/kst/misc/Kst Colors  #1.1:1.2
@@ -1,9 +1,7 @@
 GIMP Palette
 255 0 0
-0 0 255
+200 200 0
 0 255 0
-0 0 0
-255 0 255
-60 39 138
-80 16 16
-16 80 16
+0 230 230
+0 0 255
+230 0 230

I have never had the problem of curve colors being indistinguishable from the background, but I insist (see comments #2 and #4 above) on the fact that curve colors should cycle only within a plot (or this should at least be an option).
Making the color sequence application-global sometimes also results in bad settings anyway (like if you load series of vectors from two files : it will be hard to spot which are the same).
Sure, if this is changed then in the more common case where there is only one curve per plot, there will be less fancy colors which is less appealing to the eye :-) But I think it is worth it for readability.