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
signature.asc
Description: This is a digitally signed message part.
