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? Cheers, Albert
