Déjà pour info, la migration de QGraphicsView vers QML a commencé il y a quelques versions déjà, et pour la 4.11, à priori, tous les éléments de bases seront converti (ils le sont déjà prèsque tous pour la 4.10, et quelques majeurs en 4.9)
Donc tu vois, il n'y a pas eu tant de régressions que cela ;)
Ensuite, c'est le passage de QGraphicsView à QML qui est sans changement visible pour l'utilisateur, et dans cette phrase, il y a (au moins) trois mots importants :
"Passage" : des changements visibles pourront arriver après, mais pour le passage, ce qui est important c'est d'éviter les régressions, donc on essais de refaire la même chose qui marche pareil, pas de fonctionnalités en plus.
"Visible" : une consomation moindre de mémoire et de meilleurs performances sont des changements, mêem s'ils ne sont pas à priori visibles.
"Utilisateur" : le développeur lui, il les voit bien les changement, grosse réduction de sa base de code à maintenir, grosse mise en commun de code gérant l'interface et ses effets graphiques, donc les bogues sont corrigés pour tout le monde, les fonctionnalités développées pour un élément sont accessibles à tout le monde. Et il peut plus se concentrer sur ce qui est important : ce que fait l'application/l'outil/l'élément de bureau qu'il développe.
# Un bureau qui ne change pas, ça change !
Posté par moi1392 . En réponse au journal KDE from scratch. Évalué à 10.
Déjà pour info, la migration de QGraphicsView vers QML a commencé il y a quelques versions déjà, et pour la 4.11, à priori, tous les éléments de bases seront converti (ils le sont déjà prèsque tous pour la 4.10, et quelques majeurs en 4.9)
Donc tu vois, il n'y a pas eu tant de régressions que cela ;)
Ensuite, c'est le passage de QGraphicsView à QML qui est sans changement visible pour l'utilisateur, et dans cette phrase, il y a (au moins) trois mots importants :
"Passage" : des changements visibles pourront arriver après, mais pour le passage, ce qui est important c'est d'éviter les régressions, donc on essais de refaire la même chose qui marche pareil, pas de fonctionnalités en plus.
"Visible" : une consomation moindre de mémoire et de meilleurs performances sont des changements, mêem s'ils ne sont pas à priori visibles.
"Utilisateur" : le développeur lui, il les voit bien les changement, grosse réduction de sa base de code à maintenir, grosse mise en commun de code gérant l'interface et ses effets graphiques, donc les bogues sont corrigés pour tout le monde, les fonctionnalités développées pour un élément sont accessibles à tout le monde. Et il peut plus se concentrer sur ce qui est important : ce que fait l'application/l'outil/l'élément de bureau qu'il développe.
Moi je trouve que c'est plutôt cool au final :)