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

[Michael Pyne]

On Tuesday, September 06, 2011 14:39:35 Stephen Kelly wrote:
> We've just had a long discussion about the future of KIcon in APIs,
> which led into a discussion about what we're doing in frameworks at
> all and why.
> 
> Several people don't think refactoring kdelibs into independent
> frameworks is a good thing. Do we need to decide if it's worth it?
> 
> I'm posting the log for archival reasons mostly. There are several
> misunderstandings in it, but those are mostly untangled later on.

I have to say that something about the idea of posting IRC transcripts of 
rather vigorous debates, because the debate was vigorous, makes me uneasy. I 
understand they're already effectively public already, but kicking things up 
to a public mailing list isn't the way to get issues resolved, because the 
issues are *not* technical, they are interpersonal.

I read the whole thing and so I'll just make these comments:

* The idea that we (KDE) cannot develop classes because someone might 
accidentally make them a parameter of a library function is ludicrous. Even if 
it does happen you can re-add the appropriate library method and mark the old 
one for integration in the next major version bump. Likewise, porting tools 
are nice and useful and all, but that cannot be our only advice to developers 
unless we want to reproduce KDE 4.0...

* While I personally agree with modularizing KDE libraries if only because it 
will make our framework more well-defined and easier to understand (and 
replace parts of if needed for different form factors), the result should 
still be "KDE" at the end! It is already a large fear among some KDE devs that 
the modularization process is just going to result in the complete Qt-
ification of kdelibs. I had thought such fears were overblown but I see chat 
logs now where devs argue for removing KDE software that has no complete 
replacement in Qt ("who really uses that feature anyways?") and now I start to 
wonder myself.

We hit our users and developers /hard/ with KDE 4 and so like dfaure said, we 
should strive to *minimize* the porting impact going to KDE 5. So where we can 
use upstream libraries to fully implement KDE features then great, let's do 
so, but the question we need to ask when doing so is NOT 'who really uses that 
feature' unless you're actually going to go to the trouble of at least using 
lxr, google, mailing lists, etc. to determine the feature really is vestigial.

* There really was an awful lot of confusion about what KIcon* class does 
what. How can you all let what's supposed to be technical debate get so 
intense when you all don't have all the details? The answers don't have to be 
determined today, at some point that conversation needs to be nipped in the 
bud because "garbage in" amongst the debaters always equals "garbage out". 
Just figure out what code needs to be examined, examine it, come back later if 
necessary. BTW, this kind of thing is what mailing lists are for (sans chat 
logs ordinarily ;), to give people that time for review.

* With all /that/ said, if all KIcon has over QIcon is the automatic usage of 
KIconLoader (and look at the source [kdelibs/kdeui/icons/kicon.cpp], that 
really is pretty much all it has) then I personally don't think it should be 
an actual class in KDE 5. Obviously that has implications for the easy porting 
of software, but this will hardly be the only instance of that so let's not 
pretend this is a massive blocker one way or the other.

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/eab2e19d/attachment.sig>