Re: [PyX-devel] Dash length relative to line width

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

Hi Otto,

On 21.10.03, Otto Tronarp wrote:
> I admit that my choice wasn't the best. I think that the name should
> communicate that it is a length so that leaves *len and *lengths. When
> it comes to absolute vs. relative I think that relative is more
> suitable. So if I have a vote I would vote for rellengths or rellen (or
> even relativelen).
> 
> I can prepare a new patch when you guys reaches a decision on the name
> issue.

If you spend a look to the new connector module by Michael Schindler,
the matching name would be rellengths ...

> > > BTW: What version of python do you require? Is it ok to use True and
> > > False instead?
> > 
> > At the moment we only require Python 2.1, because it is the default in
> > Debian/stable, which does not know True and False.
> > 
> > > 2: However, for this to work the linewidth must be set before we set
> > > the dash so I introduced a class member in PathStyle named prio
> > > (default 0) and I set this prio to 1 in linewidth. Then in
> > > decoratedpath::_writestyles I do a reverse sort on prio before we
> > > write the styles to file.
> > 
> > Similar ordering problems arise at other places in PyX, where we
> > use a similar solution. André, maybe we should use the mechanism
> > of the text module?
> > 
> 
> I took a quick look and it seems that it only differs on some minor
> points.
> * texsettings uses id instead of prio
> * texsettings defines a __cmp__ in the base class instead of supplying  
> sort with a custom compare function
> Besides that it also defines a class member exclusive and only one
> object with the same id is allowed if the exclusive flag is set.

Exactly.

I should tell you that there is a long standing discussion about
attributes used in methods like canvas.stroke, canvas.fill,
canvas.text and at a few other places. There is no common style in
terms of those attributes. We already thought about building a generic
interface in a new attrib-module (should become a directory with
modules like strokeattr, fillattr, textattr, color, ...) where things
like sorting, excluding, merging etc. should be implemented once and
for all. It would be nice to even include changeable attributes (the
graph has something like that right now, but I consider it a dirty
hack although I've written this specific crap myself), specialization
of attributes (I don't like the special way of arrows having a
__call__ method although we might come up with a solution using
__call__). One idea is to get rid of the problem, that you can not
easily change some default attributes provided in keyword arguments.
Suppose write some function:

def StrokeRedPathWithBlueText(c, p, t, # canvas, path, and text
                              pathattrs=[color.rgb.red],
                              textattrs=[color.rgb.blue]):
    c.stroke(p, *pathattrs)
    c.text(0, 0, t, *textattrs)

You now want stroke the path thick. You can't without repeating the
attribute color.rgb.red. That's bad. On the other hand you want to be
able to remove some default attributes (if you force a removal). And
you want some exclusion of some attributes, some sorting etc.

> I don't know if the last thing is applicable to pathstyles, but I can
> prepare a new patch with id instead of prio and that defines a __cmp__.
> What do you think?

Hmmm. I'm not sure. I think it doesn't really matter for the moment
and it is not worth the trouble to implement something very
complicated while we still have to come up with a solution on the
topic I discussed above (instead you may have some thoughts regarding
this subject as a hole).

> A general question: What is all those __implements__ about, I couldn't
> find anything that uses them in the source tree. So I thought that it
> was some feature in python, but I couldn't find anything in the
> documentation.

No, it is not a python language feature, but a coding style feature.
We use it for documentation purposes only, while some other projects
(cf. zope3) might use it for further code analysis and documentation.


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us...
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/