Proposal to use QIcon in APIs in KF5.

[John Layt]

On Tuesday 06 Sep 2011 23:14:03 Albert Astals Cid wrote:
> A Dimarts, 6 de setembre de 2011, Stephen Kelly vàreu escriure:
> > I want to know what people expect in terms of source
> > compatibility and what people are willing to accept. At the moment I
> > don't know those things.
> 
> To be honest, application developers were promised almost total source
> compatibilty by the frameworks effort, since the only thing that was going
> to be modified was the modularization/tiering, and thus KDE application
> developers that would still depend on the whole thing would not need to do
> any change at all.
> 
> Albert

Yes, we promised mostly source compatible, and a compatability library for 
those bits of api that are removed.  If parts of the api need cleaning and the 
end result is simpler, more consistent, more usable api's for our developers 
then we shouldn't be afraid to do that.  KIcon and KUrl are two good examples 
of this, if only to remove the confusion over which to use.

Porting a dozen or so lines from KIcon(foo) to KIconFactory::icon(foo) is 
nowhere near the effort required for say a change to model/view list widgets 
and a burden I hope our devs will understand is for their benefit.  If they 
don't, then they can keep using the KDE4Support version of KIcon.

The only reason I've been able to contemplate the Locale and Date/Time change 
to Qt is the KDE4Support library which will give the needed time to port the 
apps.  And yes, I'll be helping people port to the new api, I have no 
intention of just dumping and running, I want all of SC ported before any 
release even if I have to do it myself.  Even if we end up keeping KLocale and 
KCalendarSystem I will still have deprecated api I want to get rid of that we 
would need to port away from.

I can understand the emotional attachment to KClasses, but when there's an 
equivalent QClass that does everything we need then it makes no sense to cling 
to it.  After all, we have chosen to base ourselves on Qt, and we have to draw 
a line somewhere between Qt and KDE, it just seems inevitable to me that as 
more core QClasses come up to the required standard that we switch to them and 
use our valuable time working on more useful things.

John.