Proposal to use QIcon in APIs in KF5.

[todd rme]

On Thu, Sep 8, 2011 at 9:17 AM, Jaime <jtamate at gmail.com> wrote:
> Hi,
>
>  Lets center in the technical aspects...
>
>  We should assume that Qt5 will have some kind of global icon cache,
> valid for every Qt application run in one machine, like KIcon has now.
> Am I Right?
>
>  Then, without removing KIcon, it could be a thin layer (~1Kb) over
> QIcon. Why do not call QIcon::fromTheme() in KIcon constructors, and
> then nothing changes in the KDE land.
>
>> in fact, for qt5 we defined "source compatible" to mean "porting can be fully automated".
>
>  By the way, if "source compatible" means "porting can be fully
> automated" (I guess like in Python 2 to 3), you (Qt and KDE
> frameworks) MUST provide such a porting tool.
>
> Best Regards.
>

So it seems to me there are two sides to this:

1. We want to be as attractive as possible to as developers.
Currently the monlithic nature and duplicates of some Qt functionality
serve as barriers to use of KDE libraries.
2. We do not want to hurt or drive away existing developers.  Major,
required changes to the API will hurt and possible drive away existing
developers.

People saying that the QIcon/KIcon duplicate is detrimental seem to me
to be making a compelling argument.  However, I would say the same of
people presenting real numbers regarding how massive the task of
porting KIcon to QIcon would be.

Several people have proposed moving to a separate module classes that
are needed for existing applications but pose a problem for new
developers, are no longer needed, or clutter the API.  From what they
are saying, this seems to ease the porting efforts since KIcon will
not have to be changed to QIcon for any existing software, while
freeing the rest of the frameworks from dependence on this class and
making to clear to developers the QIcon should be used for any new
software.  This, from my reading, does NOT involve deprecating any of
the classes placed in the module, they will continue to be supported.

Does this proposal satisfy everyone's needs sufficiently?  Will this
pose a major barrier to porting?  Will this pose any problems or
barriers to the overall move to frameworks?

-Todd