Ce que j'ai voulu dire c'est que quelqu'un qui me dit "c'est comme ça qu'il faut travailler" alors qu'il ne sait même pas quels sont mes besoins arrive en mode "je détiens la vérité". En l'occurence non.
Les dév. ont fait des choix, moi j'utilise beaucoup gimp en mode bidouille (parce que c'est de la bidouille que je fais, c'est pas du travail "pro") et je pense que l'outil n'est plus celui qui me convient ; sur ce on me dit "c'est comme ça que tu dois travailler parce que ta méthode perd de l'information", c'est à ça que je fais allusion dans ce que tu cites.
C'est un peu comme quand tu développes un proto ou que tu fais un "proof of concept" et qu'on te dit "tu as pas bien suivi les règles de nommage" ou "ton code n'est pas flexible". On s'en fout : dans ce cas, l'objectif c'est d'arriver rapidement à un résultat présentable - il sera temps plus tard de travailler proprement et en suivant les bonnes pratiques.
Prenons un exemple dans le monde du développement. Supposons que tu aies un workflow de développement avec des revues de code obligatoires avant commit. Supposons que tu travailles sur un proto dont la seule raison d'être est de montrer que ça marche. Si ton mécanisme de revues de code n'est pas débrayable, tu vas commiter ailleurs parce que c'est lourd et ça n'a aucun intérêt dans ton cas. Il se trouve que tu pourras probablement utiliser le même outil (git par exemple) pour travailler en mode "crado" et en mode "pro" tout en sachant dans les deux cas conserver de la même manière ton statut commit/pas commit. C'est ça que j'aurais aimé.
[^] # Re: Dynamisme de GIMP
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse à la dépêche Financement participatif de dessin symétrique dans GIMP. Évalué à 0.
Ce que j'ai voulu dire c'est que quelqu'un qui me dit "c'est comme ça qu'il faut travailler" alors qu'il ne sait même pas quels sont mes besoins arrive en mode "je détiens la vérité". En l'occurence non.
Les dév. ont fait des choix, moi j'utilise beaucoup gimp en mode bidouille (parce que c'est de la bidouille que je fais, c'est pas du travail "pro") et je pense que l'outil n'est plus celui qui me convient ; sur ce on me dit "c'est comme ça que tu dois travailler parce que ta méthode perd de l'information", c'est à ça que je fais allusion dans ce que tu cites.
C'est un peu comme quand tu développes un proto ou que tu fais un "proof of concept" et qu'on te dit "tu as pas bien suivi les règles de nommage" ou "ton code n'est pas flexible". On s'en fout : dans ce cas, l'objectif c'est d'arriver rapidement à un résultat présentable - il sera temps plus tard de travailler proprement et en suivant les bonnes pratiques.
Prenons un exemple dans le monde du développement. Supposons que tu aies un workflow de développement avec des revues de code obligatoires avant commit. Supposons que tu travailles sur un proto dont la seule raison d'être est de montrer que ça marche. Si ton mécanisme de revues de code n'est pas débrayable, tu vas commiter ailleurs parce que c'est lourd et ça n'a aucun intérêt dans ton cas. Il se trouve que tu pourras probablement utiliser le même outil (git par exemple) pour travailler en mode "crado" et en mode "pro" tout en sachant dans les deux cas conserver de la même manière ton statut commit/pas commit. C'est ça que j'aurais aimé.
J'ai l'impression que c'est un peu ce que faisait gimp avec le mécanisme précédent consistant à fusionner les calques comme le fait remarquer Grégoire dans ce commentaire.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo