From: Joerg L. <jo...@us...> - 2005-08-31 09:22:56
|
Hi Michael! On 31.08.05, Michael Schindler wrote: > Update of /cvsroot/pyx/pyx/test/experimental > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv28316 > > Added Files: > brace.py > Log Message: > braces that look good even when drawn huge -- but where to put them? Looks amazing! But obviously, we do not yet have a place where one could put such stuff. Maybe it would maybe be more clear if brace were a path instead of having a path() method. We could then create a new package (for instance "paths", but I'm sure there is a better name, "elements" also came to my mind) which contains only modules generating paths. In principle, already a simple circle or a line would belong there, but I'm not sure whether we want something like: paths.circle.circle(1, 2, 3) paths.line.line(1, 2, 3, 4) One could also think about grouping stuff together paths.basic.circle(1, 2, 3) paths.basic.line(1, 2, 3, 4) Then we could also say that all stuff from the basic package is so important that we inject it in the paths namespace: paths.circle(1, 2, 3) paths.line(1, 2, 3, 4) Actually, I think this is not too bad, is it? Btw, André, if we are about to split path anyway (in order to separate normpath out), we could also think about doing things like this at the same time. Adding some backwards compatibility code which issues a warning would be rather simple. Jörg |
From: Andre W. <wo...@us...> - 2005-08-31 10:16:58
|
Hi, On 31.08.05, Joerg Lehmann wrote: > On 31.08.05, Michael Schindler wrote: > > Update of /cvsroot/pyx/pyx/test/experimental > > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv28316 > > > > Added Files: > > brace.py > > Log Message: > > braces that look good even when drawn huge -- but where to put them? > > Looks amazing! But obviously, we do not yet have a place where one could > put such stuff. Maybe it would maybe be more clear if brace were a path > instead of having a path() method. That's an interesting idea. Get's a +1 from me. I was always thinking about braces to be somehow related to connectors and/or decorators. But neigher connectors nor decorators fit very well. Instead, in the first, they are path "constructors". A brace-function seems absolutely natural. I have to repeat myself: +1 > We could then create a new package > (for instance "paths", but I'm sure there is a better name, "elements" > also came to my mind) which contains only modules generating paths. In > principle, already a simple circle or a line would belong there, but I'm > not sure whether we want something like: > > paths.circle.circle(1, 2, 3) > paths.line.line(1, 2, 3, 4) > > One could also think about grouping stuff together > > paths.basic.circle(1, 2, 3) > paths.basic.line(1, 2, 3, 4) > > Then we could also say that all stuff from the basic package is so > important that we inject it in the paths namespace: > > paths.circle(1, 2, 3) > paths.line(1, 2, 3, 4) > > Actually, I think this is not too bad, is it? Interesting. But it looks a bit overdesigned. Should paths become a subdirectory? How is this subdirectory related to the path (normpath) module(s)? Do we except such a huge number of path creating functions having that much code? Get's something like a -0.5 from me ... I would suggest to split the path module into path, paths and normpath (the later is quite unimportant to the user, it should not even be imported by "from pyx import *"). > Btw, André, if we are about to split path anyway (in order to separate > normpath out), we could also think about doing things like this at the > same time. BTW I've already started to rework the pathitem signature. It seems to work very well and leads to very clean and readable code (overall it becomes less code and faster code as well). However, I'm not yet finished (pdf is not working ... I want to allow for epsilon=None to be used in that case), but I guess I can easily finish it tonight. It's not really related to this discussion, but I could easily split of the normpath (a regular user should not even notice this) ... and create a paths module at the very same time. Do we already have a consensus (otherwise this splitting can wait ... as I said, its not really related). > Adding some backwards compatibility code which issues a > warning would be rather simple. Right, we definitely should do that. 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...> - 2005-08-31 11:13:18
|
Hi André, On 31.08.05, Andre Wobst wrote: > I was always thinking about braces to be somehow related to connectors > and/or decorators. But neigher connectors nor decorators fit very > well. Instead, in the first, they are path "constructors". A > brace-function seems absolutely natural. I have to repeat myself: +1 Exactly. Don't be to focused on decorators and this whole stuff. It's a good framework and terminology for some things but definitely not for everything. > > We could then create a new package > > (for instance "paths", but I'm sure there is a better name, "elements" > > also came to my mind) which contains only modules generating paths. In > > principle, already a simple circle or a line would belong there, but I'm > > not sure whether we want something like: > > > > paths.circle.circle(1, 2, 3) > > paths.line.line(1, 2, 3, 4) > > > > One could also think about grouping stuff together > > > > paths.basic.circle(1, 2, 3) > > paths.basic.line(1, 2, 3, 4) > > > > Then we could also say that all stuff from the basic package is so > > important that we inject it in the paths namespace: > > > > paths.circle(1, 2, 3) > > paths.line(1, 2, 3, 4) > > > > Actually, I think this is not too bad, is it? > > Interesting. But it looks a bit overdesigned. Should paths become a > subdirectory? How is this subdirectory related to the path (normpath) > module(s)? Do we except such a huge number of path creating functions > having that much code? Get's something like a -0.5 from me ... Ok, but if we move the connectors there (which makes a lot of sense) and have braces there as well, we certainly don't want to put everything into one file. > I would suggest to split the path module into path, paths and > normpath (the later is quite unimportant to the user, it should not > even be imported by "from pyx import *"). Of course. > > Btw, André, if we are about to split path anyway (in order to separate > > normpath out), we could also think about doing things like this at the > > same time. > > BTW I've already started to rework the pathitem signature. It seems to > work very well and leads to very clean and readable code (overall it > becomes less code and faster code as well). However, I'm not yet > finished (pdf is not working ... I want to allow for epsilon=None to > be used in that case), but I guess I can easily finish it tonight. > It's not really related to this discussion, but I could easily split > of the normpath (a regular user should not even notice this) ... and > create a paths module at the very same time. Do we already have a > consensus (otherwise this splitting can wait ... as I said, its not > really related). Let's first do one thing and split later. Jörg |
From: Michael S. <m-s...@us...> - 2005-08-31 10:24:52
|
Hello Jörg, On 31.08.05, Joerg Lehmann wrote: > On 31.08.05, Michael Schindler wrote: > Looks amazing! But obviously, we do not yet have a place where one could > put such stuff. Maybe it would maybe be more clear if brace were a path > instead of having a path() method. Oh, this can easily be changed -- it is of no importance. > We could then create a new package > (for instance "paths", but I'm sure there is a better name, "elements" > also came to my mind) which contains only modules generating paths. In > principle, already a simple circle or a line would belong there, but I'm > not sure whether we want something like: > > paths.circle.circle(1, 2, 3) > paths.line.line(1, 2, 3, 4) > > paths.circle(1, 2, 3) > paths.line(1, 2, 3, 4) > > Actually, I think this is not too bad, is it? This is worth to be considered. But the geometry elements like line, circle, rect,... are far more basic than a brace. A brace makes no sense to me without aligning things to it. We have a similar problem as with the boxes and the connectors: Two points + orientation sign are sufficient to orient a brace. Next, the brace yields one point + orientation vector for aligning something to the brace (some text, some connectors, another brace?) It should also be possible to align a brace the other way round: one point + orientation vector --> Two points + orientation sign The boxes, when I have understood André right, should orient themselves relative to other boxes, too. Their orientation relative to one point + orientation vector is already there. The connectors, on the other hand, need more information than just points. They only work if they also have some distance information (for cuts at their ends), so I have chosen boxes (point + outline path) to be the alignment base for the connectors. So, when introducing braces in a geometry package we certainly should derive them from a class that can align (boxes?) When seen from their path capability the braces are rather like decorators. One decorates something (a path, a box, ...) with a brace, similar to the arrow heads. > Btw, André, if we are about to split path anyway (in order to separate > normpath out), we could also think about doing things like this at the > same time. What is then to remain in path? Only the pathels? Michael. -- "A mathematician is a device for turning coffee into theorems" Paul Erdös. |
From: Andre W. <wo...@us...> - 2005-08-31 10:54:19
|
Hi, On 31.08.05, Michael Schindler wrote: > This is worth to be considered. But the geometry elements like line, > circle, rect,... are far more basic than a brace. A brace makes no > sense to me without aligning things to it. We have a similar problem > as with the boxes and the connectors: > > Two points + orientation sign are sufficient to orient a brace. > Next, the brace yields one point + orientation vector for aligning > something to the brace (some text, some connectors, another brace?) > It should also be possible to align a brace the other way round: > one point + orientation vector --> Two points + orientation sign Well, isn't this whole discussion about *using* braces for example as decorators to lines or connectors between boxes. > The boxes, when I have understood André right, should orient > themselves relative to other boxes, too. Their orientation relative to > one point + orientation vector is already there. > > The connectors, on the other hand, need more information than just > points. They only work if they also have some distance information > (for cuts at their ends), so I have chosen boxes (point + outline > path) to be the alignment base for the connectors. > > So, when introducing braces in a geometry package we certainly should > derive them from a class that can align (boxes?) > > When seen from their path capability the braces are rather like > decorators. One decorates something (a path, a box, ...) with a brace, > similar to the arrow heads. Basically braces are decorators for me. But they can decorate straight lines only. They could also be used to decorate connection lines between boxes. Something like this ... but I'm not sure. However, a brace decorator would basically place some text (or different canvas, say a box) as a description text (or whatever). There might be cases, where you want to use braces directly without constructing a connection line to be decorated. I'm not that sure either, but I think so. > > Btw, André, if we are about to split path anyway (in order to separate > > normpath out), we could also think about doing things like this at the > > same time. > > What is then to remain in path? Only the pathels? The pathel's, the path itself and the helper functions to deal with arcs (conversion to beziers etc.). Overall its more than 1000 lines and thats enough to make this part its own module. The normpath is again more than 1000 lines. From the numbers alone splitting seems natural. Splitting of the paths (circle, rect, etc. seems natural), when we deside to allow for complicated path creators like the braces. As I said, its kind of 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: Magnus L. H. <ma...@he...> - 2005-08-31 11:07:25
|
Andre Wobst <wo...@us...>: > [snip] > Basically braces are decorators for me. But they can decorate > straight lines only. There is a package with braces for MetaPost that lets you do curved braces. Not sure how useful that is, but if braces are to be path decorators, it might be consistent to let them apply to all paths? -- Magnus Lie Hetland http://hetland.org |
From: Joerg L. <jo...@us...> - 2005-08-31 11:18:22
|
Hi Magnus! On 31.08.05, Magnus Lie Hetland wrote: > Andre Wobst <wo...@us...>: > > > [snip] > > Basically braces are decorators for me. But they can decorate > > straight lines only. > > There is a package with braces for MetaPost that lets you do curved > braces. Has anybody looked at this package. > Not sure how useful that is, but if braces are to be path > decorators, it might be consistent to let them apply to all paths? Exactly. And as long as this is not possible, we should not call them path decorators. Jörg |
From: Magnus L. H. <ma...@he...> - 2005-08-31 11:49:02
|
Joerg Lehmann <jo...@us...>: > > Hi Magnus! > > On 31.08.05, Magnus Lie Hetland wrote: [snip] > > There is a package with braces for MetaPost that lets you do curved > > braces. > > Has anybody looked at this package. I have only looked at the source for the arrows (implemented my own bent arrows in MetaPost at one time, to get sharp points :)... But here is the package, anyway: http://www.student.nada.kth.se/~f91-tek/cm_arrows.html I've used the brace code. One nice thing is that you can place the middle "notch" (or whatever) wherever you want along the path. Hm. Perhaps the arrow code could be useful too? After all, if we typeset text with TeX, having arrows that look consistent with the arrows in Computer Modern may not be a bad thing. (Perhaps a really parametrizable arrow class -- so the CM style could just be a special case?) -- Magnus Lie Hetland http://hetland.org |
From: Andre W. <wo...@us...> - 2005-08-31 12:37:56
|
Hi, On 31.08.05, Magnus Lie Hetland wrote: > I have only looked at the source for the arrows (implemented my own > bent arrows in MetaPost at one time, to get sharp points :)... But > here is the package, anyway: > > http://www.student.nada.kth.se/~f91-tek/cm_arrows.html Thanks for this link. Quite interesting. > I've used the brace code. One nice thing is that you can place the > middle "notch" (or whatever) wherever you want along the path. Yes, Michael's code can do that as well. It also allows you to tilt the middle notch ... ;-) > Hm. Perhaps the arrow code could be useful too? After all, if we > typeset text with TeX, having arrows that look consistent with the > arrows in Computer Modern may not be a bad thing. (Perhaps a really > parametrizable arrow class -- so the CM style could just be a special > case?) Right. At some point we could invest some time in makeing TeX-style braces and arrows to better fit the computer modern style. Meanwhile we do have arrows and we do have serveral solutions for braces, especially some which are completely (but weakly) curved when used along a straight line ... which looks quite nice. So this tells us, that (at least some) braces fit into the concept of decorators for arbitrary paths. Hence they could be implemented to be decorators and nothing else. Still it seems natural, that there are some brace-path-creation facilities, which are available as plain path constructors/creators/factories (whatever you name it). Especially Michaels curved braces, which are (currently?!;-)) available for a straigh "baseline" only, do better fit to be a path creator than to be a decorator. It could live in a newly created paths module, where for the sake of uniformity things like path.circle and path.rect should be moved into as well. 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: Andre W. <wo...@us...> - 2005-08-31 11:09:46
|
On 31.08.05, Andre Wobst wrote: > Splitting of the paths (circle, rect, etc. seems natural), when we > deside to allow for complicated path creators like the braces. As I decide > said, its kind of ... unfinished. Ops. ;-) I currently see advantages of allowing complicated path constructors in a paths module. Hence I support Jörgs idea for a split of the path module into three parts. 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...> - 2005-08-31 11:16:54
|
On 31.08.05, Andre Wobst wrote: > On 31.08.05, Michael Schindler wrote: > > This is worth to be considered. But the geometry elements like line, > > circle, rect,... are far more basic than a brace. A brace makes no > > sense to me without aligning things to it. We have a similar problem > > as with the boxes and the connectors: > > > > Two points + orientation sign are sufficient to orient a brace. > > Next, the brace yields one point + orientation vector for aligning > > something to the brace (some text, some connectors, another brace?) > > It should also be possible to align a brace the other way round: > > one point + orientation vector --> Two points + orientation sign > > Well, isn't this whole discussion about *using* braces for example as > decorators to lines or connectors between boxes. Exactly: using. > > The boxes, when I have understood André right, should orient > > themselves relative to other boxes, too. Their orientation relative to > > one point + orientation vector is already there. > > > > The connectors, on the other hand, need more information than just > > points. They only work if they also have some distance information > > (for cuts at their ends), so I have chosen boxes (point + outline > > path) to be the alignment base for the connectors. > > > > So, when introducing braces in a geometry package we certainly should > > derive them from a class that can align (boxes?) > > > > When seen from their path capability the braces are rather like > > decorators. One decorates something (a path, a box, ...) with a brace, > > similar to the arrow heads. > > Basically braces are decorators for me. But they can decorate straight > lines only. If they can only do this, then they are neither deformers nor decorators. > They could also be used to decorate connection lines > between boxes. In this sense they are connectors. So one alternative option would be to put them in the connectors module. > Something like this ... but I'm not sure. However, a > brace decorator would basically place some text (or different canvas, > say a box) as a description text (or whatever). There might be cases, > where you want to use braces directly without constructing a > connection line to be decorated. I'm not that sure either, but I think > so. You can certainly do more stuff, but the basic thing is a highly parametrized path. Jörg |
From: Joerg L. <jo...@us...> - 2005-08-31 11:04:53
|
Hello Michael! Btw: I'd really like to get comments on this issue from other people, as well, especially since most PyX users would be affected if we adopt such a new hierarchy On 31.08.05, Michael Schindler wrote: > On 31.08.05, Joerg Lehmann wrote: > > On 31.08.05, Michael Schindler wrote: > > > Looks amazing! But obviously, we do not yet have a place where one could > > put such stuff. Maybe it would maybe be more clear if brace were a path > > instead of having a path() method. > > Oh, this can easily be changed -- it is of no importance. Fine. > > We could then create a new package > > (for instance "paths", but I'm sure there is a better name, "elements" > > also came to my mind) which contains only modules generating paths. In > > principle, already a simple circle or a line would belong there, but I'm > > not sure whether we want something like: > > > > paths.circle.circle(1, 2, 3) > > paths.line.line(1, 2, 3, 4) > > > > > paths.circle(1, 2, 3) > > paths.line(1, 2, 3, 4) > > > > Actually, I think this is not too bad, is it? > > This is worth to be considered. But the geometry elements like line, > circle, rect,... are far more basic than a brace. Of course they are far more basic, but does that really matter? > A brace makes no > sense to me without aligning things to it. We have a similar problem > as with the boxes and the connectors: Hmm, but this is a different issue - which seems to be rather orthogonal to the one at hand. > Two points + orientation sign are sufficient to orient a brace. > Next, the brace yields one point + orientation vector for aligning > something to the brace (some text, some connectors, another brace?) > It should also be possible to align a brace the other way round: > one point + orientation vector --> Two points + orientation sign Ok, this would imply that there are different factory methods for a brace (in fact there already is one, namely straightbrace). But that's no problem. > The boxes, when I have understood André right, should orient > themselves relative to other boxes, too. Their orientation relative to > one point + orientation vector is already there. > > The connectors, on the other hand, need more information than just > points. They only work if they also have some distance information > (for cuts at their ends), so I have chosen boxes (point + outline > path) to be the alignment base for the connectors. Ok, but still they yield a path, no matter what things you use to build them [1]. Btw, that's why the connectors module should probably also be moved into a "paths" package. > So, when introducing braces in a geometry package we certainly should > derive them from a class that can align (boxes?) You can do that, but I think that's a different issue. > When seen from their path capability the braces are rather like > decorators. One decorates something (a path, a box, ...) with a brace, > similar to the arrow heads. Really? It didn't seem to be like that, at least at the moment. And how do you want to decorate an arbitrary path with a brace. I don't think this makes sense. On the other hand, arrow heads could go into such a module (but not the arrows decorators). > > Btw, André, if we are about to split path anyway (in order to separate > > normpath out), we could also think about doing things like this at the > > same time. > > What is then to remain in path? Only the pathels? Basically only the path class and the pathels. But that's enough. Jörg [1] The only exception here would be to be the case of a deformator, which constructs a new path out of a given one. |
From: Andre W. <wo...@us...> - 2005-08-31 11:29:43
|
Hi, On 31.08.05, Joerg Lehmann wrote: > Btw: I'd really like to get comments on this issue from other people, > as well, especially since most PyX users would be affected if we adopt > such a new hierarchy Hmm! > On 31.08.05, Michael Schindler wrote: > > Two points + orientation sign are sufficient to orient a brace. > > Next, the brace yields one point + orientation vector for aligning > > something to the brace (some text, some connectors, another brace?) > > It should also be possible to align a brace the other way round: > > one point + orientation vector --> Two points + orientation sign > > Ok, this would imply that there are different factory methods for a > brace (in fact there already is one, namely straightbrace). But that's > no problem. Also a brace decorator build out of a brace factory living in paths can additionally hide some of the complicated internal parametrization by some simplification of the usecase. That's good news, not bad one. > > The boxes, when I have understood André right, should orient > > themselves relative to other boxes, too. Their orientation relative to > > one point + orientation vector is already there. > > > > The connectors, on the other hand, need more information than just > > points. They only work if they also have some distance information > > (for cuts at their ends), so I have chosen boxes (point + outline > > path) to be the alignment base for the connectors. > > Ok, but still they yield a path, no matter what things you use to build > them [1]. Btw, that's why the connectors module should probably also be > moved into a "paths" package. I don't think so. Connectors are connecting boxes and take into account a box center (or whatever this will become in the future) and the box boundary. However, there might be quite some basic path creators in the paths module, which help to construct those paths. An great example would be the bezier curves created from the end points, the tangents and the curvatures, which is currently hidden somewhere in the deformer ... where it really doesn't belong to. Still it's controversal, whether this is really something we want to have in the paths module, since its just another parametrization to create a bezier pathitem. OTOH all allowed pathitems are defined in the path module and the path module should not grow to something with complicated numerical stuff in. A solution would be a pathitems module as well, but no ... this is would be strange too. And the bezier path constructed out of the end points and some restrictions is a real path ... it clearly has a starting point. > Really? It didn't seem to be like that, at least at the moment. I think building a brace along an arbitrary path will be quite difficult. The best you could do (and maybe that's an option), would be to use the parallel deformer, add some small line segments and run a smoother on top of it. Its not that good as a real curved brace, but its actually not that bad, as we've recently learned (especially after our smoother rework we did last weekend). So still, may be a brace along an arbitrary path is not that unlikely to be constructable. > And how > do you want to decorate an arbitrary path with a brace. I don't think > this makes sense. On the other hand, arrow heads could go into such a > module (but not the arrows decorators). Right. The arrow head path construction could go into a paths module. 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: Michael S. <m-s...@us...> - 2005-08-31 18:19:59
|
Hello, On 31.08.05, Andre Wobst wrote: > On 31.08.05, Joerg Lehmann wrote: > > On 31.08.05, Michael Schindler wrote: > > > > > Two points + orientation sign are sufficient to orient a brace. > > > Next, the brace yields one point + orientation vector for aligning > > > something to the brace (some text, some connectors, another brace?) > > > It should also be possible to align a brace the other way round: > > > one point + orientation vector --> Two points + orientation sign > > > > Ok, this would imply that there are different factory methods for a > > brace (in fact there already is one, namely straightbrace). But that's > > no problem. This is not the point I meant. You are totally right if you say that a brace is a highly parameterized path -- But a function graph, plotted from graph.graphxy.plot is also a highly parameterized path. When I draw a brace, say on a poster, grouping some figures in order to write text to them, I do not mind if this brace is a path, I want to give it the corner points of the figure group and then want to ask it where I should place my text. This is the alignment aspect I spoke of. I admit, this aspect is rather in the visionary context of André's boxes. > Also a brace decorator build out of a brace factory living in paths > can additionally hide some of the complicated internal parametrization > by some simplification of the usecase. That's good news, not bad one. Yes. > > > The boxes, when I have understood André right, should orient > > > themselves relative to other boxes, too. Their orientation relative to > > > one point + orientation vector is already there. > > > > > > The connectors, on the other hand, need more information than just > > > points. They only work if they also have some distance information > > > (for cuts at their ends), so I have chosen boxes (point + outline > > > path) to be the alignment base for the connectors. > > > > Ok, but still they yield a path, no matter what things you use to build > > them [1]. Btw, that's why the connectors module should probably also be > > moved into a "paths" package. > > I don't think so. Connectors are connecting boxes and take into > account a box center (or whatever this will become in the future) and > the box boundary. I agree with André. > However, there might be quite some basic path > creators in the paths module, which help to construct those paths. An > great example would be the bezier curves created from the end points, > the tangents and the curvatures, which is currently hidden somewhere > in the deformer ... where it really doesn't belong to. +1 from me. > > > When seen from their path capability the braces are rather like > > > decorators. One decorates something (a path, a box, ...) with a brace, > > > similar to the arrow heads. > > > > Really? It didn't seem to be like that, at least at the moment. And how > > do you want to decorate an arbitrary path with a brace. I don't think > > this makes sense. On the other hand, arrow heads could go into such a > > module (but not the arrows decorators). I neither want to decorate arbitrary paths with a brace. Whenever I draw a brace (by hand on paper) I draw it to cling to a straight line. The arbitraryly curved brace -- beside the problems with the parallel deformer -- seem to be over-designed. This has been quite a contrary discussion now, and I think it needs a summary. I have collected some of the main statements (hopefully) Jörg: - brace should be a path (highly parameterized) --> put them into new path construction package - not a path decorator (not appliable to arbitrary paths) André: - in the first, they are path "constructors" rather path creators than decorators - decorators for straight lines only Michael: - should derive from something "alignable" Magnus: - braces for arbitrary paths Thus, I still do not know where to put the braces. But that is no problem to me. At the moment, I think they would fit best in the connector module, but this is only because the connectors are not well integrated between paths, decorators and boxes, anyhow. Maybe it is best to wait until we have found/created a proper place for them? Michael. -- "A mathematician is a device for turning coffee into theorems" Paul Erdös. |
From: Joerg L. <jo...@us...> - 2005-08-31 21:16:55
|
Hi Michael! On 31.08.05, Michael Schindler wrote: [snip] > This has been quite a contrary discussion now, and I think it needs a > summary. I have collected some of the main statements (hopefully) > > Jörg: - brace should be a path (highly parameterized) > --> put them into new path construction package > - not a path decorator (not appliable to arbitrary paths) > André: - in the first, they are path "constructors" > rather path creators than decorators Actually this was exactly what I meant: there should be a separation between something which creates a path based on certain parameters and some other thing which does this for a given path. The latter thing is typically based on the former. This means that there might be two versions of nearly the same thing at different places. I think that André fully agrees with me, here. > - decorators for straight lines only > Michael: - should derive from something "alignable" They still could do so, but as just said it's quite probable that you can implement this quite easily on top of your current code. > Magnus: - braces for arbitrary paths This is indeed a bit different, as it probably requires something much more general. If this were implemented, it would be a decorator. But the current code is clearly different, so this is quite hypothetic. > Thus, I still do not know where to put the braces. But that is no > problem to me. At the moment, I think they would fit best in the > connector module, but this is only because the connectors are not well > integrated between paths, decorators and boxes, anyhow. As I wrote somewhere in one of my mails, I think this would certainly an option for the moment, i.e., in the present scheme. > Maybe it is best to wait until we have found/created a proper place > for them? +1 :-) Jörg |
From: Andre W. <wo...@us...> - 2005-08-31 22:35:51
|
Hi, On 31.08.05, Joerg Lehmann wrote: > > Jörg: - brace should be a path (highly parameterized) > > --> put them into new path construction package > > - not a path decorator (not appliable to arbitrary paths) > > André: - in the first, they are path "constructors" > > rather path creators than decorators > > Actually this was exactly what I meant: there should be a separation > between something which creates a path based on certain parameters and > some other thing which does this for a given path. The latter thing is > typically based on the former. This means that there might be two > versions of nearly the same thing at different places. I think that > André fully agrees with me, here. Right. > > Magnus: - braces for arbitrary paths > > This is indeed a bit different, as it probably requires something much > more general. If this were implemented, it would be a decorator. But the > current code is clearly different, so this is quite hypothetic. Just as a side remark: we can also build quite some braces (but not intrinsically curved as Michaels braces are) out of some straight lines and some smoothing. So we could also build a brace for this case. > > Thus, I still do not know where to put the braces. But that is no > > problem to me. At the moment, I think they would fit best in the > > connector module, but this is only because the connectors are not well > > integrated between paths, decorators and boxes, anyhow. > > As I wrote somewhere in one of my mails, I think this would certainly > an option for the moment, i.e., in the present scheme. > > > Maybe it is best to wait until we have found/created a proper place > > for them? > > +1 :-) I would prefer that for the moment as well. We might soon split the path and the normpath, just because this is much less questionable. For the path construction functions (derived classes, whatever), we can easily decide later ... 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/ |