kde-runtime

Jaroslav Reznik jreznik at redhat.com
Wed Mar 12 10:27:14 UTC 2014


----- Original Message -----
> On Tue, 2014-03-11 at 09:28 -0500, Rex Dieter wrote:
> 
> > ping, I'm interested in helping work on this, but need help/feedback.
> > 
> 
> Hi Rex, sorry for not getting back to this sooner. Its on my list for
> this week to look in more detail at the pros (or cons ?) of including
> kde-libs - I hope to get to it after Wednesday.

Hi Matthias,
see my answers - sometimes inline, sometimes not - I hope it's still
readable :).

> but also a question whether
> we would end up with 'two of everything' - 2 multimedia apis (gstreamer
> vs phonon), 2 display configuration apis, etc. Sadly, I don't have very
> deep knowledge about the qt side of the world, so you could probably
> help me out there. How do things work nowadays:

To make it even more complicated and confusing ;-) - the whole situation
is going to change a lot with upcoming KDE Frameworks 5 (KF5) and Qt 5 but I
hope it will answer all of yours questions. The main idea behind Qt 5 and
KF5 is modularity (smaller footprint for mobile devices) but also with
open nature of Qt Project, a lot of stuff from former kdelibs has been
upstreamed to Qt 5. KDE libraries/runtime were split into so called 
tiers with the goal to provide these modules to other 3rd party Qt
developers without the need to bring the whole KDE as it was in time
of KDE 4.

> Size is one of the concerns that I've heard, 

With KDE Frameworks 5 the size issue could be solved by picking up
the right modules from the tier that could be useful for wider range
of users and developers.

For two of everything - usually as backends, WS libraries and frameworks
are used (GStreamer for Phonon, UDisks for Solid etc.) and these APIs
are than just more convenient APIs for Qt/KDE developers without the
need to fight GLib/DBus integration and higher level than underlying
APIs. We try to make sure we use same technology as current Desktop
spin. And even getting closer for example with recent rewrite of
network management using nm-qt directly.

> - Is qt5 more or less a complete platform ?

Qt 5 is more or less complete platform, with addition of KF5 bits
it's even more. But as I said - it's pretty much modular these days.
You can just use Qt Base and write console apps without the need to
have GUI libs available at all.

> - Are kdelibs mainly used by core kde apps, while 3rd party qt apps
> generally just use qt ?

That's the idea behind KF5 it's going to be used by 3rd party at apps
developer as I wrote above.

Also the KDE libs and applications are now being decoupled, so it
gives as some flexbility.

What I'd propose (it's my personal opinion, not KDE SIG) - let's start
with KF 5 - it should be "stable" by F21 release. There's some
possibility some apps would be already ported to Qt 5/KF5 and we will
start from clean ground. It will be useful for developers beyond old
KDE lands...

For everyone who would like to install KDE 4 desktop or KDE 4 apps,
deps would have to be obtained from repository. But even Plasma 2
desktop is shaping up but I don't think it would be ready for
general consumption by the time of F21.

Jaroslav   

> Matthias
> 
> --
> desktop mailing list
> desktop at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/desktop


More information about the desktop mailing list