steveire at gmail.com
Sat Oct 30 21:43:50 BST 2010
Alexander Neundorf wrote:
> I think BC is less important that SC.
> If a KDE5 would just require a recompile, and maybe some changes in the
> cmake scripts (like additional find_package(SomeKLibrary)), this shouldn't
> be a too big problem for KDE.
> If it would mean people have to rewrite their apps, as they just did for
> KDE4, it might be deadly for KDE I'm afraid.
I think the big difference is that KDE4 introduced many new and different
technologies that needed to be ported to (akonadi, plasma for example),
whereas reorganizing kdelibs involves shuffling things around and renaming
libraries. So you'de use, for example, KPlatform::Locale instead of KLocale
(which uses KConfig, KStandardDirs etc), whereas Gregory would use
KLibs::Locale (which uses possibly self implemented or contributed
interfaces which use QSettings, etc).
Until we try some things out we won't know what the impact on kde apps would
> Maybe first move everything into kdelibs (kdeuspport, kdepimlibs), and
> then cut it into parts?
Yes, that's exactly what I wrote on the wiki page.
>> It seems many packaging and distribution problems either fall away,
>> because the author controls both, not a distro and not the user, or fall
>> away because they exist and must be solved anyway if
>> Gregory-the-Qt-developer or ACME Qt-using software vendor is creating
> But if the developer is the one who "must solve it anyway", this may be
> just the reason to avoid doing it and staying with Qt-only (since it will
> avoid spending a lot of time of building dependencies on Windows which are
> not fully and officially supported on Windows).
I'm starting to not understand what you mean. Or else you didn't understand
what I meant.
If a software vendor creates an application to run on particular hardware,
they must build it, and package it on the hardware together with any
dependencies. Then they give the hardware with the software on to whoever
pays them to do it. Making that building and packaging happen is the part
that must happen anyway. The software vendor does not rely on the user or
distro to make the dependencies available and configured properly. They do
If that software requires a set of classes for asynchronous job execution,
itemviews, handling of Mime documents or IMAP communication, and all those
things exist in kde libraries (where they are tied to each other, other
unrelated libraries, and the platform), then it should be possible to use
those kde libraries without a lot of hassle, because they are mostly Qt-only
libraries without any wierd non-windows deps.
I'm talking about a reorganized kdelibs (Tiered) where every library does
not depend on every dependency of every other library. In that context I
don't understand your response. Which non-windows dependencies are you
> It is possible, but it needs work.
> A lot of things are done as they are done in KDE so that individual KDE
> developers don't have to care too much about the build system, and to
> avoid duplication. The most obvious thing are the installed cmake
> find-modules from kdelibs.
You're the expert on this, not me. I know very little about the kde build
system. However, I imagined that the kind of platform level build system
integration you mention here (so that kde application developers don't have
to care too much) could be implemented 'above' the libraries, not below
All the best,
More information about the kde-core-devel