Proposal to use QIcon in APIs in KF5.

[Stephen Kelly]

Hi,

I re-read the IRC log from the last email and noticed the recommendation of 
and API review instead of meta-discussion, which I missed at the time. 

That is probably a good recommendation. Posting the log was probably a bad 
call on my part, and we can hopefully have a more useful discussion if we 
leave the other thread and discuss an API instead.

So here's my concrete technical proposal for icons in KDE Frameworks 5. Let 
me know what you think:

I would like to replace the use of KIcon in apis like this:

void someMethod(const KIcon &icon);
KIcon getIcon() const;

with this:

void someMethod(const QIcon &icon);
QIcon getIcon() const;

Because KIcon does not have any data members, and all functionality comes 
from other classes (KIconEngine and KIconLoader), no functionality is lost 
by using Qt classes in the API.

Because KIcon will remain somewhere in its current form porting should be a 
no-op or trivial, even optional.

People using such an API would create KIcons as is normally done now.

KIcon fooIcon("foo");
someClass->someMethod(fooIcon); // up cast to QIcon

KIcon barIcon = someClass->getIcon(); // Use KIcon(const QIcon &)

I do not (anymore) recommend any other changes at this time, such as 
removing, changing or deprecating KIcon, because it seems to be 
(surprisingly to me I must admit) a contentious issue.

Please don't be silent if you think this is a bad idea. I was surprised at 
the opposition to changes in the name of modular frameworks earlier. I want 
to know there is opposition to it if there is. I don't want to find out in 3 
months time. 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.

Thanks,

Steve.