Adrien Dorsaz a écrit 943 commentaires

Hello,

Je me suis lancé aujourd'hui dans ma première contribution à une dépêche, et je trouve l'interface de rédaction vraiment bien pensée et très pratique ! Félicitations :)

Merci :)

Le seul point qui m'a un peu surpris concerne le comportement de césure de l'éditeur de texte : lorsqu'on écrit le texte au format markdown dans la boîte à cet effet, l'éditeur applique automatiquement une césure à la fin des lignes avec l'ajout d'un tiret -. Seul l'affichage est modifié : le text brut sous-jacent n'est pas modifié (par exemple, un mot affiché tronqué peut être copié-collé sur une nouvelle ligne et le tiret disparaîtra).

Ce comportement est profitable pour l'affichage du texte dans le rendu html, mais cela m'a un peu déstabilisé dans l'éditeur lui-même : je me demandais parfois si j'avais fait une faute de frappe et inséré un tiret indésirable, ou bien si le tiret était celui de l'affichage de césure.

Il me semblerait bénéfique de désactiver ce comportement d'affichage de césure dans la boîte d'édition de texte brut afin de n'afficher que le texte tapé. Curieusement, je ne retrouve pas ce comportement dans la boîte de texte utilisée pour écrire cette suggestion ? :)

Je suis tout à fait d'accord avec toi et j'ai proposé une correction dans cette entrée de suivi.

Comme c'est un doublon de demande, je vais clôturer ici et on pourra continuer à discuter là-bas si jamais.

Hello,

J'ai regardé un peu comment le code fonctionne actuellement.

L'idée actuelle est que le TEXTE DE LA RELANCE est inséré dans l'email et, également, directement dans la discussion sur le côté de la dépêche.

1) que l'on voie le texte complet de la relance quand on effectue une relance depuis l'espace de rédaction

Au début, je pensais mettre directement l'email complet dans la zone de texte.

Mais à cause de l'utilisation du message de relance dans la discussion, je ne peux pas le faire.

En plus, je dois travailler côté javascript et je crois que je n'arrive pas à récupérer le texte de l'email depuis javascript.

Je suis un peu coincé pour cette idée, désolé…

2) que le texte de la relance soit modifié ainsi

Bonjour,

vous avez créé ou contribué à la dépêche en rédaction :
TITRE DE LA DÉPÊCHE CONCERNÉE

TEXTE DE LA RELANCE

Vous pouvez retrouver et compléter votre dépêche à cette adresse :
https://linuxfr.org/redaction/news/TITRE_DE_LA_DÉPÊCHE

Merci d’avance.

--
L’équipe de LinuxFr.org

Ça c'est faisable :)

J'ai juste une question: quelle phrase générique pourrais-je mettre si aucun TEXT DE LA RELANCE n'est renseigné ?

Quelque chose comme:

L'équipe d'animation vous encourage à finaliser la dépêche.

Est-ce que ça pourrait jouer ? Est-ce que tu as une meilleure idée ?

Merci pour l'idée !

C'est vrai que, quand on édite un texte, ça ne sert pas à grand chose cette césure automatique, puisqu'elle ne sera certainement pas placée au même endroit lors du rendu réel.

J'ai préparé un merge request qui enlève la césure automatique pour tous les textarea.

Hello,

Sais-tu déjà quel langage tu souhaites initier ? Ça pourrait guider certaines propositions.

J'ai souvenir d'avoir débuté entre autre avec Notepad++ pour du PHP/HTML, mais c'était sous Windows et ce n'est pas vraiment un IDE.

Ensuite, on avait fait un peu de C et là (vers 15-16 ans je pense), j'avais pu utiliser Code::Blocks qui était pas mal. Le C était utilisé pour faire des maths appliquées, alors on n'avait pas utilisé beaucoup de fonctionnalités, mais on avait pu tester le debugger.

C'est très intéressant de voir le cheminement vers ce nouveau logo et cette nouvelle marque.

J'aime bien leur proposition finale, mais je trouve dommage d'avoir perdu le signe de l'infini. Je pense qu'il ne se voit plus et que, à la longue, on va penser que c'est juste un f stylisé.

En plus, comme le logo est placé au côté gauche du texte fedora, on perd la signification de la forme du fond bleu qui était un phylactère.

Par contre, utiliser une police de caractère libre est vraiment une évidence de nos jours :)

Bref, mon avis n'est pas très important et je pense qu'ils ont déjà eu ce genre de retours de la part de la communauté fedora.

En fait, la question que je me pose vraiment, c'est que, finalement, au lieu de changer le logo, il aurait peut être été plus simple d'assouplir les règles d'utilisation du logo et de la marque ?

Par exemple, pour leur soucis de placement sur des fonds sombres, il aurait été peut être plus simple d'accepter de mettre une bordure claire autour du phylactère ? Et même de proposer une version officielle pour gérer ce cas ?

J'ai vraiment l'impression qu'une grande partie de ce travail aurait pu être évité par la simple adaptation de 2-3 règles (et, éventuellement, la définition de plusieurs variantes officiellement acceptées).

Désolée, en ce qui me concerne, je suis absolument défavorable à un nettoyage automatique

Et pourquoi donc ? Quel est l'intérêt de garder des dépêches débutées et jamais terminées ?

De mon point de vue, c'est intéressant de trier, car c'est vraiment décourageant pour les rédacteurs de voir "Actuellement 42 dépêches sont en cours de rédaction". En tant que nouveau rédacteur, je me poserai ce genre de questions:

• Par où commencer à contribuer ?
• Est-ce que j'ose démarrer la 43ème dépêche en cours de rédaction ?
• Est-ce que c'est vraiment très difficile de proposer une dépêche ?
• Qu'est-ce qui pourrait faire que la dépêche reste 5 ans en rédaction ?

Or, je trouve que le côté le plus intéressant de LinuxFr, c'est les nouvelles collaboratives. Sinon, LinuxFr serait juste un forum / discourse communautaire comme il y en a tant sur Internet.

je pense que l'urgence est plutôt d'améliorer par exemple l'interface de saisie des commentaires

Intéressant, de ton point de vue il y a une urgence à ce sujet, alors qu'il n'y a aucune entrée de suivi ouverte liée à ça :) Ou alors je ne l'ai pas trouvée.

en permettant qu'on puisse tout voir quand on répond à un contenu ou à un commentaire, ce qui facilite les dérapages en tous genres.

Désolé, mais je ne vois pas trop le lien entre les dérapages et voir tout le contenu pendant qu'on saisi un commentaire ?

Celui qui a décidé de lancer / répondre à un troll le fera même si tous les commentaires sont affichés sur la page…

En tout cas, il faudra expliquer ce point de vue dans l'entrée de suivi :)

Effectivement, je pense que l'on n'avait simplement pas prévu que les dépêches restent 5 ans dans l'espace de rédaction :)

Pour le coup, il serait peut être vraiment intéressant que je termine le code pour le nettoyage automatique de l'espace de rédaction.

Je l'avais débuté pour cette entrée de suivi.

ah oui, bizarre, je me demande comment j'y suis arrivé, désolé pour le bruit :)

Edit:

Ah j'ai compris, j'ai cliqué sur le lien à propos des seuils d'acceptation des dépêches.

Et j'ai continué à lire celui-ci en croyant être sur celui d'avril :)

finaliser le rapport moral et préparer l’assemblée générale de LinuxFr ;

Wow, on est prévenant, on prévoit déjà celle de cet automne ? 😅

La dernière assemblée a été faite début avril et le rapport est publié dans cette dépêche.

Si j'ai bien compris la réponse, c'était "ok, on a réservé le port 22 pour SSH". Ils ne disent pas avoir audité et validé le RFC pour SSH.

C'est ça qui est fou en fait: l'auteur de SSH a pris pas mal de temps à faire son mail pour demander la réservation du port, il a pris la peine de joindre un brouillon de RFC et d'avoir une version stable presque prête et le lendemain (très rapidement) on lui répond juste "ok" 😅

Oui, tout à fait, Mathieu avait proposé d'abandonner ce système lorsque l'on passera à son nouveau design.

D'ailleurs, le travaille sur l'espace de rédaction était une partie de ce projet qui n'est pas encore terminé :)

Hello,

J'ai fermé cette entrée de suivi, parce que, comme indiqué plus bas, c'est un doublon.

L'espace de rédaction avait été fortement modifiée il y a 2 ans pour avoir une barre latérale dynamique et ça a cassé tout les thèmes alternatifs.

Hello,

Je met dans ce fil les demandes de suivis en doublon:

• RonRonnement-Classic et espace de rédaction
• L'espace de rédaction des dépêches est cassé avec le thème kaiska-short

Hello,

Je ferme la demande, parce qu'elle est en doublon à propos de la barre latérale de l'espace de rédaction.

Hello,

Les images de la demande de suivi ne sont plus accessibles.

Je ferme la demande, parce que je pense que c'est un doublon à propos de la barre latérale.

Merci !

Oui, rails a prévu la commande db:setup pour préparer la première fois la base de donnée (ça permet de la monter sans avoir besoin de passer tous les scripts).

Quand tu vois que le Docker mysql est prêt avec un log du genre:

database_1 | 2020-09-21 16:03:12 139820938893312 [Note] mysqld: ready for connections.`

tu peux exécuter la commande suivante:

docker-compose run linuxfr.org bin/rails db:setup

Dans l'idéal, il aurait fallu faire un entrypoint pour le Docker linuxfr.org pour qu'il configure la première fois la base avec db:setup.

Pour bien le faire, il faudrait faire une boucle de sleep qui attend que le Docker mysql soit prêt.

Chouette, c'est cool que ça marche :-)

L'url par défaut, c'est http://dlfp.lo

Il faut penser à configurer son fichier hosts pour le définir, ainsi que img.dlfp.lo

Pour plus d'informations, tu peux regarder le fichier Docker.md.

Alors, j'ai fait un autre Pull Request: https://github.com/linuxfrorg/linuxfr.org/pull/301

En effet, j'ai appris que Rails a décidé de proposer des versions correctives pour ne plus dépendre de mimemagick.

Je préfère ce PR, parce qu'on suit simplement les mises à jour de Rails et parce qu'on n'a pas besoin d'ajouter le paquet shared-mime-info dans les dépendances du projet.

Pour info, il y a quelques liens qui expliquent pourquoi cette version a été retirée: https://github.com/mimemagicrb/mimemagic/issues/148

mimemagic est sous license MIT et il incluait un fichier de shared-mime-info qui est sous GPL-2. La mise à jour 0.3.10, n'inclue plus ce fichier et nécessite donc l'installation du projet shared-mime-info pour rester sous license MIT.

Ok, j'ai réussi à build avec les changements de ce Pull Request: https://github.com/linuxfrorg/linuxfr.org/pull/300/files

Comme j'ai indiqué dans le Pull Request, je ne suis pas sûr de pouvoir mettre à jour la version bundle dans le Gemfile.lock.

Si ce n'est pas possible, j'aurai encore besoin de modifier le Gemfile.lock, mais en attendant, tu peux utiliser ce patch pour réussir à build l’environnement.

Hello,

Oh, je n'avais pas pensé que l'on pouvait enlever des versions sur rubygems.org…

D'un côté je comprends, les développeurs ne peuvent pas faire le support de toutes les versions, mais d'un autre côté, ce n'est pas très pratique pour pouvoir construire des environnements stables.

Même Debian Bullseye (la testing) a la version 0.3.5 de mimemagic 😅

Heureusement, je vois sur rubygems que l'on pourrait essayer de passer à la version 0.3.10, en croisant les doigts pour que semver soit bien respecté.

Si jamais, j'ai choisi de faire les images Docker avec Debian Stretch, parce que ça correspond aux serveurs de productions de LinuxFr et parce que je n'avais simplement pas réussi à monter l'environnement avec Buster.

Je n'ai pas assez d'expérience avec les environnements Ruby et Rails pour m'aventurer avec d'autres versions de Debian, mais c'est volontiers si quelqu'un y arrive :)

Ce n'est qu'une question d'habitudes… Attention, elles changent souvent 😂

L'article explique justement qu'Adwaita est maintenant clairement le langage visuel et comportemental de GNOME et, surtout, validé par l'équipe design de GNOME.

De fait, c'est un thème GTK, un set d'icônes et de widgets GTK prêt à l'emploi pour créer une application estampillée GNOME (ou qui cible uniquement la plateforme GNOME).

Le thème Adwaita que tu as connu avant va s'appeler dorénavant "Défaut" dans GTK et sera une copie de l'ancien Adwaita. Il ne suivra plus les préceptes de GNOME et deviendra naturellement compatible multi-plateforme, car GTK ne cible plus aucune plateforme en particulier (Windows, MacOS, Elementary, XFCE…).

La bonne nouvelle de ce changement d'habitude, c'est que GTK pourra enfin mieux fonctionner sur Windows, MacOS, Elementary, XFCE… et ce sans avoir besoin de triturer le thème par défaut ni les widgets par défaut.

Il faut voir Adwaita, comme la marque de GNOME. Avant, GTK 3 était très lié à GNOME et c'est pour ça que Adwaita était directement dans GTK.

Aujourd'hui, GTK n'a plus besoin d'évoluer aussi vite que GNOME, il faut voir ça comme un bon signe: GTK est devenue plus mûre et assagit sa vitesse de développement pour être à nouveau plus stable, générique et multiplateforme :-)

Toutefois, je pense que l'on ne va pas se retrouver bloqué avec de vieux widgets comme à l'époque de GTK+ 2 et GNOME 2: en effet, libadwaita permettra d'expérimenter de nouveaux widgets et, à terme, s'ils sont intéressants pour toutes les plateformes cibles de GTK, de les intégrer dans GTK directement.

J'ai le sentiment que GNOME et GTK ont enfin pu se séparer correctement grâce à GTK 4 et son nouveau paradigme où "tout est un widget" (enfin, si j'ai bien suivi GTK 4, je ne suis pas sûr).

Pas de problèmes, merci pour l'explication :)

C'est ça, on est déjà passé en Regular.

Le titre du sondage est donc lui même faux.