Re: [PyX-devel] Re: [PyX-checkins] pyx/test/experimental brace.py,NONE,1.1

[Joerg L. <jo...@us...>]

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.