Re: [PyX-user] pyX design

[Andre W. <wo...@us...>]

Hi,

On 21.09.06, Joerg Lehmann wrote:
> On 21.09.06, Andre Wobst wrote:
> > On 16.09.06, andrea valle wrote:
> [ snip ]
> > > Just a curiosity.
> > > I'm having some design difficulties with PyX.
> > > In fact, typically I have to create some objects (i.e. boxes) and then 
> > > to stroke them on a canvas passing color and other attributes (e.g. 
> > > deformers).
> > > So I have to define stroking function in order to pass them my objects.
> > > The main idea in PyX  is that you have geometrical info in the object 
> > > and other "layout" info is provided by canvas methods.
> > > 
> > > This way of working is substantially procedural.
> > > To say in pseudo-code:
> > > canvas.stroke(object, red)
> > > 
> > > It would be nice to write in a OO way:
> > > object.color = red
> > > object.stroke(canvas)
> > > 
> > > So you can have thousands of object with all their layout properties 
> > > (e.g. color, smoothing, rotation), and you decide to paint them calling 
> > > a stroke method and passing the canvas.
> > > 
> > > Probably in a data plotting/graphing perspective is an unrelevant 
> > > problem, but in graphical one it would be really nice.
> > > 
> > > What do you think?
> > 
> > What you're talking about is that the canvas is an object which has
> > some intrinsic attributes attached with. While this is an resonable
> > approach, the PyX development is going to go into a very different
> > direction.
> [snip]
> 
> I fully agree with what you said here, but...
> 
> > Beside that I do understand your point in wanting to set global
> > properties. But this is something different. 
> [snip]
> 
> ... I think you misunderstood Andrea here. He does not want to set global
> properties but local ones.

Maybe. I thought about this as well before I wrote my answer. Anyway,
Andrea might clear this up.

Strictly speaking the "object" Andrea is talking about is the
decorated path, creating a canvas item out of a path and some
attributes. You could do that by hand, but I don't understand at all
why this would change anything. And we do *not* have something like
object.color. Nowhere. We just don't have such explicit attributes
anywere and we don't want them. This is something which I wanted to
say as well.

> So I would say the following. Currently the canvas is the PyX way to
> "annotate" objects with attributes like
> 
>    ap = canvas.canvas(p, attributes)

I don't understand this. We have

    dp = deco.decoratedpath(p, strokepath=..., fillpath=...,
                            styles=..., strokestyles=..., fillstyles=...,
                            ornaments=...)

but I think this is something we should not emphasize too much
(although it can be used from the outside). And it has nothing to do
with a canvas (except that it creates a canvas item out of a
mathematical path object). But all this is quite internal stuff. And
(at least at the moment) there is no dp.set() method. I think we
should stay with it. And right, we do not have a dp.stroke(canvas),
because this operation does not exist. The dp already contains the
stroke (and fill) information. It can only be inserted into a canvas,
but this operation clearly works the other way around (canvas.insert),
as we already have it.

May we further need to understand what Andrea really wanted to tell us.
I'm not sure at all ...

> However it's not yet clear, whether this will be possible in the future
> since we are thinking of removing the attributes argument of the canvas.
> But this has not yet been decided.

Right. (I mean right that we didn't yet finally decided all that. But
as I wrote my last mail, I got the impression, that we're about to do
the right thing. Sometimes it helps to just explain what we're about
to do.)


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript and PDF figures
 (_/ \_)_/\_/     with Python & TeX: visit http://pyx.sourceforge.net/