From: Andre W. <wo...@us...> - 2006-09-21 14:59:56
|
Hi Andrea, On 16.09.06, andrea valle wrote: > (maybe I have to move it to the list) Yeah, I think so. Let me cross-post my answer to the PyX users list, since it might be of interest for others as well. > 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. We do not want some huge lists of global properties in our objects. Consider the graphs in PyX: They have all kind of (indirect) properties (like axes and data and whatever), but instead of collecting everything within the graph itself, we're trying to move all the properties further into the parts the graph is constructed of, for example into the axes, or even into the painters of the axes. To my mind it's not a good idea to have huge objects with all kind of attributes they somehow have to know about. (For example most graph systems are misdesigned in that sense.) Instead, in PyX a canvas is a very "thin object". I like that and it nicely fits into the idea of being able to add features to the PyX framework without touching any of the existing parts. For example, when we added patterns, we could just do so. There is for example not place in the canvas which has to know about fill patterns ... Beside that I do understand your point in wanting to set global properties. But this is something different. In former versions of PyX there was the functionality of setting attributes of a canvas. You could have said: canvas.set([color.rgb.red]). But we never focused on this feature and finally removed it already (IIRC). But there's still the option to set some attributes in the canvas constructor (like canvas.canvas([color.rgb.red])). I'm not sure whether this is still working, but if it is, it's not going to stay either. We don't want to have a (changeable) attribute state (or any internal state at all) within a canvas instance. Instead, the canvas instance should become completely "stateless". However (and this may surprise you), this does *not* mean that we don't want to be able to set attributes "globally". Here's how you can do that (and that's the prefered way in the long term, at least as far as I am concerned and I can confirm that my opinion has some weight in the PyX development): c = canvas.canvas() c2 = canvas.canvas() c2.stroke(path.line(0, 0, 1, 1)) c2.stroke(path.line(0, 1, 1, 0)) c.insert(c2, [color.rgb.red]) c.writeEPSfile("test") The code is untested, but I hope there's not typo. Anyway, you get an idea of what I'm talking about, right? The key point is that we want to have a canvas to be a very simplistic object ... to be just a collection of canvas items *together* with attributes *each* (a canvas item is a combination of an object and some attributes, compare to the difference between a path and a decoratored path). So attributes are properties of canvas items but not of the canvas itself. The only feature is that a canvas can become a canvas item itself: you can insert a canvas into another canvas. I do know this might lead to a little more lines of code, but it has certain structural advantages. For example a canvas does not need to take care of its graphic state and no gsave/grestore operations are needed to ensure this (as it's done at the moment, but as I said, we are about to remove that and by that we will get rid of all the unnecessary gsave/grestore statements and only keep the needed ones). And it's a very simple and clean concept. I like it ... 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/ |
From: Joerg L. <jo...@us...> - 2006-09-21 15:44:01
|
Hello, 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. So I would say the following. Currently the canvas is the PyX way to "annotate" objects with attributes like ap = canvas.canvas(p, attributes) 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. Jörg |
From: Andre W. <wo...@us...> - 2006-09-21 16:11:38
|
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/ |
From: Joerg L. <jo...@us...> - 2006-09-21 16:21:28
|
Hi, On 21.09.06, Andre Wobst wrote: > 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. Yes, a decorated path is not the right thing to do this kind of things. As you said, it's much too low-level to be used by normal users. Wrapping things in a canvas seems reasonable though and I don't understand your problem with that ;-) Jörg |
From: Andre W. <wo...@us...> - 2006-09-21 16:44:14
|
Hi, On 21.09.06, Joerg Lehmann wrote: > > > 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. > > Yes, a decorated path is not the right thing to do this kind of things. > As you said, it's much too low-level to be used by normal users. > Wrapping things in a canvas seems reasonable though and I don't > understand your problem with that ;-) Ahh, ok. I see. You want to use the canvas as a wrapper for the decorated path. Now it makes sense what you wrote. And right, we have not yet decided what a canvas could stand for in the future and how its signature could look like. Still, it looks ill-designed to me for the moment, but I have to think about this one. So don't take it serious that I don't like it at the moment. Anyway, we might already leave the points originally addressed by Andreas mail. I may not have been that wrong with my original reply. Lets see ... 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/ |
From: andrea v. <va...@di...> - 2006-09-21 16:55:01
|
(Thanks) Now, I guess that all this hermeneutics (absolutely useful in any case =20= for me) probably dependents on the structural ambiguous semantics of my =20= post... So, I try to make an example. I'm developing graphical musical notation. I need a finite set of symbols, each one having its properties. eg. a =20= red circle in a white rect represents something, a red circle alone =20 represents something other, a blue cross a third thing, a little blue =20= cross a fourth one and so on. Conceptually, I would feel comfortable in defining a class for each =20 symbol, dimensions, positions, smoothing, colors included. class FirstSymbol: def __init__(self, dimensions, positions, smoothing, color): self.dimensions =3D dimensions #etc Then I'd like to paint the objects. As evident, being a symbol I will =20= have many occurences of it in my project. (My favorite approach (totally independent from actual PyX design and =20= implementation) would be to tell the object to stroke itself on a =20 canvas, passed as an attribute of the object itself.) This said: - probably there's a already way to do it - maybe I put the whole thing in a more obscure way...-) Best -a- On 21 Sep 2006, at 18:21, Joerg Lehmann wrote: > Hi, > > On 21.09.06, Andre Wobst wrote: >> 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 =3D canvas.canvas(p, attributes) >> >> I don't understand this. We have >> >> dp =3D deco.decoratedpath(p, strokepath=3D..., fillpath=3D..., >> styles=3D..., strokestyles=3D..., =20 >> fillstyles=3D..., >> ornaments=3D...) >> >> 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. > > Yes, a decorated path is not the right thing to do this kind of = things. > As you said, it's much too low-level to be used by normal users. > Wrapping things in a canvas seems reasonable though and I don't > understand your problem with that ;-) > > J=F6rg > > = -----------------------------------------------------------------------=20= > -- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to =20 > share your > opinions on IT & business topics through brief surveys -- and earn = cash > http://www.techsay.com/default.php?=20 > page=3Djoin.php&p=3Dsourceforge&CID=3DDEVDEV > _______________________________________________ > PyX-user mailing list > PyX...@li... > https://lists.sourceforge.net/lists/listinfo/pyx-user > > Andrea Valle DAMS - Facolt=E0 di Scienze della Formazione Universit=E0 degli Studi di Torino http://www.semiotiche.it/andrea and...@un... |
From: William H. <wh...@gm...> - 2006-09-22 03:14:17
|
Andrea, On 9/21/06, andrea valle <va...@di...> wrote: > So, I try to make an example. > I'm developing graphical musical notation. > I need a finite set of symbols, each one having its properties. eg. a > red circle in a white rect represents something, a red circle alone > represents something other, a blue cross a third thing, a little blue > cross a fourth one and so on. Sorry to butt in here, but I think that what you want is quite easy. You don't really have to worry about the design of PyX - just wrap it up so it has the design you want! Is the example below anything like what you are after? Note that in my example a symbol has "fixed properties", such as shape and fill color, that are set when the symbol is first defined. These could be extended to include stroke color, linewidth, etc. Then there are "temporary properties" - size, position, angle, that can be different each time the symbol is "painted" Cheers Will ########################################################################## import pyx class Shape: "Paths for simple shapes of unit size" circle =3D pyx.path.circle(0, 0, 0.5) square =3D pyx.path.rect(-0.5, -0.5, 1, 1) class Color: black =3D pyx.color.rgb.black blue =3D pyx.color.rgb(0.1,0.2,0.8) pink =3D pyx.color.rgb(0.9,0.5,0.5) class Symbol(pyx.canvas.canvas): "A symbol with properties" def __init__(self, fillcolor=3DColor.black, alpha=3D0.5, path=3DShape.circle): =09pyx.canvas.canvas.__init__(self) =09self.fill(path, [fillcolor, pyx.color.transparency(1.-alpha)]) def paint(self, c, pos=3D(0, 0), size=3D1, angle=3D0): =09c.insert(self, [pyx.trafo.translate(*pos), =09=09=09pyx.trafo.scale(size), =09=09=09pyx.trafo.rotate(angle)]) picture =3D pyx.canvas.canvas() bluecircle =3D Symbol(fillcolor=3DColor.blue) pinksquare =3D Symbol(fillcolor=3DColor.pink, path=3DShape.square) bluecircle.paint(picture) bluecircle.paint(picture, pos=3D(1, 1), size=3D2.5) pinksquare.paint(picture, pos=3D(0, 1), size=3D1.5, angle=3D30) picture.writePDFfile("paint") ########################################################################## --=20 Dr William Henney, Centro de Radioastronom=EDa y Astrof=EDsica, Universidad Nacional Aut=F3noma de M=E9xico, Campus Morelia |
From: andrea v. <va...@di...> - 2006-09-23 23:10:22
|
Thnaks Will. you gave me precious hints. I was pretty sure that there was a way to wrap up pyx code to satisfy =20= my needs. I see that in any case the idea is to subclass a canvas. Best -a- On 22 Sep 2006, at 05:14, William Henney wrote: > Andrea, > > On 9/21/06, andrea valle <va...@di...> wrote: >> So, I try to make an example. >> I'm developing graphical musical notation. >> I need a finite set of symbols, each one having its properties. eg. = a >> red circle in a white rect represents something, a red circle alone >> represents something other, a blue cross a third thing, a little blue >> cross a fourth one and so on. > > Sorry to butt in here, but I think that what you want is quite easy. > You don't really have to worry about the design of PyX - just wrap it > up so it has the design you want! Is the example below anything like > what you are after? Note that in my example a symbol has "fixed > properties", such as shape and fill color, that are set when the > symbol is first defined. These could be extended to include stroke > color, linewidth, etc. Then there are "temporary properties" - size, > position, angle, that can be different each time the symbol is > "painted" > > Cheers > > Will > > = #######################################################################=20= > ### > import pyx > > class Shape: > "Paths for simple shapes of unit size" > circle =3D pyx.path.circle(0, 0, 0.5) > square =3D pyx.path.rect(-0.5, -0.5, 1, 1) > > class Color: > black =3D pyx.color.rgb.black > blue =3D pyx.color.rgb(0.1,0.2,0.8) > pink =3D pyx.color.rgb(0.9,0.5,0.5) > > class Symbol(pyx.canvas.canvas): > "A symbol with properties" > def __init__(self, fillcolor=3DColor.black, alpha=3D0.5, > path=3DShape.circle): > pyx.canvas.canvas.__init__(self) > self.fill(path, [fillcolor, pyx.color.transparency(1.-alpha)]) > > def paint(self, c, pos=3D(0, 0), size=3D1, angle=3D0): > c.insert(self, [pyx.trafo.translate(*pos), > pyx.trafo.scale(size), > pyx.trafo.rotate(angle)]) > > picture =3D pyx.canvas.canvas() > > bluecircle =3D Symbol(fillcolor=3DColor.blue) > pinksquare =3D Symbol(fillcolor=3DColor.pink, path=3DShape.square) > > bluecircle.paint(picture) > bluecircle.paint(picture, pos=3D(1, 1), size=3D2.5) > pinksquare.paint(picture, pos=3D(0, 1), size=3D1.5, angle=3D30) > > picture.writePDFfile("paint") > = #######################################################################=20= > ### > > > --=20 > > Dr William Henney, Centro de Radioastronom=EDa y Astrof=EDsica, > Universidad Nacional Aut=F3noma de M=E9xico, Campus Morelia > > Andrea Valle DAMS - Facolt=E0 di Scienze della Formazione Universit=E0 degli Studi di Torino http://www.semiotiche.it/andrea and...@un... |
From: William H. <wh...@gm...> - 2006-09-25 15:06:55
|
Hi Andrea, On 9/23/06, andrea valle <va...@di...> wrote: > Thnaks Will. > > you gave me precious hints. > I was pretty sure that there was a way to wrap up pyx code to satisfy > my needs. > I see that in any case the idea is to subclass a canvas. That is the way I chose to do it, although there are lots of other ways too. In fact, now that I think about it, it might have been better to use delegation instead of inheritance. That is, instead of subclassing a canvas (a Symbol _is_ a canvas) there would just be a canvas component to the Symbol class (a Symbol _has_ a canvas). All these OO subtleties are a bit beyond me, I'm afraid :) Cheers Will --=20 Dr William Henney, Centro de Radioastronom=EDa y Astrof=EDsica, Universidad Nacional Aut=F3noma de M=E9xico, Campus Morelia |