Replacing the KIcon type with a factory method and is frameworks a good idea at all?

Albert Astals Cid aacid at kde.org
Tue Sep 6 22:04:43 BST 2011


A Dimarts, 6 de setembre de 2011, Ingo Klöcker vàreu escriure:
> Hi all,
> 
> I just want to comment on one thing:
> > [14:30:15] <DxSadEagle> steveire: you're basically saying we should
> > favor hypothetical Qt developers over actual KDE app developers.
> 
> Apart from the fact (as far as I understood the discussion) that Steve
> isn't favoring one over the other but rather trying to give the
> hypothetical Qt developer some of the benefits actual KDE app developers
> have, I want to make a confession: I am one of those hypothetical Qt
> developers. I have used one KDE class in a Qt-only project and to be
> able to do so I had to remove quite a lot of code from said KDE class
> because I really didn't want a dependency on KGlobal, KConfig,
> KStandardDirs, etc. Because of the pain using KDE classes in Qt-only
> projects causes I have only used this one class.
> 
> Another class I/we are using comes from the Qxt extension library. This
> class could be used out-of-the-box. I wish I could use some of KDE's
> great Qt extensions with similar ease. KDE frameworks appears to be the
> solution for this. So, I, as one of those not so hypothetical Qt
> developers (who happens to be a KDE developer as well, btw), am all for
> making the KDE libraries more modular and more easily usable in Qt
> projects.

"making thing more modular" is not bad per se.
The problem is that unfortunately it seems that "making thing more modular" 
will end up meaning "making things worse for KDE developers so it is easier 
for others"
I think that is what Maksim was saying, and I agree that is not a nice thing.
And even if those "others" is a KDE developer with a different hat it is still 
no excuse for me.

Albert

> 
> 
> Regards,
> Ingo




More information about the kde-core-devel mailing list