Review Request 129929: Port away from KImageIO
Martin Koller
kollix at aon.at
Sun Jun 4 12:20:44 UTC 2017
On Samstag, 3. Juni 2017 21:27:00 CEST Martin Tobias Holmedahl Sandsmark wrote:
>
> > 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.
>
> 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.
Either you or I misunderstand something here.
My point is, KImageIO::typeForMime() is NOT the same as mimeType.preferredSuffix().
The former returns a keyword which QImage knows and uses to select a format to save as.
I'm not confident that QImage would select the same plugin when you pass a filename suffix.
Can you prove that ALL image formats KDE supports can be written with the respective filename suffix as format keyword ?
(And you still would have the possibility that a user has installed another imageformat plugin which does not
use the suffix as keyword)
--
Best regards/Schöne Grüße
Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?
() ascii ribbon campaign - against html e-mail
/\ - against proprietary attachments
Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
More information about the Kde-graphics-devel
mailing list