Review Request: install SVM data in mimetype database; use same mimetype for SVM like LO/AOO: "image/x-svm"

[Commit Hook]

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


This review has been submitted with commit 863685f3c0750a9688d504b2df2f6f696c550bae by Friedrich W. H. Kossebau to branch kexi-altertable-staniek.

- Commit Hook


On Oct. 27, 2012, 3:18 p.m., Friedrich W. H. Kossebau wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105883/
> -----------------------------------------------------------
> 
> (Updated Oct. 27, 2012, 3:18 p.m.)
> 
> 
> Review request for Calligra, Jarosław Staniek, Boudewijn Rempt, Thorsten Zachmann, and Inge Wallin.
> 
> 
> Description
> -------
> 
> Triggered by "Fix loading of VectorShape and KoUnavailShape." (https://git.reviewboard.kde.org/r/105873/) I had another look at the mimetype and detection of SVM files. And found e.g. these, among a lot of similar matches:
> * http://api.libreoffice.org/common/ref/com/sun/star/graphic/MediaProperties.html
> * https://svn.apache.org/repos/asf/incubator/ooo/trunk/main/filter/source/config/fragments/types/svm_StarView_Metafile.xcu
> 
> So it seems that "image/x-svm" is the internally used mimetype string, not "application/x-svm". While that one is not used in the manifest by LO (correctly, as I understood the package spec), Calligra better still should switch to use it internally as well.
> 
> And installing the magic data about SVM into the mimetype database will result both in KoOdfLoadingContext::mimeTypeForPath(const QString& path, bool guess) with guess=true delivering the proper mimetype (no longer application/octet-stream), as well as allow to use the mimetype also in the filedialogs to chose a file for the vector shape.
> 
> Also moved all three checks for SharedMimeInfo into toplevel CMakeList.txt, made it optional, and adopted the buildsystem:
> * have Krita depend on sharedmimeinfo as before (needed for ORA as default format)
> * have all ooxml import filters depend on sharedmimeinfo (otherwise formats are not detected/supported at run-time)
> * still build the vectorshape plugin, just skip if needed installing SVM info mimetype database,
>   not perfect, but would need to make SVM support optionally inside vectorshape plugin, which mainly is for EMF/WMF,
>   but the extra code/work/complexity needed for that extremely rare case IMHO is not worth it
> 
> 
> Diffs
> -----
> 
>   CMakeLists.txt 9840855 
>   filters/CMakeLists.txt 633cdf7 
>   filters/libmsooxml/CMakeLists.txt af28c28 
>   filters/sheets/CMakeLists.txt fac2a4f 
>   filters/stage/CMakeLists.txt 6f81f3d 
>   filters/words/CMakeLists.txt 9127e37 
>   krita/plugins/formats/ora/CMakeLists.txt bb0baad 
>   plugins/vectorshape/CMakeLists.txt fe677e5 
>   plugins/vectorshape/VectorShape.cpp 232402a 
>   plugins/vectorshape/VectorShapeConfigWidget.cpp ca9f743 
>   plugins/vectorshape/VectorShapeFactory.cpp 8ead482 
>   plugins/vectorshape/VectorTool.cpp f0add41 
>   plugins/vectorshape/calligra_svm.xml PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/105883/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Friedrich W. H. Kossebau
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/calligra-devel/attachments/20121031/22c32096/attachment.htm>