Salut, On 15.10.09, Joerg Lehmann wrote: > On 15.10.09, André Wobst wrote:
> > There also is (or was) a canvas set method. However, I consider this a > > bad design and we are about to remove that (am I right, Jörg?). > > Yes, we wanted to get rid of this. AFAIR we mostly kept it for technical > reasons. We had some discussions about canvas.clip at this point. I vaguely remember that there was an argument why clipping is different and should be kept as an attr of the canvas constructor. André, Jörg? > > Its also questionable, whether the canvas constructor attrs-field is a > > good design decision. I remember having argued against it. Anyway, it is > > likely to stay(?). To my mind, the cleanest way of setting attributes is > > while inserting a canvas in another canvas. > > > > c = canvas() > > c2 = canvas() > > c.insert(c2, [style.linewidth(1)]) > > I also don't like the attrs argument of the canvas class too much, but > the solution with two canvases is too complicated. > Anyway, I have to say that in general you should use > unit.set(wscale=...) instead of setting a default linewidth, since then > also linewidth.thick, etc., work as wanted. As André has pointed out, > though, finding the right scaling factor for a given line-width is > non-trivial, although possible. Btw, that would be an argument for a > more natural base for the linewidth. As wscale scales _only_ the linewidth (there is already the other parameter vscale for the rest), I fear that we introduce too many control parameters for the same thing. Either we keep wscale or we introduce a way to reset the defaultlinewidth. Concerning the "more natural" base for the linewidth, I insist on a good looking one ;-) > > However, I don't consider this to be that important. Other things > > clearly are, like doing a new release this year (which is a new year's > > pledge of mine, and I still hope to get it done). > > Yes :-) > > >>> PS Btw, it is great to be able to sum(mypaths,path()), > >>> but might it be worth defining mypath+0 to be mypath > >>> so we can just sum(mypaths)? Not sure this is a good > >>> idea but thought I'd throw it out there. Every time I want to combine paths, I have to learn again the difference between adding path elements to an other path, or adding whole subpaths. The result is of course different at the joinings. The behaviour is even different for paths and for normpaths. I then recognize that the variety of variants is wanted and reasonable. I think that a single notation such as "sum(mypaths, path())" is too implicit. One never knows what will happen. Btw: There used to be a "glue" which has been abandoned. Why? -- Michael Schindler Laboratoire de Physico-Chimie Théorique. ESPCI. 10 rue Vauquelin, 75231 Paris cedex 05, France. Tel: +33 (0)1 40 79 45 97 Fax: +33 (0)1 40 79 47 31 http: www.pct.espci.fr/~michael ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ PyX-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pyx-user
