> On Feb. 6, 2014, 1:56 p.m., Alex Merry wrote:
> > Instant issue: the README.md claims that yapgvb is only needed to generate 
> > the diagrams, but not having it installed causes kgenframeworksapidocs to 
> > fail with an ImportError (it imports depdiagram, which imports yapgvb).  
> > You need to catch and handle that ImportError in a sensible way (perhaps 
> > produce an error if the user asked for dep diagrams).
> > 
> > Second thing: why call dot directly instead of using yapgvb to render to 
> > PNG?  Although it looks like tred might not be an option in that case...
> > 
> > Third thing: have you tested with python3?
> 
> Aurélien Gâteau wrote:
>     > Instant issue: the README.md claims that yapgvb is only needed to 
> generate the diagrams, but not having it installed causes 
> kgenframeworksapidocs to fail with an ImportError (it imports depdiagram, 
> which imports yapgvb).  You need to catch and handle that ImportError in a 
> sensible way (perhaps produce an error if the user asked for dep diagrams).
>     
>     Good point. Will fix.
>     
>     > Second thing: why call dot directly instead of using yapgvb to render 
> to PNG?  Although it looks like tred might not be an option in that case...
>     
>     I don't trust yapgvb much as it has proven to be not very stable, so I'd 
> rather use the minimum from it. Furthermore, as you said, we would not be 
> able to use tred. An alternative approach would be to store the end diagram 
> as a .dot file and let Doxygen do the rendering, though I am not sure we 
> would gain much from this.
>     
>     > Third thing: have you tested with python3?
>     
>     No. I don't think we should care too much about Python 3. I'd rather have 
> it well debugged and working with one interpreter.
>     
>
> 
> Alex Merry wrote:
>     > I don't trust yapgvb much as it has proven to be not very stable, so 
> I'd rather use the minimum from it. Furthermore, as you said, we would not be 
> able to use tred. An alternative approach would be to store the end diagram 
> as a .dot file and let Doxygen do the rendering, though I am not sure we 
> would gain much from this.
>     
>     Fair enough, although did you look at pygraphviz as an alternative?  That 
> appears to mostly interface with the tools.
>     
>     > No. I don't think we should care too much about Python 3. I'd rather 
> have it well debugged and working with one interpreter.
>     
>     Currently, I believe it's running under Python 3 on the EBN (although 
> Python 2 is available there).  So... that's something to consider.

> Fair enough, although did you look at pygraphviz as an alternative?  That 
> appears to mostly interface with the tools.

I did: the problem with pygraphviz is that it does not extract enough 
information: a node is just a string, which is not enough because we need to 
know the node shape to determine the target kind (see TARGET_SHAPES in 
frameworkdb.py).

> Currently, I believe it's running under Python 3 on the EBN (although Python 
> 2 is available there).  So... that's something to consider.

Oh, I did not know that. That would be a problem: right now yapgvb does not 
build with Python 3, and since the project is quite inactive, I doubt it is 
going to change anytime soon.


- Aurélien


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115495/#review49120
-----------------------------------------------------------


On Feb. 5, 2014, 3:43 p.m., Aurélien Gâteau wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115495/
> -----------------------------------------------------------
> 
> (Updated Feb. 5, 2014, 3:43 p.m.)
> 
> 
> Review request for KDE Frameworks, Alex Merry and Aurélien Gâteau.
> 
> 
> Repository: kapidox
> 
> 
> Description
> -------
> 
> This big patch moves code from depdiagram-prepare and depdiagram-generate to 
> Python modules and make kgenframeworksapidox use those modules to generate 
> the dependency frameworks.
> 
> This only happens when it is called with the --dependency-diagrams option.
> 
> Since the patch is going to be painful to review here, I also uploaded the 
> patchset here: http://agateau.com/tmp/kapidox-depdiagram-integration
> 
> 
> Diffs
> -----
> 
>   src/depdiagram-generate adabe27 
>   src/depdiagram-prepare 3d133d9 
>   src/kapidox/__init__.py 0024723 
>   src/kapidox/data/dependencies.md 5e30d09 
>   src/kapidox/data/dependencies.md.mustache PRE-CREATION 
>   src/kapidox/depdiagram/__init__.py e69de29 
>   src/kapidox/depdiagram/frameworkdb.py 9b63c8b 
>   src/kapidox/depdiagram/generate.py PRE-CREATION 
>   src/kapidox/depdiagram/prepare.py PRE-CREATION 
>   src/kgenframeworksapidox ac34f2c 
> 
> Diff: https://git.reviewboard.kde.org/r/115495/diff/
> 
> 
> Testing
> -------
> 
> Generated the whole thing, works as expected.
> 
> 
> Thanks,
> 
> Aurélien Gâteau
> 
>

_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Reply via email to