[prev in list] [next in list] [prev in thread] [next in thread]
List: koffice-devel
Subject: opal stuff
From: Andrew Sutton <asutton () mcs ! kent ! edu>
Date: 2003-05-22 16:42:18
[Download RAW message or body]
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic