Review Request: install SVM data in mimetype database; use same mimetype for SVM like LO/AOO: "image/x-svm"
Commit Hook
null at kde.org
Sun Oct 28 01:10:04 BST 2012
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105883/#review21017
-----------------------------------------------------------
This review has been submitted with commit 88b5f7af76326eea734b6c0cdd371982198c3d1f by Friedrich W. H. Kossebau to branch master.
- 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/20121028/08cfc934/attachment.htm>
More information about the calligra-devel
mailing list