Proposal to use QIcon in APIs in KF5.

[Alexander Neundorf]

On Wednesday, September 07, 2011 02:11:11 AM Michael Pyne wrote:
> On Wednesday, September 07, 2011 00:56:58 John Layt wrote:
> > 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.
> 
> Well it would have to be so anyways, right? The plan AFAIK was that
> Framework would be essentially finalized even before we started porting
> the rest of the apps so Framework+compat-shims cannot be allowed to become
> too divergent anyways.
> 
> > 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.
> 
> I really think the underlying concern is less about that per se but is
> instead two-pronged:
...
> 2) Porting KClasses to functionally equivalent QClasses, but losing the
> ability to modify those KClasses as needed for the Desktop.

This can still be done once our stuff has gone into the QClasses. It is "just" 
that we then depend on the next release of the library which contains that 
QClass.
This is a change in the workflow, but it doesn't make it impossible.
(same as I'm doing with cmake).

Alex