In data lunedì 01 settembre 2014 14:02:40, Anton Aylward ha scritto:
Is this illustrated (as in time-chart) somewhere rather than words-words-words?
As we had 2 releases of KF5 and 1 Plasma 5 release, and no KF5 applications yet, not sure I can do more than that.
Diagram of dependencies for those of us for whom all this is not "obvious", please.
Dependency diagrams, as shumski point out, make sense only for packagers or developers. But in short: /Applications KF5 (libs) \Plasma 5
#include lines, etc to new ones, Frameworks involve creativity. thought. That's cool. Applications are boooooring.
I don't see the point of sarcasm. The idea is to increase use of KDE software in the larger Qt ecosystem. I hardly think a modularization is a bad idea. Also this means that applications can have more fine-grained dependencies.
BTDT. Quit a job rather than spend ho-hum days checking all the old apps worked with the new release.
KF5 is done to minimize API and ABI (binary compatibility) breakage, but it is *not guaranteed*. Just like Qt 5 is not compatible with Qt 4. So, at least by the way you wrote this, it is not possible by design.
Are they fully compatible? Has anyone - ho-hum - checked? If so, why do they need to be ported?
They need to be ported because API and ABI changed, stuff has been deprecated, etc. Also, Qt includes new things contributed by KDE, which means that some old kdelibs specific bits need to be removed. Again: Qt5 is binary incompatible with Qt4.
Sounds like its going to be confusing for a lot of people, most notably the poor end users like me.
Actually the bulk of the work stays on the shoulder of the developers (coordinating this is not trivial) and packagers (track deps, repos, etc). At least in openSUSE we'll do our best to ensure the change is transparent to the end users. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79