Proposal to use QIcon in APIs in KF5.

[Michael Pyne]

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:

1) Porting KClasses to functionally non-equivalent QClasses and dropping 
features in the process. This is bad for obvious reasons, except for the rare 
cases where a feature is simply completely unused/unneeded.

2) Porting KClasses to functionally equivalent QClasses, but losing the 
ability to modify those KClasses as needed for the Desktop. This has actually 
happened with Phonon, except that we just kept developing it anyways and 
recommended to users to compile Qt without Phonon.

The thing with 2) is that at some point *we* have to be responsible for the 
parts of code the makeup "KDE" software. Obviously we can't do it all (and 
that's not the point) but we just need to make sure stuff we're kicking 
upstream is stuff that we won't need to fix/alter quickly if needed.

Regards,
 - Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110906/c60dbf02/attachment.sig>