DevHeads.net

The Future of our Frameworks

Hi all,

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
cases
* 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,

Comments

Modularization and other languages' bindings (was: The Future of

By Luca Beltrame at 06/06/2011 - 14:05

In data Monday 06 June 2011 19:26:38, Sebastian Kügler ha scritto:

(I took the liberty of adding kde-bindings to the CC of tihs specific topic)

Reading around the plans and this mails, I'd like to ask if bindings for
interpreted languages (aside ECMAScript, which has a more or less official
blessing thanks to QtScript and friends), were put into the equation.

The reason is simple: those too contribute to lowering the barrier of entry
for developers, especially the audience that has not a C++ programming
background. If things are adjusted (without breaking things), it would be a
perfect opportunity to involve the bindings people in the process.

Again, this is also a perfect opportunity to get the bindings team on board,
to ensure that the changes will not maim the bindings themselves.

Notice that this is not a criticism of what's has been done so far: on the
contrary, I think the effort is sorely needed. I would just like to point out
the existence of these realities (bindings) that albeit small, contribute
their little to the use of KDE.

Re: Modularization and other languages' bindings (was: The Futur

By Arne Babenhause... at 06/10/2011 - 17:33

On Monday 06 June 2011 21:05:41 Luca Beltrame wrote:
Having i.e. PyKDE more modular would be great for me, too.

I love using it, and it would be useful to have a way to distribute it with a
simple app in a nice and lean binary (if that still exists, I’m sorry for the
noise…) - or to be able to tell a GNU/Linux distritution that I need only
KUniqeApplication and IconLoader and have it install only a small subset of
PyKDE.

Best wishes,
Arne

Re: The Future of our Frameworks

By todd rme at 06/06/2011 - 17:51

On Mon, Jun 6, 2011 at 7:26 PM, Sebastian Kügler < ... at kde dot org> wrote:

It is great to hear that you are thinking about this, and I am looking
forward to seeing more details in the future.

As for new threads, are you looking for suggestions and ideas or only
questions at this point?

-Todd

Re: The Future of our Frameworks

By Aaron J. Seigo at 06/06/2011 - 18:56

On Tuesday, June 7, 2011 00:51:12 todd rme wrote:
we're looking for feedback on the topics that are presented in these emails
(there are a few others that have already been sent, and some that will be
sent soon..)

it would be nice to keep ideas and suggestions to things that you are willing
to help make happen or which impact your use of the Frameworks directly. keep
in mind that we are trying to keep the scope of this effort manageable and
oriented towards improving the state of what exists more than adding lots of
new things.

questions are always welcome, of course :)

also note that this effort does not touch on application development efforts.
so suggestions about specific applications (e.g. Dolphin) are not in scope. in
fact there will be a (yet undetermined) number of 4.x application releases
that will continue on with the existing kdelibs and kde-runtime beneath them.
porting of applications and/or making larger changes to them in the name of it
being a "new major release" is something for a future date.

hth...