# apt-get install xcalib
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Paquets suggérés :
icc-profiles
Les NOUVEAUX paquets suivants seront installés :
xcalib
0 mis à jour, 1 nouvellement installés, 0 à enlever et 2707 non mis à jour.
Il est nécessaire de prendre 18,8 ko dans les archives.
Après cette opération, 46,1 ko d'espace disque supplémentaires seront utilisés.
Réception de:1 http://debian.proxad.net/debian oldstable/main amd64 xcalib amd64 0.8.dfsg1-2+b2 [18,8 kB]
18,8 ko réceptionnés en 0s (81,3 ko/s)
Sélection du paquet xcalib précédemment désélectionné.
(Lecture de la base de données... 403824 fichiers et répertoires déjà installés.)
Préparation du dépaquetage de .../xcalib_0.8.dfsg1-2+b2_amd64.deb ...
Dépaquetage de xcalib (0.8.dfsg1-2+b2) ...
Paramétrage de xcalib (0.8.dfsg1-2+b2) ...
Traitement des actions différées (« triggers ») pour man-db (2.7.6.1-2) ...
Erreur : Le délai d'attente est dépassé
root@atilde:/home/a# man xcalib
$ xcalib -invert -alter
tout le bureau est en mode nuit /dev/tty3
dehors il fait jour : /dev/tty*
tous les terminaux fenêtrés sont en enneigés
donc, ça solutionne le problème, mais d'une façon un peu violente
Lorsqu'on s'est habitué à des codes couleurs avec certains applications, se retrouver avec des couleurs inversées peut revenir à mettre des chaussettes à un chat.
le lien fourni plus haut donnait le paquet source de xcalib officiel
(pour rappel 18 fichiers)
dans lequel se trouve peut-être le moyen d'applique le résultat à une fenêtre en particulier, ce qui à mon avis n'est pas illusoire
Le temps que l'on passe à écrire on ne le passe pas à chercher, et de toute façon je ne comprends pas le C. C'est un peu comme pour la justice, le temps qu'on passe à tenter de la saisir, on ne fait pas autre chose, c'est pourquoi généralement le peuple préfère s'en passer et préfère le Mode Gourdin.
Les #Legaltech devraient changer ça pour les générations futures, qui sait ?
Si c'est bien le code déjà copié plus haut :
grep -R invert xcalib-0.8/
xcalib-0.8/README: -invert or -i
xcalib-0.8/xcalib.c: fprintf (stdout, " -invert or -i\n");
xcalib-0.8/xcalib.c: int invert = 0;
xcalib-0.8/xcalib.c: /* invert the LUT */
xcalib-0.8/xcalib.c: if (!strcmp (argv[i], "-i") || !strcmp (argv[i], "-invert")) {
xcalib-0.8/xcalib.c: invert = 1;
xcalib-0.8/xcalib.c: if(!invert) {
alors il est possible que la transformation soit effectuée à haut niveau, en ne puisse s'appliquer à une fenêtre sans réutilisation du code dans une application spécifique, ou une modification significative de l'existant.
Quelqu'un pour confirmer ?
/eof
La question était bien que si on peut obtenir un mode jour|nuit,
comment allumer la lumière, où se trouve l'interrupteur pour ne pas à avoir à chaque fois couper le compteur central avec le frigo ?
La documentation est limitée.
Le man xcalib est peu développé, comme bien des man récents. On n'y trouve aucune indications sur une utilisation avancée, ou des perspectives de recherche. C'est malheureusement le cas avec KDE, où rien n'est documenté, il n'y a aucun man.
C'est sans doute un choix d'efficacité, en rapport avec un manque de moyens, un peu comme les logiciels Microsoft, aussi obscur qu'inexploitables en profondeur, mais très jolis et surtout efficaces. Les gains de Microsoft ne sont pas en rapport avec un prix élevé, mais une quantité élevée.
Le code d'un logiciel libre est une documentation.
KDE ne peut s'appuyer que sur du bénévolat, étudiants par exemple, et les dons effectués ne peuvent qu'être dérisoires au vu de la tâche à accomplir.
Il est très regrettable que KDE ne puisse pas être plus documenté (on a les sources, donc quiconque sait les lire peut y contribuer, mais faut-il encore comprendre le C et avoir un peu de temps pour améliorer la doc et y placer son nom et son adresse pour pouvoir le valoriser plus tard si besoin)
La doc n'est pas là seulement par confort, elle permet de inventer et exploiter à fond un logiciel, et pourvoir construire sur ses fondations ?
La baisse de la qualité de la doc et l'augmentation des applications non documentées avec man, n'est-elle pas un symptôme de régression du libre ?
L'exemple simple de Kmail me vient à l'esprit. Une fonction très utile permettait afficher et imprimer un message avec ses entêtes. Très utile pour indiquer des références précises et sûres de l'origine affichée d'un courriel, quand bien-même on se l'envoie à soit-même pour dater un document.
Il s'agissait de la fonction Afficher/en-têtes/all headers.
Cette fonction a été supprimée.
Pour avoir tenté de regarder le code, il s'agissait d'un petit bout de code. Intégré dans une application gigantesque. Non modulaire en lui-même, il ne pouvait donc être ajouté sans être capable de recompiler l'application dans son entier.
Burg eport
Il m'a été répondu à la légère, lorsque j'avais signalé un rapport de bug, que c'était possible d'obtenir le code souce avec la fonction Afficher/Afficher le source.
Oui, peut-être, mais ce n'est pas ce dont j'ai besoin, ça ne fait pas la même chose. Là le code du message est codé et inexploitable en l'état, et certainement pas imprimable pour que son contenu, hors références, puisse être lu par un humain. Ce n'est pas la même fonction, ce n'est pas le même résultat, et ce n'est pas la même application du résultat. On passe d'un texte lisible avec ses références d'entête à un texte brut codé non lisible.
$ recode
Il m'a aussi été répondu que je pouvais utiliser cet outil pour retrouver le codage lisible du texte.
Un logiciel à apprendre pour un résultat incertain, mais qui a le mérite d'exister.
Elle ne remplace toutefois pas la productivité de la fonction d'origine manquante, où d'un clic on avait le résultat escompté, en imposant un apprentissage supplémentaire, des copier-coller, et de sortir les données de l'application métier pour la traiter avec une bidouille.
Une alternative ?
J'ai recherché rapidement parmi les autres applications métier (lecteur courriel), aucun ne permettait d'imprimer en-têtes et texte. Parfois il était impossible d'obtenir les entêtes (ou je ne savais pas le faire gmail.com).
REGRESSION DE CODE
Le code écrit effacé a été produit, réfléchi et pensé par un humain.
Cet humain a engagé une partie de sa vie à réaliser une fonction qu'il savait utile. D'autres sont passés derrière, n'y ont vu que du feu et l'on virée.
Utiliser une version ancienne qui donne toute satisfaction pour se passer des nouvelles versions auxquelles il manque ces détails indispensables dans certains cas ?
Dans le cas d'une application KDE, ça semble impossible tant il y a de dépendances. Mais pas impossible.
Virtualisation
Il y a d'abord la virtualisation qui permet d'émuler un environnement complet et d'interagir avec le système hôte sous certaines conditions. Efficace, mais qui requiert beaucoup de ressources sur l'unité de travail (faire tourner un système supplémentaire en parallèle). Et dont la configuration n'est pas anodine, voire quasi impossible pour un non initié.
KDE multi-versions
Installer plusieurs librairies de kde concurrentes pour faire tourner plusieurs générations de logiciels ensemble. Ce qui là aussi prend beaucoup de ressources, même si on pourrait imaginer utiliser des liens symboliques entre les fichiers partagés, pour réduire la complication. La configuration n'est pas anodine, voire quasi impossible pour un non initié.
La solution la plus simple est de rajouter ce petit bout de code supprimé sans raison apparente, ne serait-ce que pour le temps passé par son auteur à produire une fonction qui utile et unique.
[^] # Re: Xorg ou Kwin : xcalib, KDE, Kmail, documentation man ou régression de code (dimanche)
Posté par Patrick Trauquesègues . En réponse au message kmail*reverseVideo: on ou comment afficher kmail en vidéo inversée ?. Évalué à -2. Dernière modification le 05 septembre 2021 à 19:03.
tout le bureau est en mode nuit /dev/tty3
dehors il fait jour : /dev/tty*
tous les terminaux fenêtrés sont en enneigés
donc, ça solutionne le problème, mais d'une façon un peu violente
Lorsqu'on s'est habitué à des codes couleurs avec certains applications, se retrouver avec des couleurs inversées peut revenir à mettre des chaussettes à un chat.
le lien fourni plus haut donnait le paquet source de xcalib officiel
(pour rappel 18 fichiers)
dans lequel se trouve peut-être le moyen d'applique le résultat à une fenêtre en particulier, ce qui à mon avis n'est pas illusoire
Ici est le code où naviguer :
https://github.com/zoltanp/xcalib-src
Le temps que l'on passe à écrire on ne le passe pas à chercher, et de toute façon je ne comprends pas le C. C'est un peu comme pour la justice, le temps qu'on passe à tenter de la saisir, on ne fait pas autre chose, c'est pourquoi généralement le peuple préfère s'en passer et préfère le Mode Gourdin.
Les #Legaltech devraient changer ça pour les générations futures, qui sait ?
Si c'est bien le code déjà copié plus haut :
alors il est possible que la transformation soit effectuée à haut niveau, en ne puisse s'appliquer à une fenêtre sans réutilisation du code dans une application spécifique, ou une modification significative de l'existant.
Quelqu'un pour confirmer ?
/eof
La question était bien que si on peut obtenir un mode jour|nuit,
comment allumer la lumière, où se trouve l'interrupteur pour ne pas à avoir à chaque fois couper le compteur central avec le frigo ?
La documentation est limitée.
Le man xcalib est peu développé, comme bien des man récents. On n'y trouve aucune indications sur une utilisation avancée, ou des perspectives de recherche. C'est malheureusement le cas avec KDE, où rien n'est documenté, il n'y a aucun man.
C'est sans doute un choix d'efficacité, en rapport avec un manque de moyens, un peu comme les logiciels Microsoft, aussi obscur qu'inexploitables en profondeur, mais très jolis et surtout efficaces. Les gains de Microsoft ne sont pas en rapport avec un prix élevé, mais une quantité élevée.
Le code d'un logiciel libre est une documentation.
KDE ne peut s'appuyer que sur du bénévolat, étudiants par exemple, et les dons effectués ne peuvent qu'être dérisoires au vu de la tâche à accomplir.
Il est très regrettable que KDE ne puisse pas être plus documenté (on a les sources, donc quiconque sait les lire peut y contribuer, mais faut-il encore comprendre le C et avoir un peu de temps pour améliorer la doc et y placer son nom et son adresse pour pouvoir le valoriser plus tard si besoin)
La doc n'est pas là seulement par confort, elle permet de inventer et exploiter à fond un logiciel, et pourvoir construire sur ses fondations ?
La baisse de la qualité de la doc et l'augmentation des applications non documentées avec man, n'est-elle pas un symptôme de régression du libre ?
L'exemple simple de Kmail me vient à l'esprit. Une fonction très utile permettait afficher et imprimer un message avec ses entêtes. Très utile pour indiquer des références précises et sûres de l'origine affichée d'un courriel, quand bien-même on se l'envoie à soit-même pour dater un document.
Il s'agissait de la fonction Afficher/en-têtes/all headers.
Cette fonction a été supprimée.
Pour avoir tenté de regarder le code, il s'agissait d'un petit bout de code. Intégré dans une application gigantesque. Non modulaire en lui-même, il ne pouvait donc être ajouté sans être capable de recompiler l'application dans son entier.
Burg eport
Il m'a été répondu à la légère, lorsque j'avais signalé un rapport de bug, que c'était possible d'obtenir le code souce avec la fonction Afficher/Afficher le source.
Oui, peut-être, mais ce n'est pas ce dont j'ai besoin, ça ne fait pas la même chose. Là le code du message est codé et inexploitable en l'état, et certainement pas imprimable pour que son contenu, hors références, puisse être lu par un humain. Ce n'est pas la même fonction, ce n'est pas le même résultat, et ce n'est pas la même application du résultat. On passe d'un texte lisible avec ses références d'entête à un texte brut codé non lisible.
$ recode
Il m'a aussi été répondu que je pouvais utiliser cet outil pour retrouver le codage lisible du texte.
Un logiciel à apprendre pour un résultat incertain, mais qui a le mérite d'exister.
Elle ne remplace toutefois pas la productivité de la fonction d'origine manquante, où d'un clic on avait le résultat escompté, en imposant un apprentissage supplémentaire, des copier-coller, et de sortir les données de l'application métier pour la traiter avec une bidouille.
Une alternative ?
J'ai recherché rapidement parmi les autres applications métier (lecteur courriel), aucun ne permettait d'imprimer en-têtes et texte. Parfois il était impossible d'obtenir les entêtes (ou je ne savais pas le faire gmail.com).
REGRESSION DE CODE
Le code écrit effacé a été produit, réfléchi et pensé par un humain.
Cet humain a engagé une partie de sa vie à réaliser une fonction qu'il savait utile. D'autres sont passés derrière, n'y ont vu que du feu et l'on virée.
Utiliser une version ancienne qui donne toute satisfaction pour se passer des nouvelles versions auxquelles il manque ces détails indispensables dans certains cas ?
Dans le cas d'une application KDE, ça semble impossible tant il y a de dépendances. Mais pas impossible.
Virtualisation
Il y a d'abord la virtualisation qui permet d'émuler un environnement complet et d'interagir avec le système hôte sous certaines conditions. Efficace, mais qui requiert beaucoup de ressources sur l'unité de travail (faire tourner un système supplémentaire en parallèle). Et dont la configuration n'est pas anodine, voire quasi impossible pour un non initié.
KDE multi-versions
Installer plusieurs librairies de kde concurrentes pour faire tourner plusieurs générations de logiciels ensemble. Ce qui là aussi prend beaucoup de ressources, même si on pourrait imaginer utiliser des liens symboliques entre les fichiers partagés, pour réduire la complication. La configuration n'est pas anodine, voire quasi impossible pour un non initié.
La solution la plus simple est de rajouter ce petit bout de code supprimé sans raison apparente, ne serait-ce que pour le temps passé par son auteur à produire une fonction qui utile et unique.