Guillaume Denry a écrit 2965 commentaires

Comme dit le poète, le meilleur format est certainement celui qu'on maîtrise le mieux

Bof, je ne crois pas à ce genre d'affirmation, on peut mesurer objectivement les avantages et inconvénients d'un format, comme d'un langage ou bien comme de n'importe quel produit technique, car on est pas en train de parler du goût des pommes ou des poires. Bien sûr, les compétences de l'équipe compte, mais c'est juste un des critères de choix.

L'abstraction, c'est souhaitable lorsque les systèmes offrent des similarités de fonctionnement, mais lorsqu'ils s'éloignent trop les uns des autres, ça devient contre-productif et comme je le disais, les gens souhaitent bosser sur ce qui leur plaît et leur quantité est limitée, donc…

Et bien pour l'instant le pari de Linus est gagné, de nouveaux territoires techniques sont défrichés, et le noyau et systemd sont totalement libres.
Alors, veux-tu dire que systemd aurait dû ignorer les avancées techniques du noyau Linux pour "respecter" les autres systèmes afin qu'eux aussi puissent profiter de systemd ?
Je veux dire, c'est beau la théorie, mais dans la vraie vie, le nombre de développeurs dans le libre est limité, si des gens sont motivés pour construire un système plus performant et mieux architecturé autour des avancés du noyau linux, mais qu'à côté personne ne l'est assez pour faire évoluer les autres systèmes vers quelque chose du même acabit, qui faut-il blâmer ?
Au final, il ne faut pas oublier qu'on a quelque chose de totalement libre, documenté, adaptable, c'est ça la grande rupture avec Windows et MacOS.

On se satisfait de pilotes propriétaires qui ne fonctionnent qu’avec Linux, sans plus déplorer l’absence de pilotes libres (ou mieux, de spécifications) dont pourraient profiter d’autres systèmes.

Je pense que tous ceux qui luttent pour construire des pilotes libres apprécieront :)
(et puis j'ai un peu de mal à apprécier le rapport avec le sujet ici)

On s’offusquait avant que tel logiciel ne soit disponible que pour Windows et Mac OS, aujourd’hui on est ravi d’avoir seulement ajouté Linux à la liste.

Inutile d'anticiper à ce point l'avenir, le nombre de logiciels libres uniquement disponibles pour linux et pas les autres systèmes de type unix n'est pas si élevé…
J'irais même plus loin, et si l'idéal n'était pas une prolifération de systèmes d'exploitation libre (de la taille de linux et répandu à grande échelle de manière industrielle hein, je mets à part les systèmes d'exploitation expérimentaux ou de niche) mais une unification autour de quelques grands systèmes afin de concentrer les forces pour continuer à défricher de nouveaux territoires ?

Mir est déjà tombé à l'eau (le pacifique sud pour être précis), c'est pas comme s'il/elle n'avait pas l'habitude.

Il fut un temps où l’ambition de Linux n’était pas seulement de percer pour lui-même, mais d’ouvrir la voie pour d’autres systèmes libres.

Il me semble que cette affirmation tient un petit peu du fantasme, la communauté du libre est très diverse, il n'y a pas d'"ambition de Linux", certains sont très attachés à l'ouverture vers les autres systèmes, certains non, ils ont juste en commun de vouloir écrire des logiciels libres.

Je ne pense pas qu'on puisse comparer les commentaires d'un site francophone (dont la vocation est d'être un espace d'expression spécifiquement francophone) aux commentaires qu'on peut trouver dans un produit qui en général ne s'attache pas vraiment à la langue de l'environnement et surtout, qui a une forte valeur de capitalisation et de ré-utilisabilité et dont on aurait bien du mal à définir le périmètre linguistique dans un avenir à moyen et long terme.
Mais je t'avoue que mon avis sur l'anglais dans le code source (puisque je pense à ça principalement) est loin d'être ferme et définitif, je suis également tiraillé par mon affection pour ma langue natale et plus généralement, par la diversité linguistique de notre monde. Et en effet, si l'on sait qu'un produit n'est définitivement pas destiné à sortir d'un environnement mono-linguistique, autant profiter pleinement du bénéfice de la langue natale. Malheureusement, dans un monde de plus en plus mondialisé, je pense que ces cas là deviennent relativement de niche.

Des produits non internationaux, et qui n'ont pas la préoccupation de la langue universelle, se contente bien de produire le contenu dans la langue natale et pas en anglais dont les logs pour des raisons de conforts et de facilité.

Peut-être qu'utiliser systématiquement l'anglais dans le produit est un gage de pérennité et signifie "on est prêt éventuellement à s'ouvrir à l'international, on aura pas à repasser partout comme ceux qui doivent dégager l'allemand des sources de libreoffice" ?

Tu es surtout confronté (comme moi à l'époque) au fait que les composants de base de QtQuick sont relativement primitifs et qu'on se retrouve à réinventer la roue lorsqu'on souhaite revenir à iso-fonctionnalités avec les applications plus « traditionnelles ».

Cela dit, vu que je suis un peu rouillé en QML ces temps-ci, j'ai oublié de te dire que si tu as la possibilité d'utiliser QtQuick.Controls 1.1, tu as le TableView qui formalise un peu plus le concept de tableau.
Mais attention, contrairement au listview qui est "à poil", ce composant utilise par défaut le thème natif de la plateforme cible, mais tu peux le customiser aux petits oignons.

Ceci dit je ne sait toujours pas comment faire une simple table avec du qml : mon modèle me donne plusieurs valeurs pour chaque index et je veux simplement que les colonnes puissent se redimensionner en fonction du contenu.

Une table en QML, c'est classiquement le ListView.
Et au niveau des largeurs automatiques, ce que tu cherches à faire ressemble à ce qui est décrit sur cette page :
http://qt-project.org/wiki/How_to_create_columns_in_a_QML_ListView

Qml est vraiment bien pensé, je ne lui reproche que le positionnement des objets qui est souvent hasardeux, plusieurs modèles sont proposés pour places les éléments et c'est difficile au moins au début de les utiliser correctement.

"Hasardeux" ?

Je trouve au contraire que le système de positionnement est une grande force de QML car il est d'une souplesse Jean-Claude Van Dammienne.
On peut utiliser du positionnement absolu, relatif (par rapport à d'autres composants), ou bien du layouting plus "classique" (en colonne, en grille, etc).
Après, si tu veux dire qu'on est un peu perdu au début, je peux te rejoindre là dessus, mais je ne connais aucun autre environnement qui me permette de positionner mes éléments aussi facilement que je le fais en QML.

C'est justement l'ironie du sort, le problème n'existe pas pour ceux qui utilisent massivement les onglets, mais seulement pour ceux comme moi qui de temps en temps, ont des onglets avec une largeur assez petite pour que la croix occupe assez de place pour que mes doigts maladroit cliquent sur la croix au lieu de cliquer sur l'icône et le texte.
Et puis je pense que le fait que je n'utilise JAMAIS cette croix devrait être une raison suffisante pour ne pas vouloir la voir afficher sur mon navigateur.

Y'a un moment faut se demander pourquoi j'ai toute cette merde étalée en permanence. M'enfin chacun fait ce qu'il veut…

Je n'ai même pas envie de rentrer dans le débat mais je pense que vous êtes aveuglés par votre conception relativement étriquée de l'utilisation d'un navigateur et qu'il vous est difficile de concevoir les cas "raisonnables" où on utilise assez d'onglets pour que la présence de la croix de fermeture devienne un problème, en particulier pour des doigts un peu boudinés et à la précision de clic relative :)

Si le problème ne se pose pas pour une workload "raisonnable" pourquoi s'embeter à ajouter ca ?

Je pense pas qu'il s'agisse d'un soucis de réalisation, ça serait probablement trivial à ajouter.
Non, pour moi, c'est un choix de "charte ergonomique", à la gnome. Probablement basée sur la peur que des utilisateurs qui activeraient cette option (que l'on demande bien planquée, même pas dans le panneau de préférences, ou bien juste activable par un plugin) ne sauraient plus ensuite comment fermer leurs onglets, les "pauvres".

c'est peut être un truc plus évolué qu'il faut plutôt que d'essayer de gratter quelques pixels.

C'est pas gratter quelques pixels qui m'intéresse, c'est juste éviter une fois sur 10 de cliquer sur la croix lorsque je veux juste activer un tab en "mode random" (sinon y'a ctrl-tab et ctrl-shift-tab) et devoir ralentir la course de mon curseur souris spécifiquement pour chromium.

J'adore, je pose un commentaire pour soulever un problème technique concomitant à l'utilisation de nombreux onglets et on en vient à me dire que je suis un procrastinateur qui passe son temps sur le web et qui manque de pragmatisme.
Pas de doute, on est bien sur linuxfr :)

ça montre pas plutôt un mauvais pattern consistant à vouloir mener pleins de trucs de front ?

Non, c'est plus de la paresse je crois, ça me fait juste chier de passer du temps à fermer des onglets, ou alors sur le moment, je me dis "j'y reviendrais peut-être plus tard" donc je le laisse ouvert.
Cela dit, peu importe la raison, j'aime bien parler de moi, mais là, on causait surtout de la gestion de la croix de fermeture dans un contexte de plusieurs dizaines d'onglets, peu importe si c'est légitime à vos yeux ou non.

Le problème survient lorsque je veux sélectionner un onglet particulier et que je clique malencontreusement sur la croix car cette saloperie occupe la moitié de l'espace lorsque l'onglet est petit.
Sinon, j'utilise depuis toujours C-w ou bien le clic du bouton du milieu de la souris.
Y'a dans ce navigateur une pile des onglets récemment fermés, ce qui permet de retrouver les onglets fermés par accident mais c'est pas terrible comme workaround :)

Ok, je suis prêt à baisser à 25 :)
Mais sérieusement, au boulot, je suis vraiment vite surchargé d'onglets, en comptant le bug reporter, le code reviewer, etc… après, c'est probablement une mauvaise habitude, je pourrais trouver mieux, mais bon…

Sur Chrome, on se retrouve très rapidement à ne voir que les favicons des onglets car on ne peut plus lire le texte dès qu'on a plusieurs onglets d'ouvert

Et tu oublies cette P***** de croix de fermeture qu'il est impossible de cacher, car l'équipe de Chromium a jugé que c'était pas bien d'offrir la possibilité de le faire, même via une obscure option avancée.
Pour ceux qui utilisent fréquemment plus d'une cinquantaine d'onglets ouverts, c'est absolument abominable, et je conchie ceux qui ont décidé de mettre cette fiche en WontFix.

Attention, QML est "juste" le langage déclaratif, vous voulez parler de QtQuick.
A propos de QML, qbs est un système de build très puissant qui permet de gérer des projets de toute sorte, de la compilation jusqu'au déploiement (contrairement à qmake et cmake, il gère entièrement toute la chaîne de compilation, un peu comme Scons), les fichiers projets sont tous décrits en QML.
Je le recommande chaudement, le principe déclaratif du langage se prête vraiment bien à un système de build, et son expressivité et sa clarté sont un vrai régal.

On dirait que l'arroseur de l'arroseur s'est repris la flotte en pleine tronche ;)

C'est finalement ca la grande difference entre KDE et GNOME. GNOME a ete cree pour copier Windows. Il n'y a jamais eu de volonte d'innover de leur cote.

C'est assez cocasse lorsqu'on se souvent comme moi que les premières versions de KDE étaient clairement inspirées du bureau Windows. Barre en bas, bouton démarrer, boutons des barre de titres des fenêtres similaires, etc.

Je vais pas réussir à dormir avec ça…
Les boulettes entre les doigts de pied au moins, c'était du bio, du naturel, mais là…

Comment c'est fourbe de faire un journal aussi long, pour décourager ceux qui veulent cliquer sur "inutile".
Bin ça a pas marché avec moi, na :)

parce que les utilisateurs sont trop cons pour comprendre la notion de presse-papiers multiples

Je ne pense pas que ce changement est (seulement) motivé par un soucis de simplification vis-à-vis d'une certaine confusion des utilisateurs face au double-clipboard, mais surtout parce qu'historiquement, ces deux presse-papiers n'ont jamais cherché à être unifiés "proprement", ce sont deux outils qui ont été ajoutés comme des couches de glaçage sur un gâteau, et du point de vue ergonomique, c'est assez aberrant, même si pratique pour les vieux cons comme moi qui ont bien intégré leur fonctionnement particulier au fil des années d'utilisation, depuis WindowMaker jusqu'au dernier KDE.
Un véritable presse-papier multiple devrait être plus cohérent et intelligent que cela, on ne devrait pas avoir à se poser la question de "alors, est-ce c'est dans mon presse papier X ou bien celui de mon DE ?", il devrait y avoir les mêmes points d'entrée pour ses invocations (ou bien définir plusieurs points d'entrée simultanés, peu importe).
Par contre, il me paraît évident que ceux qui veulent supprimer le double presse-papier devrait laisser la possibilité de retrouver ce comportement, sinon ça envoi un message bien triste à la base d'utilisateurs actuelle.

J'ai ça dans Archlinux depuis un bon bout de temps maintenant, après une fresh install.
Du coup, ça pose des soucis pour certaines applis qui utilisent le control droit pour des actions particulières (comme déverrouiller le curseur souris capté par une machine virtuelle dans VirtualBox)
J'ai toujours trouvé ça débile, un control droit, c'est un control droit.
Donc, je patch systématiquement à chaque fois que j'installe une archlinux, supaire ! C'est moi qui doit patcher pour retrouver un comportement "normal" et pas ceux qui utilisent Rythmbox.