Tu as mal compris mon commentaire.
Ce n'est pas une question de mauvais outils, ni de "j'ai pas le temps ou c'est trop tard", ni d'incompétence en programmation. C'est juste que c'est de mon point de vue la meilleure façon de faire. Si toi, tu penses que ce n'est pas la bonne façon de faire, aucun problème, c'est ton droit.
Il faut croire qu'on est pas d'accord. Donc maintenant, de deux choses l'une :
Si tu veux me convaincre que ce n'est pas la bonne façon de faire, aucun problème, ça m'intéresse même.
Par contre, j'attend un peu plus, il faut prouver ce que tu dis de manière un peu rigoureuse et scientifique. Balancer des grosses généralités sur la "bonne" façon de programmer, ça n'avance à rien. Dire que les template n'empêchent pas d'avoir plusieurs fichiers parce que Boost ou la STL ont plusieurs fichiers c'est une évidence. J'ai jamais dis le contraire. Dire qu'une classe avec +1000 lignes c'est absurde, ça commence à ressembler à un gros troll velu. Le mieux serait encore que tu proposes une alternative plus belle et plus fonctionnelle à partir des sources que je fournis gracieusement. Y a pas beaucoup de fichiers C++, donc ça ne devrait pas être un travail énorme :)
Si au contraire, tu ne cherches pas à me convaincre, essaye au moins de respecter mes choix, peut-être même tenter de les comprendre, sans me faire passer pour un neuneu de la programmation (bref, soit un peu ouvert). Je suis loin d'être aussi fermé que ton commentaire le sous-entend, et je n'accepte pas qu'on descende ce projet sous des prétextes fallacieux et des mauvaises interprétations de ta part.
Je ne vais pas changer la structure complète du code, parce que deux ou trois personnes sur Linuxfr m'ont fait remarqué que c'était mal fait. Je suis prêt à écouter tout bon conseil et toute bonne suggestion, mais à un moment donné, il faut prouver ce qu'on dit, et arrêter le déballage d'opinions sans arguments étayés. J'essaye de construire un projet libre qui marche le plus efficacement possible (tu doutes de l'efficacité de l'outil, mais l'as-tu au moins essayé?). Efficacité, à la fois dans l'exécution en elle-même, la généricité du code, la facilité de maintenance, etc.. Et pour le moment, je ne me plains pas de l'efficacité. Je me plains pas de grand chose en l'occurence, j'essaye juste d'avancer.
Prouve moi que tu peux rendre ce projet encore plus efficace et je te suivrais dans tes choix avec plaisir.
Mais sans occulter non plus tous les avantages que procurent la structure actuelle!
(Ce message est aussi valable pour N. Boulay, qui depuis quelques années, à chaque news Linuxfr sur G'MIC en profite sur donner son avis sur la bonne façon de programmer. Depuis le temps, il aurait donc eu le temps de contribuer d'une manière ou d'un autre au projet pour nous remettre dans le "droit chemin", mais on a jamais eu de nouvelles, on attend toujours).
[^] # Re: color2gray et organisation du code
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G’MIC 1.6.2.0 : Colorisation de BD, transfert de couleurs, aide au détourage et autres réjouissances. Évalué à 9. Dernière modification le 23 avril 2015 à 08:43.
Tu as mal compris mon commentaire.
Ce n'est pas une question de mauvais outils, ni de "j'ai pas le temps ou c'est trop tard", ni d'incompétence en programmation. C'est juste que c'est de mon point de vue la meilleure façon de faire. Si toi, tu penses que ce n'est pas la bonne façon de faire, aucun problème, c'est ton droit.
Il faut croire qu'on est pas d'accord. Donc maintenant, de deux choses l'une :
Si tu veux me convaincre que ce n'est pas la bonne façon de faire, aucun problème, ça m'intéresse même.
Par contre, j'attend un peu plus, il faut prouver ce que tu dis de manière un peu rigoureuse et scientifique. Balancer des grosses généralités sur la "bonne" façon de programmer, ça n'avance à rien. Dire que les template n'empêchent pas d'avoir plusieurs fichiers parce que Boost ou la STL ont plusieurs fichiers c'est une évidence. J'ai jamais dis le contraire. Dire qu'une classe avec +1000 lignes c'est absurde, ça commence à ressembler à un gros troll velu. Le mieux serait encore que tu proposes une alternative plus belle et plus fonctionnelle à partir des sources que je fournis gracieusement. Y a pas beaucoup de fichiers C++, donc ça ne devrait pas être un travail énorme :)
Si au contraire, tu ne cherches pas à me convaincre, essaye au moins de respecter mes choix, peut-être même tenter de les comprendre, sans me faire passer pour un neuneu de la programmation (bref, soit un peu ouvert). Je suis loin d'être aussi fermé que ton commentaire le sous-entend, et je n'accepte pas qu'on descende ce projet sous des prétextes fallacieux et des mauvaises interprétations de ta part.
Je ne vais pas changer la structure complète du code, parce que deux ou trois personnes sur Linuxfr m'ont fait remarqué que c'était mal fait. Je suis prêt à écouter tout bon conseil et toute bonne suggestion, mais à un moment donné, il faut prouver ce qu'on dit, et arrêter le déballage d'opinions sans arguments étayés. J'essaye de construire un projet libre qui marche le plus efficacement possible (tu doutes de l'efficacité de l'outil, mais l'as-tu au moins essayé?). Efficacité, à la fois dans l'exécution en elle-même, la généricité du code, la facilité de maintenance, etc.. Et pour le moment, je ne me plains pas de l'efficacité. Je me plains pas de grand chose en l'occurence, j'essaye juste d'avancer.
Prouve moi que tu peux rendre ce projet encore plus efficace et je te suivrais dans tes choix avec plaisir.
Mais sans occulter non plus tous les avantages que procurent la structure actuelle!
(Ce message est aussi valable pour N. Boulay, qui depuis quelques années, à chaque news Linuxfr sur G'MIC en profite sur donner son avis sur la bonne façon de programmer. Depuis le temps, il aurait donc eu le temps de contribuer d'une manière ou d'un autre au projet pour nous remettre dans le "droit chemin", mais on a jamais eu de nouvelles, on attend toujours).