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
signature.asc
Description: This is a digitally signed message part.
