Only QImage in KContacts::Picture needs Qt::Gui.
If Pictures isn't used in consumer, we do not need to threat them to
link Qt:Gui for nothing.
(Sink has no Qt::Gui dependencies right now).
mlaurent |
KDE PIM |
Only QImage in KContacts::Picture needs Qt::Gui.
If Pictures isn't used in consumer, we do not need to threat them to
link Qt:Gui for nothing.
(Sink has no Qt::Gui dependencies right now).
Built all users of KContacts:
No Linters Available |
No Unit Test Coverage |
Picture is used in addressee.cpp or vcardtools, so if you import vcard it will use Picture too so I don't see how you want to avoid QtGui linking.
You can't avoid the linkage of QtGui inside KContacts, that is correct and I don't have plans to change this. The usage of QImage is only internaly in the library. The only external usage is KContacts::Picture::data/ KContacts::Picture::setData. Okay we have to move Qt:Gui to PRIVATE library.
The point I'm talking about is about using KContacts in external applications (f.ex. R9:f198198b9b08b331873185f66cd370e63ee46564 for Sink)
I'm doing only things that do not using picture at all:
Sink::ApplicationDomain::Contact contact; KContacts::VCardConverter converter; const auto addressee = converter.parseVCard(contact.getVcard()); contact.setUid(addressee.uid()); contact.setFn(addressee.formattedName());
until I don't really use addresse.picture.data() or addresse.picture.setData() - I don't need a full class defintion of QImage and the forward declaration of QImage is enough for the compiler/linker. I could also create and modify Picture objects without linking QtGui into Sink:
KContacts::Picture picture; picture.setData("IMAGEBYTESTRING", "png"); [...]