In data lunedì 01 settembre 2014 18:58:30, Anton Aylward ha scritto:
whatever that is. Are you saying that, like with Qt4/5, KDE4/5 has "breakage"? Does that mean that apps we have now won't work with KF5? Which gets back to the point I was trying to make.
Let's tell everything from the beginning, like in the second Airplane movie. Qt moved from version 4 to version 5, back in the days, and therefore (as per their policy on major versions) they broke binary compatibility. At the same time the development process was made more open, and Qt moved to open governance. KDE thought it would be a good idea to step in to do things like: - Move very useful stuff that was inside kdelibs to Qt - Get rid of some deprecated stuff / bad decision made in the past - Generate finer-grained dependency so people would stop thinking "you need all of kdelibs for just 1 tiny class" - Improve the existing libraries Given that Qt 5 was breaking (in the sense of: you can't run a Qt 4 app against Qt 5 at runtime), they thought, and again this is OK with the project policies, to break compatibility (although only if necessary) Other KDE developers also wanted to move to Qt 5 (the Plasma developers) because it offered Qt Quick 2, which was a much better iteration of the Qt Quick 1 used in later Plasma widgets of the 4.x era. As usual, these 2 weren't compatible ;) and to make use of the new features most stuff would have to get rewritten. At the same time the basic library used by Plasma was also overhauled to remove cruft and make it into a KDE Framework. BTW: porting from Qt4 / kdelibx 4.x to Qt5 / KF5 is much easier than for KDE3 -> 4.x (which is why it took long for applications to move, back then). So what you're seeing is akin to renovation of an existing house: the foundations stay there, but a lot has changed inside.
even going to be trying. And the subset of the apps I use are not going to be the same as the next guy or the next. How are you going to prioritise this?
Depending on who gets the work done. ;)
important part. Perhaps it was mismanaged, then, and perhaps that
It was also a mismanagement on part of the distros, and openSUSE is to blame as well. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79