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

[Andre W. <wo...@us...>]

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/