Review Request: Add support for dr3d:scene and its children

[Inge Wallin]

> On June 25, 2012, 6:57 a.m., Thorsten Zachmann wrote:
> > When saving I get the following error when validating the saved document.
> > 
> > content.xml:8:419: error: bad value for attribute "vertical-segments" from namespace "urn:oasis:names:tc:opendocument:xmlns:dr3d:1.0"
> > content.xml:46:205: error: required attributes missing
> > content.xml:47:205: error: required attributes missing
> > 
> > The value for vertical-segments has a % at the end which should not be there.
> > The draw:rotate miss the svg:viewBox attribute which is mandetory.
> > 
> > I think the code should not be committed before roundtripping to LO/OO does not work as this is the only thing it tries to archive up to now.

Good.  This may be the problem. Btw, which tool are you using to get these diagnostics?

And I agree about roundtripping to LO/OO.


> On June 25, 2012, 6:57 a.m., Thorsten Zachmann wrote:
> > plugins/staging/threedshape/Object3D.h, lines 81-82
> > <http://git.reviewboard.kde.org/r/105292/diff/2/?file=70349#file70349line81>
> >
> >     I think that is a bad descition as when the layers where implemented we made the explicit design decision that we use hierarchy for the shapes and when a layer does not match the parent we fix that during loading.
> >     If it is only for having style information available I think it is much easier to reuse only the style loading code and don't inherit the shapes as shape are also painted by the shape manager but I'm not sure that is wanted here.

If there is such an explicit design decision about layers, then option 2 is not just a bad decision, it's totally wrong.  But as it says in the explanation it has nothing to do with styling.  The styling works fine as it is.

As a side note, I think that these design decisions should be documented somewhere, e.g. at the community.kde.org wiki.


> On June 25, 2012, 6:57 a.m., Thorsten Zachmann wrote:
> > plugins/staging/threedshape/Object3D.h, line 99
> > <http://git.reviewboard.kde.org/r/105292/diff/2/?file=70349#file70349line99>
> >
> >     saveOdf2 is a very bad name in my oppinion. How about using saveObjectOdf?

Yeah, that is a better name.

But if we go back to just having the entire scene in one layer, then the whole method becomes unnecessary so the name doesn't matter. :)


- Inge


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105292/#review15092
-----------------------------------------------------------


On June 25, 2012, 4:52 a.m., Inge Wallin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105292/
> -----------------------------------------------------------
> 
> (Updated June 25, 2012, 4:52 a.m.)
> 
> 
> Review request for Calligra.
> 
> 
> Description
> -------
> 
> This patch adds rudimentary support for the dr3d:scene element and its children by introducing a 3D shape. The 3D support in ODF is pretty simple: it just defines 4 different object types: cube, sphere, extrude and rotate as well as a scene element that acts a bit like a group (draw:g).
> 
> I implemented all the object types as KoShapes because they can have styling and the scene object is also a KoShapeContainer. None of the shapes except for the scene itself can be modified now, and for the scene it's only the standard shape parameters (size, position, transform, etc).
> 
> My plan is to work in 3 stages:
> 1. Loading and saving - this prevents data loss
> 2. Rendering - this implements viewing
> 3. Scene and object editing
> This patch implements stage 1 only.
> 
> My goal was to load dr3d:scenes and save them back with full compatibility with OOo and LO. Unfortunately I didn't manage to do that yet. 
> 
> I have tested with Karbon during the development and it loads and savs the scenes nicely. But calling KoShape::loadOdfAttributes(..., OdfAllAttributes) in karbon still loses the layer information. This makes OOo/LO not show the shapes when they are loaded again after a roundtrip through Karbon. I have not been able to analyze why Karbon saves back all shapes with layer="" when the infile clearly has layer="layout".
> 
> And if I want to make it work in Words and presumably also Stage (and Sheets?) I have to integrate it with the KoInlineObjectRegistry in kotext, something that I have also not yet managed to do. Help would be appreciated here.
> 
> But until Karbon is fixed and Words integration is done, I'm happy to receive and integrate feedback here.
> 
> 
> Diffs
> -----
> 
>   plugins/staging/CMakeLists.txt f55b316 
>   plugins/staging/threedshape/CMakeLists.txt PRE-CREATION 
>   plugins/staging/threedshape/Messages.sh PRE-CREATION 
>   plugins/staging/threedshape/Object3D.h PRE-CREATION 
>   plugins/staging/threedshape/Object3D.cpp PRE-CREATION 
>   plugins/staging/threedshape/Objects.h PRE-CREATION 
>   plugins/staging/threedshape/Objects.cpp PRE-CREATION 
>   plugins/staging/threedshape/PLAN PRE-CREATION 
>   plugins/staging/threedshape/SceneObject.h PRE-CREATION 
>   plugins/staging/threedshape/SceneObject.cpp PRE-CREATION 
>   plugins/staging/threedshape/ThreedShapeFactory.h PRE-CREATION 
>   plugins/staging/threedshape/ThreedShapeFactory.cpp PRE-CREATION 
>   plugins/staging/threedshape/ThreedShapePlugin.h PRE-CREATION 
>   plugins/staging/threedshape/ThreedShapePlugin.cpp PRE-CREATION 
>   plugins/staging/threedshape/threedshape.desktop PRE-CREATION 
>   plugins/staging/threedshape/utils.h PRE-CREATION 
>   plugins/staging/threedshape/utils.cpp PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/105292/diff/
> 
> 
> Testing
> -------
> 
> Tested with a simple ODG file containing 3D objects.
> 
> 
> Thanks,
> 
> Inge Wallin
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/calligra-devel/attachments/20120625/28bdb06c/attachment.htm>