Absolument pas… La base de données Sqlite reste inchangée au niveau du schema… Seule le schéma d'une base de données Mysql est mis à jour pour les corrections de bogues.
Dans Krita on peut voir que 3 ou 4 frameworks de KDE ont été carrément dupliqués et changés. C'est certainement une solution de facilité pour réduire temporairement les dépendances à KDE, surtout que ces frameworks sont les éléments centraux pour une application basée sur KF5.
Pour Kdenlive, dixit une discussion orale avec les développeurs de l'application, il semblerai que ce soit le chemin inverse qui soit pris, mais je n'ai pas regardé dans le code source. Il y a un lien quelque part (blog, mailing list) où l'on notifie ce type de réduction de dépendances à KDE ?
Exact. Mais lorsque l'on a une application KDE à maintenir cela fait plus du double de travail : deux API à supporter. On ne parle pas de tests de regressions à faire. Bref c'est une horreur.
Pour info, le code source de digiKam en ligne de code c'est çà :
On peut facilement imaginer la montagne de travail que ça représente à maintenir ce code. Donc avoir une application pure Qt5 cela semble logique sur le long terme.
Ceci dit, tout le système infâme de run-time KDE est retiré. La liste des dépendances KDE qui apparait en listant avec ldd l'exécutable de l'application sont les inter-dépendances. Typiquement, une lib KDE utilisée va appeler une multitude de libs KDE. C'est titanesque, voir viral. Et ce n'est pas vraiment comme cela que l'on défini un framework C++ propre. Et c'est pour cela qu'il y a très peu d'application KDE sous Windows, car c'est compliqué et lourd à gérer, à maintenir, à installer…
Mais le plus important dans cette version c'est toutes les dépendances KIO et DBUS qui ont disparu. Pour Windows et OSX, les 2 n'ont jamais vraiment bien marché. Ils posaient de sérieux problèmes de stabilité à l'exécution.
Pour Windows et OSX, tout est déployé en Bundle. Tout l'installateur Windows est cross-compilé sous entièrement sous Linux. Pas de Windows pour développer, pas de compilateur M$ complètement bancale, pas de DLL manquantes au run-time, pas de risque de virus lors des builds. Bref un pingouin qui fait du Windows de A à Z c'est beau. De plus c'est entièrement automatisé car c'est des scripts BASH en arrière plan…
# La version 5.1.0 est de sortie....
Posté par dynamo . En réponse à la dépêche digiKam change de rythme. Évalué à 1.
Dixit l'annonce de digiKam 5.1.0 avec plus de 343 entrées dans bugzilla qui ont été traité. Un autre sacré triage de rapports…
[^] # Re: digikam.db
Posté par dynamo . En réponse à la dépêche digiKam change de rythme. Évalué à 4.
Absolument pas… La base de données Sqlite reste inchangée au niveau du schema… Seule le schéma d'une base de données Mysql est mis à jour pour les corrections de bogues.
[^] # Re: Félicitations à l'équipe !
Posté par dynamo . En réponse à la dépêche digiKam change de rythme. Évalué à 1.
Dans Krita on peut voir que 3 ou 4 frameworks de KDE ont été carrément dupliqués et changés. C'est certainement une solution de facilité pour réduire temporairement les dépendances à KDE, surtout que ces frameworks sont les éléments centraux pour une application basée sur KF5.
Pour Kdenlive, dixit une discussion orale avec les développeurs de l'application, il semblerai que ce soit le chemin inverse qui soit pris, mais je n'ai pas regardé dans le code source. Il y a un lien quelque part (blog, mailing list) où l'on notifie ce type de réduction de dépendances à KDE ?
[^] # Re: Changement de nom
Posté par dynamo . En réponse à la dépêche digiKam change de rythme. Évalué à 7.
Exact. Mais lorsque l'on a une application KDE à maintenir cela fait plus du double de travail : deux API à supporter. On ne parle pas de tests de regressions à faire. Bref c'est une horreur.
Pour info, le code source de digiKam en ligne de code c'est çà :
C++: 658800 (92.81%)
C ANSI: 43874 (6.18%)
BASH: 2572 (0.36%)
perl: 2386 (0.34%)
yacc: 958 (0.13%)
python: 495 (0.07%)
ruby: 233 (0.03%)
On peut facilement imaginer la montagne de travail que ça représente à maintenir ce code. Donc avoir une application pure Qt5 cela semble logique sur le long terme.
[^] # Re: Dépendances à KDE
Posté par dynamo . En réponse à la dépêche digiKam change de rythme. Évalué à 10.
digiKam n'est pas encore une application pure Qt5. Il reste environ 15-20% de dépendances à retirer (les plus dures en fait).
https://quickgit.kde.org/?p=digikam-software-compilation.git&a=blob&f=DEPENDENCIES
Ceci dit, tout le système infâme de run-time KDE est retiré. La liste des dépendances KDE qui apparait en listant avec ldd l'exécutable de l'application sont les inter-dépendances. Typiquement, une lib KDE utilisée va appeler une multitude de libs KDE. C'est titanesque, voir viral. Et ce n'est pas vraiment comme cela que l'on défini un framework C++ propre. Et c'est pour cela qu'il y a très peu d'application KDE sous Windows, car c'est compliqué et lourd à gérer, à maintenir, à installer…
Mais le plus important dans cette version c'est toutes les dépendances KIO et DBUS qui ont disparu. Pour Windows et OSX, les 2 n'ont jamais vraiment bien marché. Ils posaient de sérieux problèmes de stabilité à l'exécution.
Pour Windows et OSX, tout est déployé en Bundle. Tout l'installateur Windows est cross-compilé sous entièrement sous Linux. Pas de Windows pour développer, pas de compilateur M$ complètement bancale, pas de DLL manquantes au run-time, pas de risque de virus lors des builds. Bref un pingouin qui fait du Windows de A à Z c'est beau. De plus c'est entièrement automatisé car c'est des scripts BASH en arrière plan…