On Wednesday, February 9, 2011, Stephen Kelly wrote: > http://techbase.kde.org/Projects/KDELibsModifications
good to see people thinking about these things. however:
this page belongs on commuity.kde.org. it's already linked from here:
http://community.kde.org/KDE_Core
and it should be moved over.
one thing that jumps out at me is the use of terms like "library" when really
it means "classes". there's an implicit assumption on that page that libraries
like kdecore will be split up into N different libraries. while i think
there's an easier case to be made for some of other libraries such as kdeui
(which is a huge collection of rather different kinds of things) and kio
(which quite evidently mixes framework and platform concepts into one
library), it's less obvious that this applies to kdecore.
yes, there are different kinds of things in kdecore, but there are both
interdependencies and the open question of how many of those basic items does
a typical application end up using. there's little point in splitting it up if
a significant % of apps will use a significant % of features together from
that library: they'll just end up linking to all the smaller libraries
individually and we'll end up with a more complex system to maintain.
imho what kdecore can benefit from is streamlining the KDE-only details in it,
such as the global ref/deref and other such things. this should help make it
smaller and get the lines between it and QtCore a bit more clear and clean.
the ultimate goal of splitting out KJob, though? personally, i'm less
convinced.
--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
KDE core developer sponsored by Qt Development Frameworks
signature.asc
Description: This is a digitally signed message part.
