You've probably been aware that a rather sizable group of KDE developers and
stakeholders in our development platform is meeting in Randa, Switzerland to
discuss the future of our development frameworks, with the big topic being
"modularization of kdelibs". We've had a number of great discussions here
about various technical and process-related topics. We are still in the
process of making the results digestable, transforming our notes into
something that is understandable for those that haven't been able to
participate in these -- very productive -- sessions in person.
Let me already give you some information on the bigger picture we came up with
here, as you are all probably very curious about that. The overall theme was
the modularization of kdelibs, kde-runtime, kdepimlibs, kdepim-runtine and
kdesupport. With Qt5 -- a change in binary interface -- having been announced,
it is a good point in time to introduce some changes to our frameworks that
are only possible if we change the ABI -- which Qt5 will do for us anyway.
What is the scope?
Instead of Platform, we want to consistently use the term "Frameworks", this
includes what we currently refer to as kdelibs, kdepimlibs, kde-runtime,
kdepim-runtime and kdesupport. We explicitely are not talking about our apps
and workspaces, but read on.
What do we want to achieve, and why?
We want to make it possible to use our frameworks in Qt projects without
significant additional dependencies. This means:
* We reach out to the Qt development community in a more focused way
* We make it easier to use our frameworks
* We lower the barrier for contributions
* We make our frameworks more suitable for mobile and device-spectrum use
* We make it possible to select a specific set of features developers would
like to use
* We improve our QA processes, leading to better quality apps and frameworks
We want this to happen with ...
* ... no disruption for our users
* ... little to no source incompatibilities
* ... most apps not needing any significant changes
* ... changes, if at all necessary being kept to a minimum
What does it mean for users?
* No disruption
* Most probably invisible
* Short term: Iit becomes easier to run kDE apps outside of the Plasma
workspaces, including other operating systems
* Longer term: We will probably see more apps using KDE technology
What does it mean for developers?
* We will maintain source compabitility as much as possible
* The impact for existing apps will be minimal
* We will provide a compabitility library as additional measure to reduce the
impact of these changes
What does it mean for packagers?
* We make it possible to ship our frameworks in a more modular way
* We also plan to provide "monolithic tarballs" much as we do now, depending
on the needs and preferences of downstreams
Please note that this is *not* KDE5, as it doesn't refer to our community, but
about our development frameworks. At this point there is also no benefit in
talking about KDE 5, since that just opens the door to misinformation. This is
also clearly not about our workspaces, or applications. (See
<a href="http://vizzzion.org/blog/2011/06/there-is-no-kde5/" title="http://vizzzion.org/blog/2011/06/there-is-no-kde5/">http://vizzzion.org/blog/2011/06/there-is-no-kde5/</a> for a quick explanation.)
In order to prevent this thread from growing into an unmanageable load of
hundreds of emails, please post specific questions as separate threads. (You
can of course reply with praise to this, but anything that is likely to spark
a more detailed discussion is probably better off in a separate thread.)
Thanks for your attention, and cheers from a wonderful Switzerland,
|KDE Frameworks 5.2.0 release||0|
|Review Request 109561: Disable SSL compression support in TCPSlaveBase||2|
|Review Request 126659: [kio_ftp] fix display of file/directory modification time/date||7|
|PSA: KDE Telepathy master now must have new plugin installed||1|
|Review Request: Implement a dialog to show unhandled Bugzilla errors||6|
|KPushButton and deprecated setIcon ?||1|
|kdelibs coding style.||1|
|/: Revert "Fix plugins lookup when not building in the Qt prefix"||2|