Il me semble que les patchs produits par diff nécessitent un minimum de points communs, notamment que la portion de code ciblée par le patch soit la même que celle référencée dans le patch, et placée au même endroit (il y à des numéros de ligne, ça dois pas être pour rien, quand même?).
Du coup, le cumul de patches pour rendre un fichier source unique me semble proche du supplice de Sisyphe.
Je suis à peu près sûr qu'il est plus simple de juste forker et de faire des pull réguliers. Bien sûr, si les fonctions étaient chacune dans un fichier différent, les choses seraient plus aisées, et puis, ça éviterais de devoir se faire chier à fouiller dans plus de 2000 lignes de code C où est la fonction ou structure intéressante quand on veut bidouiller un peu.
J'espère vous avoir donné envie de tester dwm, avec ou sans dwm-custom,
Non, parce que je ne vois pas l'intérêt par rapport à celui que j'ai adopté, à savoir i3. Pour être moins crû, je trouve que ton journal n'explique pas vraiment l'intérêt des WM en tuile et/ou minimalistes (typiquement et dans l'ordre: pilotage complet et rapide au clavier des fenêtres et utilisation de machines à faible perf).
Tu t'es beaucoup concentré sur l'aspect configuration par la compilation, qui est, à mon avis, l'un des gros problèmes des logiciels interactifs produits par les gens de suckless (chacun ses goûts après, et malgré ma différence d'opinion j'ai un grand respect pour suckless.org), et tu n'as mis pour seul argument en faveur de dwm que le fait que selon toi cette approche minimaliste favorise le hack. D'ailleurs, perso, le style de codage de dwm:
Me fait plus dire que ça favorise le risque de planter à la moindre faute de frappe. Le bout de code que je viens de montrer (ligne 694) montre que la convention de codage mélange allègrement les blocs avec et sans accolades. Du coup, un malencontreux retour chariot au mauvais endroit, et on augmente le risque d'insérer un bug sans retour visuel (en lisant le code source). Par exemple, ajouter une ligne indentée sur le m = mons; fera croire à un lecteur inattentif qu'elle sera exécutée dans le if, ce qui ne sera pas le cas.
Dans la même veine, il y a des macros qui pourraient en C moderne être remplacées par des fonctions inline, parce que les macros c'est un truc qui à tendance à attirer des bugs bien pénibles à corriger, que le compilateur ne pourra vérifier que difficilement.
Bien sûr, on peut juste faire attention quand on programme. Mais moi, je suis partisan de m'appuyer sur des outils pour être sûr de ne pas introduire de bugs, surtout quand il s'agit d'un outil aussi central à mon usage qu'un gestionnaire de fenêtres.
Puis, franchement, une config, ça se parse une fois au lancement, et un fichier de config INI-style est bien plus simple à modifier qu'un header C, qui respecte des règle de syntaxe autrement plus complexes (macros, p.e.).
Bien sûr, un fichier de config il faut le parser à chaque démarrage, ça prend du temps CPU et un poil de RAM (de l'ordre de quelques Kio, peut-être?) et c'est un argument recevable... tout dépend du degré de confort vs ré-utilisabilité/performance que l'on souhaite.
Il s'agit de ma première contribution au libre, de ma première publication de paquet et de mon premier journal sur LinuxFR.org.
Bon courage pour la suite et au plaisir de te relire :)
Je suis un peu critique sur dwm, mais uniquement parce que je les trouve un peu trop extrémistes sur certains cas.
En réalité, j'ai beaucoup de respect pour leur philosophie, et lire leurs opinion m'à mené à des recherches plutôt intéressantes, même si mes opinions ne concordent pas nécessairement avec les leurs.
Je me suis déjà dis à plusieurs reprise qu'il faudrait un site type, suckmore, qui référencerait des projets un peu moins extrêmes que ceux de suckless tout en restait hyper-spécialisés...
# if( patchs & automatisme == maintenance_galere) return TRUE;
Posté par freem . En réponse au journal dwm-custom v0.1 : faciliter l'installation et la personalisation de dwm dans le home utilisateur. Évalué à 7.
Il me semble que les patchs produits par
diffnécessitent un minimum de points communs, notamment que la portion de code ciblée par le patch soit la même que celle référencée dans le patch, et placée au même endroit (il y à des numéros de ligne, ça dois pas être pour rien, quand même?).Du coup, le cumul de patches pour rendre un fichier source unique me semble proche du supplice de Sisyphe.
Je suis à peu près sûr qu'il est plus simple de juste forker et de faire des pull réguliers. Bien sûr, si les fonctions étaient chacune dans un fichier différent, les choses seraient plus aisées, et puis, ça éviterais de devoir se faire chier à fouiller dans plus de 2000 lignes de code C où est la fonction ou structure intéressante quand on veut bidouiller un peu.
Non, parce que je ne vois pas l'intérêt par rapport à celui que j'ai adopté, à savoir i3. Pour être moins crû, je trouve que ton journal n'explique pas vraiment l'intérêt des WM en tuile et/ou minimalistes (typiquement et dans l'ordre: pilotage complet et rapide au clavier des fenêtres et utilisation de machines à faible perf).
Tu t'es beaucoup concentré sur l'aspect configuration par la compilation, qui est, à mon avis, l'un des gros problèmes des logiciels interactifs produits par les gens de suckless (chacun ses goûts après, et malgré ma différence d'opinion j'ai un grand respect pour suckless.org), et tu n'as mis pour seul argument en faveur de dwm que le fait que selon toi cette approche minimaliste favorise le hack. D'ailleurs, perso, le style de codage de dwm:
Me fait plus dire que ça favorise le risque de planter à la moindre faute de frappe. Le bout de code que je viens de montrer (ligne 694) montre que la convention de codage mélange allègrement les blocs avec et sans accolades. Du coup, un malencontreux retour chariot au mauvais endroit, et on augmente le risque d'insérer un bug sans retour visuel (en lisant le code source). Par exemple, ajouter une ligne indentée sur le
m = mons;fera croire à un lecteur inattentif qu'elle sera exécutée dans le if, ce qui ne sera pas le cas.Dans la même veine, il y a des macros qui pourraient en C moderne être remplacées par des fonctions inline, parce que les macros c'est un truc qui à tendance à attirer des bugs bien pénibles à corriger, que le compilateur ne pourra vérifier que difficilement.
Bien sûr, on peut juste faire attention quand on programme. Mais moi, je suis partisan de m'appuyer sur des outils pour être sûr de ne pas introduire de bugs, surtout quand il s'agit d'un outil aussi central à mon usage qu'un gestionnaire de fenêtres.
Puis, franchement, une config, ça se parse une fois au lancement, et un fichier de config INI-style est bien plus simple à modifier qu'un header C, qui respecte des règle de syntaxe autrement plus complexes (macros, p.e.).
Bien sûr, un fichier de config il faut le parser à chaque démarrage, ça prend du temps CPU et un poil de RAM (de l'ordre de quelques Kio, peut-être?) et c'est un argument recevable... tout dépend du degré de confort vs ré-utilisabilité/performance que l'on souhaite.
Bon courage pour la suite et au plaisir de te relire :)
Je suis un peu critique sur dwm, mais uniquement parce que je les trouve un peu trop extrémistes sur certains cas.
En réalité, j'ai beaucoup de respect pour leur philosophie, et lire leurs opinion m'à mené à des recherches plutôt intéressantes, même si mes opinions ne concordent pas nécessairement avec les leurs.
Je me suis déjà dis à plusieurs reprise qu'il faudrait un site type, suckmore, qui référencerait des projets un peu moins extrêmes que ceux de suckless tout en restait hyper-spécialisés...