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. |