--===============0289884769==
Content-Type: multipart/signed;
  boundary="nextPart1781781.YBtGic4Lml";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1781781.YBtGic4Lml
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Thursday 11 August 2005 15:58, Bart Coppens wrote:

> Also, I don't think we should be adding this to the colorspaces, they're
> bloated enough already.=20

:-). What we need here is perhaps something along the lines of the composit=
e=20
ops, but for operations. So every colorspace can export the operations it=20
has, and filters and so on can request an operation and refuse to work if=20
they don't get it. That way, operations can be separated from the colorspac=
e=20
classes proper and implemented independently, and one op can be associated=
=20
with more than one colorspace. It would help with warning people that the=20
action they selected will degrade their image.

But that's probably a refactoring that will only happen after the next rele=
ase=20
(unless I get really fed up...)

=2D-=20
Boudewijn Rempt=20
http://www.valdyas.org/fading/index.cgi

--nextPart1781781.YBtGic4Lml
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQBC+1pDdaCcgCmN5d8RAj4hAKCj6I9dtql1wNfyfuTeh/6vvD9FsQCfYhu0
cXT356bnGAdGcYsdqtUv67o=
=1wOC
-----END PGP SIGNATURE-----

--nextPart1781781.YBtGic4Lml--

--===============0289884769==
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop

--===============0289884769==--