Qu'est-ce que tu fais si $EDITOR pointe vers un truc inexistant ?
Tu retournes au défaut que tu as proposé évidemment.
Et regarde le cas "simple" d'Emacs qui a un mode par type de fichier. Pour faire du mail, idéalement tu veux indented-text, auto-fill, et filladapt (et j'oublie font-lock). vi lui est complètement différent. Comment tu fais pour lui dire de passer au bon mode ?
Si ça t'amuse de le faire tu peux essayer, mais sinon laisse l'utilisateur définir sa ligne de commande, ce sera bien suffisant. C'est un programme externe, évidemment qu'on ne va pas chercher à la contrôler avec le même niveau que des composants. On lance, on récupère éventuellement un fichier temporaire. Pour les viewers on lance, on ne fait rien d'autre, l'utilisateur a défini la ligne de commande.
Sauf que tu dois te frapper le codage du parsing de la config, plus l'éditeur de préférences parce que de nos jours éditer des fichiers de conf à la main c'est un peu passé de mode.
N'importe quoi ça fait maximum une ligne, si tu as une config ça s'ajoute comme n'importe quelle autre élément de config. De plus les fichiers de mode c'est passé de mode ? Tiens donc, suivant que ça t'arrange, l'utilisateur est tantot geek tantot neuneu. Eh bien puisque tu considérais que c'était forcément un geek, il saura bien faire avec un fichier de conf, pas la peine d'en proposer plus.
Oui, et elle recouvre 99% des besoins des utilisateurs normaux.
L'utilisateur normal étant défini parce qu'il utilise, ce qui n'est jamais que ce qui lui est proposé, ce 99% ne veut d'une part rien dire, et ne serait d'autre part pas une bonne raison pour oublier 1% restant quand l'implémentation n'est pas un problème. Enfin les développeurs font ce qu'ils veulent, je dis juste que c'est dommage.
Et ils ont tout à fait raison. Enfin non, c'est pas qu'il n'a pas à le faire, c'est qu'il s'en fout complètement.
Comme je l'ai dit, celui qui s'en fout prendra celui qui est proposé par défaut. Pour les autres ce n'est certainement pas toi qui a à leur imposer ce qu'ils veulent utiliser. Dès qu'on a des critères c'est normal de vouloir choisir un wm plutot qu'un autre.
Et peut-être qu'on aurait un peu plus d'applis correctes.
Rien ne permet de l'affirmer, par contre ce serait beaucoup de choses en moins. Mais vas-y, fais ton OS+Framework+Logiciels avec une norme stricte. C'est satisfaisant pour le développeur, pas trop pour l'utilisateur.
Ben ça existe toujours, et quelques fois même on s'en sert.
Très bien dans ces cas là, mais ça a tendance à disparaître dès qu'une solution composants est écrite.
[^] # Re: Confusion gestionaire de fenêtres - environements
Posté par #3588 . En réponse à la dépêche Ximian ou KDE sur une petite machine?. Évalué à 3.
Tu retournes au défaut que tu as proposé évidemment.
Et regarde le cas "simple" d'Emacs qui a un mode par type de fichier. Pour faire du mail, idéalement tu veux indented-text, auto-fill, et filladapt (et j'oublie font-lock). vi lui est complètement différent. Comment tu fais pour lui dire de passer au bon mode ?
Si ça t'amuse de le faire tu peux essayer, mais sinon laisse l'utilisateur définir sa ligne de commande, ce sera bien suffisant. C'est un programme externe, évidemment qu'on ne va pas chercher à la contrôler avec le même niveau que des composants. On lance, on récupère éventuellement un fichier temporaire. Pour les viewers on lance, on ne fait rien d'autre, l'utilisateur a défini la ligne de commande.
Sauf que tu dois te frapper le codage du parsing de la config, plus l'éditeur de préférences parce que de nos jours éditer des fichiers de conf à la main c'est un peu passé de mode.
N'importe quoi ça fait maximum une ligne, si tu as une config ça s'ajoute comme n'importe quelle autre élément de config. De plus les fichiers de mode c'est passé de mode ? Tiens donc, suivant que ça t'arrange, l'utilisateur est tantot geek tantot neuneu. Eh bien puisque tu considérais que c'était forcément un geek, il saura bien faire avec un fichier de conf, pas la peine d'en proposer plus.
Oui, et elle recouvre 99% des besoins des utilisateurs normaux.
L'utilisateur normal étant défini parce qu'il utilise, ce qui n'est jamais que ce qui lui est proposé, ce 99% ne veut d'une part rien dire, et ne serait d'autre part pas une bonne raison pour oublier 1% restant quand l'implémentation n'est pas un problème. Enfin les développeurs font ce qu'ils veulent, je dis juste que c'est dommage.
Et ils ont tout à fait raison. Enfin non, c'est pas qu'il n'a pas à le faire, c'est qu'il s'en fout complètement.
Comme je l'ai dit, celui qui s'en fout prendra celui qui est proposé par défaut. Pour les autres ce n'est certainement pas toi qui a à leur imposer ce qu'ils veulent utiliser. Dès qu'on a des critères c'est normal de vouloir choisir un wm plutot qu'un autre.
Et peut-être qu'on aurait un peu plus d'applis correctes.
Rien ne permet de l'affirmer, par contre ce serait beaucoup de choses en moins. Mais vas-y, fais ton OS+Framework+Logiciels avec une norme stricte. C'est satisfaisant pour le développeur, pas trop pour l'utilisateur.
Ben ça existe toujours, et quelques fois même on s'en sert.
Très bien dans ces cas là, mais ça a tendance à disparaître dès qu'une solution composants est écrite.