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

[Michael S. <m-s...@us...>]

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.