Kate, KWrite, KDevelop, KatePart

Kate est le parfait exemple de projet raté. Plus précisément KatePart qui est un moteur d’affichage de texte, qui est utilisé ensuite par Kate, mais aussi KWrite et plus généralement n’importe quel logiciel qui a besoin d’afficher du texte coloré (du code source en général) comme KDevelop. Je pense que c’est le parfait exemple du pourquoi linux n’est pas encore prêt pour le grand public.

KatePart est une brique essentielle de l’environnement de bureau KDE puisque beaucoup de programmes vont se reposer dessus pour afficher une zone d’édition de texte. Pour les connaisseurs, on peut voir KatePart comme en gros un équivalent de Scintilla. Il peut ainsi être utilisé dans d’autres applications de manière très simple grâce aux interfaces KTextEditor qu’il implémente (l’API).

Je ne vais pas entrer dans le détail puisque l’équipe a rendu public ce problème sur leur site officiel. Ce qui est une bonne chose de reconnaître publiquement les problèmes d’un projet, et ainsi comprendre les erreurs pour ne plus les refaire. Le problème a été introduit lors de la migration vers Qt4, donc aussi de KDE3 vers KDE4. Quelques phrases clefs:

« The implementation is really complex and rather undocumented in most areas. ».
« It’s far too complex to make the KTextEditor interfaces thread-safe… »
« this shows that multi-threading simply complicates the matter a lot. »
« Hence, the current API is unfortunately pretty much broken by design. »

Bref, une mauvaise conception… Es-ce que cela peut se résumer à: « Ca à l’air bien, on fonce, on regarde ce que ça donne. » et ce à l’échelle d’une interface critique ?

La phrase de fin de l’article peut presque résumer la situation: « So maybe the issues above are a necessary step to a much better implementation » qui se comprend naturellement, c’est en faisant des erreurs que l’on apprend et améliore. Cependant, la coloration de lettres, de mots, de portions de texte, ne date pas d’aujourd’hui. Les usages que l’on peut en faire ne sont pas nouveau non plus, cela fait plus de 15 ans que les IDE existent (Delphi en 1995 par exemple). D’autant plus qu’afficher du texte, éventuellement coloré, c’est la base, KatePart est une brique fondamentale de KDE.

L’article date du 28 avril 2010, à cela on ajoute le temps de correction et autre, donc c’est fin 2010 que l’on a pu profiter de l’évolution, et durant toute cette période les rapports de bugs ont été classé en WON’T FIX (« ne sera pas corrigé). Et le downgradage était peu envisageable puisqu’il fallait retourner à KDE3 (l’API ayant changé), ou sinon utiliser la version git et c’est ce que j’ai fais.

Mon coté utilisateur a été extrêmement déçu, qu’en l’an 2010 je me sois retrouvé dans une situation de non-production à cause d’un problème d’éditeur de texte. J’utilise Arch linux pour avoir les versions de release les plus récentes, et pourtant pendant plusieurs mois cela a été bloquant. Il existait des solutions comme je l’ai indiqué, mais cela ne change rien au problème qui est que pendant plusieurs mois une version buggée de KatePart était en production (et aussi sur toutes les distributions qui utilisaient cette version), impactant les applications qui en dépendent (comme KDevelop).

Mon coté développeur a été encore plus déçu en voyant la réalité des choses.

  • Déjà, la « qualité » du code, digne d’une entreprise qui a fait codé la chose dans l’urgence et par un seul développeur. En fait dans tous les projets open source dont j’ai mis les mains, le code était vraiment pourri et déroutant (cf update-mime-database)
  • Ensuite, un composant critique, au coeur d’un environnement de travail (KDE), complétement mal pensé: aussi bien l’interface KatePart qui imposait l’utilisation abusive de signaux, que l’implémentation qui se voulait être thread-safe.
  • Une méthode de travail pas digne d’un projet qui a pour vocation d’être maintenu par d’autres, mais cela rejoint le premier point sur la qualité du code et documentation.

Pour résumer: une plus grosse déception.

Cela rejoins le problème essentiel de linux: cela a été codé pour résoudre un problème personnel: que ce soit KatePart codé pour des documents faiblement coloré, faisant donc planté une IDE comme KDevelop. PHP a été codé pour un besoin personnel… et a été codé n’importe comment: un ensemble d’outils perl à l’origine, puis couplé à du C, puis pour être entièrement recoder pour la version 3 de PHP. D’un certain coté, PHP date de 1995, par opposition à KatePart dont les besoins auxquels il était amené à répondre était connus depuis fort longtemps.

Bref, une majorité de programmes du monde de linux sont écrit par passion, et donc pour répondre avant tout au besoin de celui qui l’écrit. Cela peut être mal fait, donc il y a des ré-écritures (combien de voir j’ai pu voir ça dans des releases), ou alors c’est forké car l’auteur souhaite conserver son code pourri. Du coup linux c’est la diversité car chacun aime faire différemment, ou faire sa propre implémentation, car puisqu’il y a beaucoup d’étudiant, ils aiment bien refaire les choses pour les découvrir et les comprendre.

C’est la différence du monde propriétaire, où le besoin de l’utilisateur passe avant le besoin du développeur, dont en général le développeur n’aime pas ce qu’il fait et le fait car il est payé (mais il ne faut pas généraliser n’est-ce pas).

Advertisements

2 Responses to Kate, KWrite, KDevelop, KatePart

  1. Ping : KDE: la merde est de retour | linux aventure

  2. Ping : Kate, bugs forever | linux aventure

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :