Review Request 129929: Port away from KImageIO
Martin Koller
kollix at aon.at
Sun Dec 3 12:37:16 UTC 2017
> On Feb. 7, 2017, 3:10 a.m., Michael Pyne wrote:
> > Ship It!
>
> Martin Koller wrote:
> No, that won't work.
> I had a mail discussion about this in 2015:
>
>
> On Sunday 10 May 2015 19:39:07 Alex Merry wrote:
> > On Saturday 09 May 2015 22:54:49 Martin Koller wrote:
> > > I'm working on porting kolourpaint to kf5.
> > > Now I find the following:
> > > KDELIBS4SUPPORT_DEPRECATED_EXPORT QStringList typeForMime(const QString
> > > &mimeType);
> > >
> > > The comment says: Use QMimeType::name() instead().
> > >
> > > However this seems incorrect.
> > > typeForMime() returned a format string usable for QImage::save(), e.g.
> > > "image/png" returns "PNG"
> > > QMimeType::name() returns the name of the mime type, which is again
> > > "image/png", which I can not pass to QImage::save()
> > > (typeForMime() gives the X-KDE-ImageFormat field from the desktop file, and
> > > the mime type is in the X-KDE-MimeType field)
> > >
> > > So, is there a REAL alternative for this method ?
> >
> > Ah, you want QMimeType::suffixes() instead, since QImage types are essentially
> > file extensions.
>
> no, this is not the same.
> suffixes() returns a QStringList(!), for instance this would return "jpg", "jpeg" for image/jpeg.
> But the QImage::save() method needs exactly ONE specific string as format.
> How should my code know which one to use ?
>
> > I had plans a while back to submit a patch to Qt to do implement the
> > equivalent of typeForMime and its inverse properly (using the data in the
> > QImageFormat plugin metadata), but never got round to finishing it. Hopefully
> > I'll have the time and energy to pick that up again at some point.
>
> I'd say a better solution would be to simply have no need for such a method, e.g.
> allow that QImageWriter (QImage, QPimap) accepts a QMimeType.
>
> Martin Tobias Holmedahl Sandsmark wrote:
> My patch doesn't try to guess which one from a QStringList(), that's what the old code does. With this patch it uses preferredSuffix(), which solves the problem.
>
> Luigi Toscano wrote:
> Any update on this? Martin (Koller), the answer from Martin (Sandsmark) seems to address the issue that you raised.
My point is: a file suffix is not related to the QImageWriter format string.
Probably all the current image-IO plugins use - by chance - the same format string as the preferred file suffix, however I can't say for sure.
And I think this is the reason why the KDE desktop file entry X-KDE-ImageFormat was invented in the first place.
Please correct me if I'm wrong.
- Martin
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129929/#review102435
-----------------------------------------------------------
On Feb. 6, 2017, 10:36 p.m., Martin Tobias Holmedahl Sandsmark wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129929/
> -----------------------------------------------------------
>
> (Updated Feb. 6, 2017, 10:36 p.m.)
>
>
> Review request for KDE Graphics and Martin Koller.
>
>
> Repository: kolourpaint
>
>
> Description
> -------
>
> KImageIO is apparently deprecated, so use similar code to what is now used in Gwenview.
>
>
> Diffs
> -----
>
> document/kpDocument.cpp 69aa8d83
> document/kpDocument_Open.cpp 7c0be0b4
> document/kpDocument_Save.cpp 1434832a
> document/kpDocument_Selection.cpp efdd735a
>
>
> Diff: https://git.reviewboard.kde.org/r/129929/diff/1/
>
>
> Testing
> -------
>
> Saving as different formats works as expected here.
>
>
> Thanks,
>
> Martin Tobias Holmedahl Sandsmark
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-graphics-devel/attachments/20171203/ebe9a564/attachment.html>
More information about the Kde-graphics-devel
mailing list