> Hi,
>
> i found rome API very close to OpenVG.
> Still OpenVG is a bit superior :)
> So, i'm using it as a guide to model/implement Rome interfaces.
Excellent!
> So, here is my thoughts (i also having a draft class skeleton for them):
frankly consider that we are working on Rome because we need something
to get access to Cairo/ whatever but we are newbie at the level.
Now the good point for us is that we are smart newbies :)
and ready to learn fast.
So our first idea is
- make it work (romePluginCanvas)
- make all romeReferenceCanvas
Get feedback, improve it improve it improve it
as well as make all the code use it make all the code use it .
So thanks for your brainstorming/ideas/wishes
> Because, we could simply do:
>
> canvas fill: myPath with: myPaint
>
> instead of:
>
> canvas selectFill: myPaint.
> canvas fill: myPath.
>
> Because you anyways can't draw a paths without paints, i don't see why
> canvas should have a notion of 'current fill' or 'current paint'.
> I think that with paint's encapsulation, its not necessary.
>
>
> I'd like to hear your thoughts about it.
No idea. Now at the back end level or "reference level"
is there a value to separate?
because like that you can do
> canvas selectFill: myPaint.
> canvas fill: myPath.
> canvas fill: myPath.canvas fill: myPath.canvas fill: myPath.canvas fill:
> myPath.canvas fill: myPath.canvas fill: myPath.canvas fill: myPath.
Stef
> Paints:
>
> Paint is an object, which when applied to path, renders(draws) the
> path using paint's unique properties.
>
> I defined two methods in paint's base class:
>
> fillPath: aPath on: aCanvas
>
> self subclassResponsibility
>
> strokePath: aPath on: aCanvas
>
> self subclassResponsibility
>
> So, to draw a path, one should use a concrete paint to either fill it
> or stroke it (or both, if you want, but its handled by canvas and
> still will end up with separate fill & stroke requests to paint).
>
> I started from a quite basic things:
>
> NullPaint
> Paint which does not performs any drawing.
> Applying this paint to any path won't lead to any
> changes/processing. A simple OO approach to define 'nothing' :)
>
> SolidColorPaint
> instanceVariableNames: 'color'
>
> Paint with solid color. Most trivial thing which can be done :)
>
> RomePen
> instanceVariableNames: 'paint capStyle joinStyle width dash'
>
> A 'pen' paint is just encapsulating a set of properties, which is used
> for stroke.
> It is using another paint, which should handle the fills (in 'paint'
> ivar), while various stroke properties should be handled by itself.
> Filling with pen, will be the same as filling with its paint. While
> doing a stoke is different (includes path processing, given the values
> of pen's properties etc etc).
> I'm not sure with this part. Maybe stroke properties would be better
> to leave in canvas? Both OpenVG and Rome seems like following this
> road,
> but i don't quite like that stroke properties is global for canvas and
> lacking a proper encapsulation.
>
> CompositePaint
> Quite dumb thing. Holds a list of paints. When asked to fill or
> stroke the path, applies paints from own list.
>
> GradientPaint (abstract)
> LinearGradient
> RadialGradient
> etc..
> paints which will use gradients for fills. Nothing fancy :)
>
>
> Canvas protocol:
>
> selectFill: anObject
>
> fill := anObject asRomePaintOn: self
>
> - selects a paint which will be used for fills.
>
> selectPen: anObject
>
> pen := anObject asRomePaintOn: self
>
> - selects a paint which will be used for stokes.
>
>
> stroke: anObject
> | path |
> path := anObject asRomePathOn: self.
>
> fill strokePath: path on: self.
>
> - stroke a path using currently selected 'pen' paint
>
> fill: anObject
> | path |
> path := anObject asRomePathOn: self.
>
> fill fillPath: path on: self.
>
> - fill path using paint for fills
>
>
> fillAndStroke: anObject
> | path |
> path := anObject asRomePathOn: self.
>
> fill fillPath: path on: self.
> pen strokePath: path on: self
>
> - fill and stroke path.
>
> And from that point, i wonder, do we need to have a paint's selection
> mechanisms at all?
>
> Because, we could simply do:
>
> canvas fill: myPath with: myPaint
>
> instead of:
>
> canvas selectFill: myPaint.
> canvas fill: myPath.
>
> Because you anyways can't draw a paths without paints, i don't see why
> canvas should have a notion of 'current fill' or 'current paint'.
> I think that with paint's encapsulation, its not necessary.
>
>
> I'd like to hear your thoughts about it.
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
