Lu dans un article qui parle du passage de KDE à Qt5 http://syvolc.briolet.fr/2013/01/30/kde-un-chantier-pour-le-passage-a-qt5/
"Tous les éléments du bureau KDE doivent être en grande partie réécrits pour passer de la technologie QGraphicsView au QML."
"Les plasmoids sont réécrits un par un sans grands changement visibles pour l’utilisateur"
Sans déc, c'est vraiment obligé ? A prévoir des régressions, des pertes de fonctionnalités probables… pour un gain non visible pour l'utilisateur.
# Un bureau qui ne change pas, ça change !
Posté par moi1392 . É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 :)
[^] # Re: Un bureau qui ne change pas, ça change !
Posté par Olivier Serve (site web personnel) . Évalué à 5.
Sachant qu'en plus, tout n'est pas réécrit, seulement la couche d'interface.
Les DataEngines et Services qui contiennent la logique des composants (et sont partagés entre eux) ne changent pas.
[^] # Re: Un bureau qui ne change pas, ça change !
Posté par groumly . Évalué à 1.
"Seulement", c'est vite, la composante UI d'un desktop, ca fait un morceau monstrueux quand meme…
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Un bureau qui ne change pas, ça change !
Posté par mickabouille . Évalué à 2.
Si je me souviens bien, QML c'est backend openGL obligé, donc pas forcément invisible pour l'utilisateur. Ou alors je mélange.
[^] # Re: Un bureau qui ne change pas, ça change !
Posté par Olivier Serve (site web personnel) . Évalué à 3.
Ta mémoire te joue des tours :-)
La nature déclarative de QML le rend facile à accélérer par un backend OpenGL contrairement aux QWidgets (qui incluent l'algo de rendu dans leur code). Mais QML peut parfairement fonctionner sans OpenGL. Depuis l'apparition de QtQuick (Qt4.7) c'est le moteur de rendu raster qui est utilisé par défaut.
Il était (je n'ai pas vérifié) par contre prévu de passer sur le backend OpenGL par défaut dans Qt5. Mais KDE n'en est pas encore là.
[^] # Re: Un bureau qui ne change pas, ça change !
Posté par mickabouille . Évalué à 2.
Ah, j'en étais resté à http://qt-project.org/forums/viewthread/22892
# Proverbe d'informaticien
Posté par liberforce (site web personnel) . Évalué à 10.
[^] # Re: Proverbe d'informaticien
Posté par cosmocat . Évalué à 10.
Parce que je sais pas si tu fais du dev et de la correction de bug, mais y'a rien de plus déprimant…
[^] # Re: Proverbe d'informaticien
Posté par vlamy (site web personnel) . Évalué à 10.
Proverbe indien :
[^] # Re: Proverbe d'informaticien
Posté par Badeu . Évalué à 10.
La boucle est bouclée \o/
# Apprendre de ses erreurs
Posté par Benjamin Verhaeghe (site web personnel) . Évalué à 5.
Le passage de KDE 3 à KDE 4 a entraîné de nombreuses controverses et une perte de notoriété au sein de KDE. Ils ne souhaitent pas refaire cette erreur, et c'est pour cela que maintenant ils optent pour des changements plus doux pour l'utilisateur.
De plus on a pu voir l'effet de changement trop brusque de l'environnement sur l'utilisateur avec la dernière évolution de Gnome… qui a entraînée la aussi du mécontentement et quelques forks…
Cependant l'équipe KDE reste très ouverte pour toute demande d'ajout de fonctionnalité de la part de ses utilisateur (cf forums KDE).
[^] # Re: Apprendre de ses erreurs
Posté par Strash . Évalué à 7.
C'est aussi du à la nature du changement dans Qt. Le passage de Qt3 à Qt4 était beaucoup plus violent que ne l'est celui de Qt4 à Qt5.
[^] # Re: Apprendre de ses erreurs
Posté par reno . Évalué à 2.
Pas uniquement: les nepomukeries pas mures activées par défaut bien que ça soit buggé et consommateur de CPU, ça n'a rien à voir avec Qt..
Coté gestion de projet franchement KDE ils ont des progrès à faire..
# Obligé?
Posté par ʭ ☯ . Évalué à 7.
On n'est jamais obligé, et le projet Trinity aurait pris une grande place si KDE4 avait été mal conçu. Mais en fait, il est très bien conçu, ce qui fait qu'il peut évoluer facilement quand des sous-couches technologiques évoluent (QML) et qu'il peut s'adapter aussi à des usages très variés (tablette/pc).
J'ai essayé Gnome sur un eeePC 900, pensant que son côté simplifié irait bien avec un écran 1024x600… ben je suis resté coincé sur la fenêtre options de firefox qui n'est pas déplaçable avec le gestionnaire de fenêtres par défaut. J'ai dû utiliser le truc du Alt + clic pour faire apparaître le bouton OK! Un ascenseur automatique est indispensable pour les petits écrans…
J'ai été surpris l'autre jour par un utilisateur qui en farfouillant est tombé sur le bureau de type "Rechercher et lancer" : il m'a dit :"Mais c'est super ce truc, pourquoi ils le mettent pas par défaut?" alors que je ne le montre jamais car il me semble trop différent du bureau PC classique…
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Obligé?
Posté par devnewton 🍺 (site web personnel) . Évalué à -3.
Est-ce que ces évolutions sont justifiées? Entre QCanvas, QGraphicView et QML, je ne saurais dire quel est/était le meilleur…
Au final si je dois faire un rendu, je prendrais plutôt opengl qui bien que plus primitif a l'avantage de rester rétrocompatible sur plusieurs décennies.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Obligé?
Posté par moi1392 . Évalué à 10.
Tu ne parles pas de la même chose, OpenGL sert à faire le rendu, d'ailleurs QML à un backend OpenGL (il me semble même qu'il est activé par défaut dans QML 2 si les pilotes sont OK)
QCanvas est un outil très primitif, un canvas amélioré qui permet de dessiner dedans des pixels.
QGraphicsView permet de faire du dessin vectoriel et de QWidgets et OpenGL et de XEmbed et de petits poneys qui chantent dans une scène de rendu, le tout en gérant le layout, la profondeur des objets, la cohérence globale et le taux d'humidité de l'air ambiant.
Ça en fait quelque chose de lourd, dur à maintenir et à déboguer, compliqué à utilisé.
QML ne fait que du rendu d'objets QML, décrits dans un langague descriptif et avec des interaction décrites en javascript.
Tu n'as, à aucun moment, la possibilité d'agir directement sur le scenegraph, donc QML peut en faire, ce qu'il veut, et en particulier utiliser un moteur de rendu de scènegraph écrit en OpenGL qui est très performant et consomme peu de ressources mémoire et cpu. En plus, ça rends les choses beaucoup plus simple à écrire pour les mainteneurs et les développeurs d'applications QML.
OpenGL, bah c'est OpenGL, une couche d'abstraction la plus fine possible (à vent…) par dessus la carte graphique, ça permet de faire du rendu, et seulement du rendu, de la manière la plus optimale possible si tu as les bonnes data structures et que tu les fournis de la bonne façon.
[^] # Re: Obligé?
Posté par Olivier Serve (site web personnel) . Évalué à 6.
Il y a une logique derrière cette évolution. Évolution des possibilités techniques et des besoins.
QCanvas, c'était Qt3.
QGraphicsView est arrivé avec Qt4.2 comme une amélioration de QCanvas (et avec une API similaire). QGV profitait des évolutions du moteur d'affichage ainsi que d'optimisations sur la conso mémoire et la vitesse d'affichage.
QML est un changement d'orientation.
Il faut voir en parallèle l'évolution de la construction d'interfaces :
- en dur dans le code au début ;
- puis avec des fichiers de description "statiques" (.ui, XML mon amour) ;
- enfin, gestion des états/transitions des interfaces.
Comme ça, direct en OpenGL, sans rien au-dessus ? Avec chaque appli qui recode son truc dans son coin ? Et si OpenGL n'est pas disponible ?
[^] # Re: Obligé?
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Peut être, mais c'est la troisième fois que Qt refonds son API graphique en 10 ans. Ça peut paraître long, mais pour de grosses applications qui durent, ça prends un temps et un budget de développement qu'il est très difficile de justifier.
On a eu le débat ici lors de la sortie de Tk qui a beaucoup vieilli, mais qui reste compatible et maintenu au travers des âges.
Durer est aussi important qu'évoluer.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Obligé?
Posté par Olivier Serve (site web personnel) . Évalué à 6.
Il faut relativiser un peu quand même.
Qt4 était voulu comme une révolution nécessaire afin de pouvoir mieux évoluer en douceur par la suite. Donc ça a beaucoup cassé, certes. Cependant, la doc de migration était là et des classes de transition qt3support disponibles.
De plus, l'API de QGraphicsView était calquée sur celle de QCanvas pour faciliter la migration. Enfin, celle des QWidgets (quand même plus utilisée que QCanvas) a assez peu bougé.
Les API QWidget et QGraphicsView sont toujours présentes dans Qt5. Il n'est donc pas nécessaire de tout réécrire en QML.
QML/QtQuick2 vient en plus et non en remplacement (même si la migration est encouragée).
La vraie refonte dans la pile graphique de Qt5 vient de QPA mais c'est un changement invisible.
Et que plus personne n'a envie d'utiliser pour de nouveaux développements, donc condamné.
[^] # Re: Obligé?
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
On peut généraliser aux toolkits natifs: la majorité des nouveaux développements utilisent html/css/js comme gui.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Obligé?
Posté par Gui13 (site web personnel) . Évalué à 6.
Oui et non, quand tu compares le rendu de Tk et de Qt, on est quand même à des années lumières.
Tk reste maintenu dans l'état où il était il y a 10 ans; c'est bien, mais bon à un moment faut sortir de sa torpeur.
[^] # Re: Obligé?
Posté par zebra3 . Évalué à 1.
Alors tu as un problème de Firefox, donc c'est la faute de GNOME ?
Et tu crois qu'avec KDE ça se serait mieux passé ? Genre la fenêtre aurait d'elle-même décidé de mieux s'adapter à l'écran ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Obligé?
Posté par ʭ ☯ . Évalué à 7.
Oui : j'ai essayé. Le problème avec Gnome est qu'il ne propose plus de déplacer les fenêtres filles en cliquant sur leur barre supérieure… enfin c'est l'impression que ça m'a fait. Mon truc n'est pas de troller sur Gnome/KDE même si on est Vendredi, mais d'expliquer que la souplesse c'est aussi de prévoir les cas extrêmes.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Obligé?
Posté par Atem18 (site web personnel) . Évalué à 3.
Pareil. Tout ceux à qui j'ai montré le "Rechercher et lancer" ont adoré ce concept. D'ailleurs, un projet existe pour le faire en "menu démarrer" il me semble.
# bah
Posté par Guillaume Denry (site web personnel) . Évalué à 10. Dernière modification le 01 février 2013 à 15:16.
En informatique, si tu n'avances pas, tu recules. Ok, j'exagère un peu (quoique) mais je trouve ça très bien que l'équipe KDE adapte peu à peu leur code aux fonctionnalités les plus modernes du framework sur lequel il s'appuie, ça permettra une plus grande souplesse plus tard.
Et puis si y'a quelques bugs, c'est pas dramatique, en tout cas, moins dramatique que si tu payais cet environnement de bureau et que tu exigeais un niveau élevé de stabilité.
Et puis un logiciel libre, c'est aussi l'occasion pour les développeurs de se faire un peu plaisir, on est pas uniquement dans un rapport de fournisseur à client.
[^] # Re: bah
Posté par ZeroHeure (site web personnel) . Évalué à 3.
+++++
J'approuve de toutes mes 42 mains! N'oublions pas le plaisir, malgré les utilisateurs grincheux!
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
# évoluer ou perdurer
Posté par hervé Couvelard . Évalué à 6.
Je ne sais pas si c'est une bonne chose ou pas et je ne veux pas prendre parti pour l'un ou l'autre. Maintenant il est vrai qu'il y a des applications métiers qui ne bougent pas parce qu'on ne touche pas un truc qui marche.
Je (mais ce n'est que mon opinion) trouve un peu dommage de devoir faire évoluer une application parce que ses composantes internes bougent. Alors sur certains types d'application c'est évident qu'il faut avancer : player multimédia, jeux, système de bureau, connectivité… parce que l'environnement évolue et qu'il serait suicidaire de proposer aujourd'hui une machine sous win3.1 ou sous motif ou lesstif.
Mais certaines applications métiers peuvent tout à fait rester à l'identique parce que le workflow ne bouge pas, parce qu'elles sont entièrement adaptées à l'entreprise, et parce que pour un comptable, par exemple, qu'il ne puisse pas bénéficier d'un effet glossy sur ses boutons ou pouvoir communiquer par dbus avec d'autres applications n'est pas très grave.
Alors c'est vrai qu'une application plus maintenue se meurt petit à petit, mais je professe le logiciel libre pour que de petites entreprises puisse bénéficier d'outils "comme une grande" et si tous les 5 ans ils doivent remettre 1 000 ou 2 000 euros pour faire la migration ca limite un peu l'intérêt. Comment leur expliquer qu'il faut mettre X euros pour un truc de compta alors qu'un ebp compta qui vaut entre 100 et 500 euros sera installable pendant presque 15 ans ?
Maintenant j'ai bien saisi que le coeur du libre c'est le plaisir de ceux qui le font et que c'est un élément majeur de la réflexion et c'est à celui qui construit son application de faire attention de prendre des briques qu'il saura stable dans le temps ou a trouvé les moyens de se prémunir de trop rapides changements.
Tout ça pour dire que c'est un équilibre compliqué à trouver et appréhender, que ceux qui râlent quand ça bouge trop vite ne sont pas des passéistes grincheux et ceux qui codent "bleeding edge" ne sont pas des terroristes. De longues discussions entre les deux populations seraient bénéfiques pour tous.
[^] # Re: évoluer ou perdurer
Posté par Olivier Serve (site web personnel) . Évalué à 3.
C'est aussi l'avis des développeurs Qt. Et c'est pour ça que les API actuelles existent toujours dans Qt5. QML vient comme une possibilité supplémentaire, pas comme une obligation.
Le bureau KDE (plasma) migre vers QML car cela résoud certaines limitations de la techno actuelle. Mais il s'agit là uniquement du bureau. Les applications KDE peuvent parfaitement rester en QWidgets / QGraphicsView.
[^] # Re: évoluer ou perdurer
Posté par Sufflope (site web personnel) . Évalué à 3.
Oui enfin la sortie de Qt5 n'a pas contraint d'un pistolet sur la tempe les applis de recompiler. Alors l'appli qui n'a pas besoin de bouger elle marche encore avec Qt4 et voilà. Je ne comprends pas ton commentaire.
# et?
Posté par Albert_ . Évalué à 4. Dernière modification le 01 février 2013 à 22:00.
Plasma, ce qui est a la base du bureau de KDE, a servi, comme c'etait prevu, version de test de nouvelle technologie qui une fois mature a ete integre sous le nom de QML dans Qt pour le plus grand bonheur de pas mal d'autre projet. Naturellement pour pouvoir etre portable et non KDE dependant il a fallu modifier quelques petites choses mais bon visiblement l'architecture de KDE4 + plasma permet de faire la transition de facon totalement transparent pour les utilisateurs.
Si tu lisais le planet du projet KDE cela fait bien longtemps que tout cela est discute et que tu as des mise a jour sur les elements en transition.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.