> I've read the manual over and over and I found it not so clear. In page 44,
> "The class symbol provides some symbol functions as member variables, namely:"
> could be:
> "The class symbol provides some pre-defined symbols functions as member variables which can be used as argument of symbol in graph.style.symbol(), namely:"
> 1. they are not really functions, but rather att.changelist's (the module graph.style is the one who has the private functions) of the symbol.
> 2. It already suggests the reader how they are to be used.
> Other important point is that if I want to create a custom symbol, it is non-trivial to see that it has to be of type att.changelist...
> Anyway, maybe I'm being too picky about this, but I'm also trying to do an effort to push this project forward: I'm confident it has a lot of potential, and not so many people (at least in my community) is aware of it.
> I'm would like to contribute to pyx; is there any guide for contributions for pyx? I saw the road map but it is quite "broad"... Do you accept patches, diffs, commits? I don't use svn for quite a while, but I contributed to some open-source projects before...
yes, the documentation definitely could benefit from contributions. It's
mostly written in "German English" and from a developer's perspective. A
"pure user's view" could help a lot.
Also, I agree with you that PyX deserves more attention. I've impressed
many people with PyX output already, but we need to get more users.
Though it's frustrating when people ask you more about the software than
the research on the poster ;)
I'm not one of the core PyX developers, but from my experience here:
Patches (svn or git) are always welcome on the devel list, though there
are periods of lesser activity, so don't expect rapid responses.
There is also an unofficial git-svn mirror of the official svn tree at
which I ususually keep up-to-date. (My own additions are separated out
at https://github.com/mjg/PyX; shame on github for not allowing me to
fork my own repo.)
This mirror is a straight git-svn conversion, the only exceptions being:
- I don't push out the "tag branches" which git-svn creates; rather, I
create proper annotated tags from those tagging commits with the same
commit message, tagger etc.
- In the case of botched tags (wrong root for the tree), I turn the
"layout fix commits" such as 3339 into merge commits between the botched
and the correct history, so that nothing is lost. Git's diff machinery
is then clever enough to detect the diff against the botched tree as a
move. Since these commits are in the "tag branches" they are not pushed out.
I could also push out these tag branches, of course, in case they are
useful for someone or are considered to make that mirror more complete.