Porting to KF5 - kimageio question
Martin Koller
kollix at aon.at
Sat Aug 1 10:34:11 BST 2015
On Friday 31 July 2015 15:29:45 Albert Astals Cid wrote:
> El Dilluns, 18 de maig de 2015, a les 13:38:36, Albert Astals Cid va escriure:
> > El Dilluns, 18 de maig de 2015, a les 08:00:07, Martin Koller va escriure:
> > > 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 ?
> >
> > People make mistakes? Have you tried emailing directly the person that did
> > the deprecation?
>
> Ping? What happened with this?
>From my side, nothing happened yet
--
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-core-devel
mailing list