Replacing the KIcon type with a factory method and is frameworks a good idea at all?

[Kevin Ottens]

Hello,

On Tuesday 06 September 2011 10:41:22 Michael Pyne wrote:
> * With all /that/ said, if all KIcon has over QIcon is the automatic usage
> of KIconLoader (and look at the source [kdelibs/kdeui/icons/kicon.cpp],
> that really is pretty much all it has) then I personally don't think it
> should be an actual class in KDE 5. Obviously that has implications for the
> easy porting of software, but this will hardly be the only instance of that
> so let's not pretend this is a massive blocker one way or the other.

Well, it's a natural candidate for a kde3support-like library. There would be 
no disruption for application developers apart from linking on said library. 
And in time they can port to the newer API which would be further down the 
stack (likely in libkui, the exact dependency chain for the other KIcon* 
classes would need to be examinated I guess).

I find that case easy enough really. Even if we ignore the whole 
modularization and such, looking at the situation purely from a "let's improve 
our API" position it's clear to me that the KIcon type has no benefit over a 
factory method returning a QIcon instance which is enough to put a deprecated 
label over it.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110906/b1100731/attachment.sig>