Port away from KImageIO

Review Request #129929 - Created Feb. 6, 2017 and updated

Martin Tobias Holmedahl Sandsmark

KImageIO is apparently deprecated, so use similar code to what is now used in Gwenview.

Saving as different formats works as expected here.

Michael Pyne
Ship It!
  1. 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

    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.

  2. 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.

  3. Any update on this? Martin (Koller), the answer from Martin (Sandsmark) seems to address the issue that you raised.

  4. 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.