[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: [Uml-devel] Re: karbon/umbrello
From:       rwlbuis () xs4all ! nl
Date:       2003-05-22 6:21:27
[Download RAW message or body]

Hi Andrew,

> if this is all going to be c++, we should pull dirk in and use KPainter as
> the
> main painter/paintdevice lib. i see two major differences in paradigm:
> opal/karbon uses objects to describe paths. KPainter relies on the *To()
> methods to establish paths. these are actually fairly reconcilable. the

 Right, the objects just use those *To() methods to draw themselves...
This works well, though if there are performance problems, caching some
lowlevel path structures could be an option...

> other
> main differences come from the stroke, pattern, fill, gradient and color
> classes. these should receive alot of attention so we can establish a set
> of
> standard interfaces for KDE.

 Already in the ruby version there is some attempt at this.
I am hesitating with the C++ version because we want to introduce
a more powerful concept, the renderstack or renderlist. Basically its a
rendering pipeline that allows multiple rendering actions on the same
source path data. For instance its possible then to do multiple strokes,
but also part of it could be filter actions like "Gaussian Blur" etc.
Designing this and also adding sharing of styles/gradients/patterns is not
so easy :) Luckily Ilustrator already has this concept, and we can figure
out some detials of how to do it from that implementation.

> i must not have gotten the right version, because there wasn't a c++
> version.
> otherwise, i suppose i'd need cvs access or something.

 Aah, you got the package from the website.
Yes, the C++ is only in cvs. You can also browse it here :

http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdenonbeta/opal/cplusplus/

> also, i liked dirk's ideas on some of the core painting objects:
> specifically,
> the way he deals with patterns and the like... (from above).
>
> class Fill;
> class SolidFill : public Fill;
> class GradientFill : public Fill;
> class PatternFill : public Fill;
> class BrushFill : public Fill;

 Seems like a lot of classes. Also I assume brush == pattern.
I am still thinking about the design of stuff like this...

> the same goes for strokes and patterns too. i think that's a pretty good
> abstraction. the only problem i might have with this is the use of
> copy-by-value painting objects. using this design.
>
> how do i get a copy of the version that you're talking about?

 See above :)
Cheers,

Rob.
_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]