Réutilisabilité, modèle "briques" et gravure de cd - Page 1

Ce n'est pas une question, juste une remarque qui me venait à l'esprit dans l'autre topic, et que j'ai jugé préférable de séparer dans un autre sujet.

K3B (ou mettez ici votre interface favorite) représente l'archétype de la philosophie Unix du développement.

- un outil sait lire des fichiers. Il n'a pas d'interface qui pique, il ne sert qu'à ça, il ne sait faire que ça, mais il le fait bien.
- un outil sait créer des images iso à partir de fichiers. Il n'a pas d'interface qui pique, il ne sert qu'à ça, il ne sait faire que ça, mais il le fait bien.
- un outil sait graver une image sur un cd. Il n'a pas d'interface qui pique, il ne sert qu'à ça, il ne sait faire que ça, mais il le fait bien.
- une interface a des jolis boutons qui piquent, elle ne sait pas lire de fichiers, elle ne sait pas créer d'images iso, elle ne sait pas graver. Elle sait faire joli, déclencher les autres outils et les faire communiquer ensemble; elle ne sert qu'à ça, elle ne sait faire que ça, mais elle le fait bien.

Je trouve ça beau et propre.
[/mavie]

Moi aussi, c'est ce que j'apprécie dans Linux

Je ne comprends quand même pas pourquoi un outil ne pourrait pas avoir une jolie interface et bien faire son travail ?

ben je pense qu'il faut 1) que le backend soit réutilisable pour une autre interface 2) que le backend n'ait pas de dépendances vers qt/gtk, et donc que ça soit dispo en tant que version sans interface...

enfin cela dit la gravure de cd est un truc particulièrement simple à séparer en composants : aucune interaction une fois le processus lancé, et à peu près aucune communication (juste l'état d'avancement et les éventuelles erreurs)

bah le 1) peut très bien être vérifié tout en ayant une interface, non ? Je pense notamment aux applis Apple, qui souvent offrent une double API ObjectiveC / AppleScript (voire même automator et ligne de commande unixienne) tout en ayant une interface graphique.
pour le 2) ok ^^ mais quelle idée de ne pas avoir un truc unifié

Flanker> Si si, bien sûr un logiciel peut avoir une jolie interface tout en faisant lui-même tout le boulot, mais ça demande plus de codage, ça peut induire de réinventer l'existant, etc.
Ce qui est intéressant dans le domaine du libre c'est que chaque brique développée peut être réutilisée, ce qui limite la réécriture de l'existant.

Bah comment souvent, c'est effectivement plus interessant du coté du développeur, mais perso quand j'utilise une application, j'aime bien l'idée que le programme soit un seul et même bloc, autonome, fiable et solide, qui fait tout ce je veux qu'il fasse (et qui ne fasse que ça, et qui le fasse bien ^^). Ça ne demande pas forcément de "réinventer l'existant" à chaque fois, mais ça demande bien sûr plus de travail et de temps qu'en ayant la possibilité de faire communiquer des outils qui existent déjà. Tout dépend de quel bout on regarde ^^

Et je trouve ça franchement pas pratique quand on se retrouve avec des milliards de petits programmes qui ne font qu'une chose
Je ne sais pas si c'est encore le cas, mais un moment on m'avait dit d'utiliser un programme uniquement pour activer la touche NumLock a démarrage de ma debian, par exemple. Ok, il ne fait que ça, il le fait bien, mais je trouve que c 'est franchement absurde que ce genre de fonctionnalité soit dans un programme indépendant.

Flanker :
Et je trouve ça franchement pas pratique quand on se retrouve avec des milliards de petits programmes qui ne font qu'une chose

oui enfin le principe c'est que tu demandes juste d'installer k3b et il installe d'autres trucs dans ton dos, t'as pas besoin de savoir que k3b utilise en interne tel ou tel programme ^^

Exactement. Du point de vue utilisateur c'est transparent quand il utilise k3b. Il peut toutefois noter la différence s'il a plusieurs interfaces différentes, parce qu'elles se comporteront de manière cohérente (un bug corrigé dans le backend sera corrigé simultanément pour toutes les "applications" point de vue utilisateur).

D'ailleurs :

peut très bien être vérifié tout en ayant une interface, non ? Je pense notamment aux applis Apple, qui souvent offrent une double API ObjectiveC / AppleScript (voire même automator et ligne de commande unixienne) tout en ayant une interface graphique.

A moins d'avoir mis le nez dans l'implémentation, tu n'en sais absolument rien, il est parfaitement envisageable, voire même probable que les développeurs Apple aient bien séparé les composants et qu'ils s'appellent les uns les autres.

ce que j'apprécie moins c'est...

(venez tenter d'installer une gentoo sur un parisc 2.0)

(t'as de droles d'idées en même temps )