Re: pigment API

> As a result I'd like to propose we alter these two
methods on KoColor:
alter, definitively not, for performance reason as well, the
less you create 
KoColor object the better.

>   void   fromQColor (const QColor &c) const
>      Convenient function for converting from a QColor.
>    void   fromQColor (const QColor &c, quint8
opacity) const
>
> to be static factory methods (i.e. return a KoColor).
> An API like;
>   static KoColor fromQColor(const QColor &color);
>   static KoColor fromQColor(const QColor &color,
quint8 opacity);

They would also need a KoColorSpace*, unless it is assumed
that in this case 
the color space is RGB 8bit.

But that said, I think those function should be merged in
static KoColor fromQColor(const QColor &color, quint8
opacity = 
Q_UINT8_MAX ); // I don't remember if there is a
OPACITY_OPAQUE defined 
somewhere

> Note that those two methods are only used in; karbons
vcolordocker.cc,
> vgradientwidget.cc and kritas image/kis_gradient.cc
>
> As we move to have most usages in KOffice be instances
of KoColor instead
> of QColor, and we minimize convertions from QColors, it
would be a good
> idea to convert some of the constructors that take a
QColor to static
> factory methods as well.
>
> The benefit there is that it makes the intend (use
KoColor everywhere) much
> clearer.

either way I don't really care, is there a (kde|koffice)
policy or something 
like that ?

And same for this static function/constructor, only one is
enought and should 
be (const QColor&color, KoColorSpace* cs, quint8 opacity
= Q_UINT8_MAX )


-- 
Cyrille Berger
_______________________________________________
koffice-devel mailing list
koffice-develkde.org
h
ttps://mail.kde.org/mailman/listinfo/koffice-devel