Porting to KF5 - kimageio question
kollix at aon.at
Mon May 18 07:00:07 BST 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.
So what to do about the deprecation ?
Why was it done in the first place with no alternative ?
Best regards/Schöne Grüße
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-core-devel