From koffice-devel  Thu May 22 16:42:18 2003
From: Andrew Sutton <asutton () mcs ! kent ! edu>
Date: Thu, 22 May 2003 16:42:18 +0000
To: koffice-devel
Subject: opal stuff
X-MARC-Message: https://marc.info/?l=koffice-devel&m=105362193513708

okay... i've finally figured out how to get the cvs version of opal. neat 
stuff. i like the use of templates to constrain what types an object contains 
or doesn't contain. good stuff :)

some things i see missing:
- gradient
- pattern
- stroke
- fill

along with color, point and rect, i figure these class categories make up the 
painting primitives. they're pretty much universally required for vector 
graphics, painting etc. i see two possibilities for these classes - one of 
which a like alot more than the other.

1. use kpainter to define primitive painting primitives like this. these could 
or should be part of the standard painting api. this would require a 
dependency of opal on kpainter and would require us to get together to figure 
out the best possible design for these classes. we've talked about them a 
little bit. can i assume that these classes are missing for that reason? 
right, we'd also need to move Point and Rect to KPainter too. OPAL can 
subclass to provide the required affinemap support. for that matter, OPAL can 
sublcass the other primitives to provide more advanced support. this seems 
like a good idea.

2. allow kpainter to use OPAL's drawing primitives. this seems like a 
backwards dependency to me. if we do this, we'll end up with a cyclic 
dependency somewhere (boo! hiss!).

actually, that was about it. the only other issue would be kpainter 
integration - i'm not entirely sure how to go about doing that. if we make a 
kpainter compatible API, within the OPAL hierarchy, we'll probably end up 
with a nice layered affect and possibly get some good results from the 
coupling (more efficient painting for interactive canvases or something like 
that). the other option - one that i'm not as fond of would be to build a 
kpainter specific visitor. this would entirely remove the coupling and 
probably not be nearly so useful as the other option.

note that both of these options work in the absence of a dependency of 
kpainter to opal (yeah!). good layering :)

also, in addition to the vector manipulators, i'm having an idea for a graph 
layout library built on top of these things. its basically an engine that 
implements classes for various phases of graph layout (like filtering nodes, 
compaction, clustering, orthogonality - all the good stuff needed for uml 
layout :)). it could take an opal group, run through a layout pipeline and 
generate a new document with the resultant layout. best of all, it could be 
used to layout different groups within the same document - maybe. in other 
words, i've found a direct connection between opal and some of my graduate 
research ;)

aside from those issues, i like what i see. good work folks :)

andy
_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel