Hello Alan,
On 21.07.08, Alan G Isaac wrote:
> OK, I take it my post was long enough to get its
> reading post-poned. So, below are the questions
> in summary.
It's on my internal TODO list and I'm glad that you pushed me a bit so I
can get rid of it...
> Q1. Why do we need g.finish() and not just g.dolayout()
> to get access to the path of a plotitem?
At least you need to do doplot, otherwise the path is not defined.
> Q2: How do we know the "direction" of an xgridpath?
> Is it always from lesser to higher values?
Sorry, only André can answer that precisely.
> Q3: When considering the result of a path intersection,
> is it correct to say that the "parameter values" in the
> returned lists are ``normpathparam`` object, and that these
> are a normalized way of characterizing a point along the
> path.
Indeed, you get a normpathparam. Normpathparams are used internally
instead of arc lengths in order to properly support the case of
discontinous paths, i.e., ones consisting of more than one normsubpath.
But all that inner guts should be pretty much hidden to the user.
At least, when we introduced this change a couple of releases
ago, nobody noticed (read: complained).
> Q4: Is there a good reason to ``close`` the area, or is
> that just for completeness? (I'm going to guess that without
> the close, half of the axis line will be covered by the gray
> area.)
When filling an area, PostScript (and hence PyX) always implicitly
closes all sub-paths. So it wouldn't make a difference here.
> Q5: might it be worth it in the documentation to explicitly
> mention the ``<<`` operator for normpath?
> (Ex post, I understand you could say this is just another
> method.)
Yes, this part of the documentation still needs to be written.
There's a long-standing TODO list item in the CHANGES file...
But Michael described it very clearly.
> Q6. Once I have the answers, should I revise the write up?
> (I.e., do you want to use it as part of the posted example?)
It would be nice to have it somewhere. In the example it will
be rather long, especially if you compare it to the other gallery
examples. On the other hand, it's better to have more documentation
than less...
In the optimal case, we would have a new section in the tutorial
styles examples, say: "Graph methods". There one could
explain using more simpler examples various concepts like
the do...-methods, gridpaths, etc.
The format is quite simple, have a look in the source distribution.
Basically it's one Python file for the drawing and a text file
with some simple markup rules for the explanation. Additionally,
there's an INDEX file in every directory which defines the order
of the examples.
So to summarize: If you could extend the example (in that case, please
use the standard comment prefix # instead of the text strings), it's
would be already very helpful. If you could split it in "orthogonal"
sub-examples for the tutorial section, it would be optimal. Our hope
always was that we get some user help for this part.
Best,
Jörg
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
PyX-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pyx-user
