liberforce a écrit 4744 commentaires

Satisfait ? On aurait pu espérer mieux effectivement, mais ça aurait pu être pire. Donc on peut dire qu'on est content.

En même temps, c'est un mètre-étalon. C'est la première année, elle servira de repère pour les années suivantes.

Je pensais que pour un dev, le retour d'expérience utilisateur avait de l'importance.

Il en a. Mais pour un bug ouvert demandant une fonctionnalité, tu en as un autre qui demande l'opposé. Faire un logiciel qui répond à chaque besoin spécifique de chaque individu, c'est faire un logiciel utilisable par personne. Il y a donc forcément un compromis à faire, auquel s'ajoute un compromis technique sur ce qui est faisable (ou pas), maintenable sur le long terme (ou pas), cohérent avec le reste (ou pas).

Est-ce que ceci répond à ta question ?
http://mixeduperic.com/linux/how-to-enable-multiple-language-keyboard-layouts-in-gnome3.html

patrick_g trusts two places in ze top ten!

Si tu veux avoir un journal bien noté chaque semaine, toi aussi, cher linuxfr-ien, trolle sur GNOME 3 !

Arf, oui, j'avais pas les neurones en place quand j'ai écrit ça…

C'est sûr que si ton cas d'utilisation, c'est ouvrir un gros fichier, le fermer, faire autre chose puis le rouvrir plus tard, oui, cela ira plus vite avec plus de RAM. Mais ce scénario n'est peut être pas représentatif de son utilisation de sa machine.

Et comment sais-tu qu'il ne sature pas la RAM?

Je ne le sais pas, pas plus que toi.

Mais le commentaire auquel tu as répondu gère les 2 cas: sans swap (assez de RAM) ou avec swap (pas assez de RAM). Et ton commentaire laisse entendre que même s'il n'en vient pas à taper dans le swap, plus de RAM, c'est mieux. Bin moi je dis que non. Parler de streaming audio ou vidéo n'a aucun sens: c'est sa consommation de RAM qui importe , quelle que soit l'utilisation qui en est faite. S'il consomme plus de ressources qu'il n'est possède, oui, ça peut valoir le coup d'ajouter de la RAM (encore que je suis plutôt du genre à conseiller de virer les trucs inutiles qui en consomment). Mais son système pourrait tout aussi bien être léger mais limité par un processeur poussif, et là, rajouter de la RAM n'aurait aucun effet.

La règle de base de l'optimisation, c'est qu'avant d'optimiser, il faut mesurer.

Ben non, justement. Si pendant ses sessions habituelles il ne sature pas la RAM, en rajouter ne changera rien. Il ne va pas rester 3x plus de temps d'affilée sur son ordi que d'habitude pour saturer son cache et te donner raison…

à quel sein me vouer…

Hum… Galopin, va ! Les saints n'apprécieront pas.

Ceci semble être un détail insignifiant mais ce n'en est pas un car c'est typiquement ce genre de détails qui fait qu'un débutant sous Linux va être de suite à l'aise ou va être désorienté et va préférer un autre système (bon, sous Windows, ce n'est pas mieux).

Est-ce que cela valait un fork ?

J'avais fait cette remarque à l'équipe de traduction française de Gnome 2 qui à l'époque, m'avais expliqué que c'était trop de travail pour modifier cela (documentation à mettre à jour etc.). Par contre, l'équipe de traduction française de MATE est beaucoup plus réceptive. Encore un peu d'efforts et peut-être que Cinnamon en tiendra aussi compte et que le menu par défaut de MATE sera aussi bien traduit que l'applet Barre de menus qui n'est pas installée par défaut.

La base d'utilisateurs n'est pas vraiment la même. L'utilisateur de MATE a dû entendre parler de GNOME (il n'y a à ma connaissance pas de distribution qui fournissent MATE par défaut). L'utilisateur de GNOME n'a pas forcément entendu parler de MATE. Et forcément, sur un projet plus petit, il y a moins d'inertie. Mais à une époque où les possesseurs de smartphone et les médias parlent d'apps, est-ce que la différence sera flagrante ? Tous les tutoriels auraient été rendus un poil obsolètes et déroutants pour les débutants. Je pense comme toi que "Logiciels" est sans doute une meilleure traduction, mais je ne peux pas reprocher qu'un élément aussi proéminent ait été conservé. En revanche, "Applications" a disparu dans GNOME 3.6, remplacé par un bouton grille. Ça bouge un peu dans GNOME aussi…

Plutôt que les gens forkent, ils pourraient tout simplement tenter de contribuer upstream ? Les développeurs GNOME qui maintiennent GNOME n'ont rien contre le rendre vraiment multiplate-forme, mais il faut bien que quelqu'un fasse le boulot, et ils en ont déjà trop. Forker serait idiot. Que ceux qui veulent changer la direction que prend GTK se retroussent les manches et contribuent, tout simplement.

GTK ne peut rester séparé de GNOME que si d'autres gens y contribuent. Or il n'y a que les devs GNOME qui maintiennent GTK. Cette situation me déplait, mais c'est le constat des développeurs GTK. Du coup GTK est lentement en train de devenir le GNOME toolkit plus que le GNU Toolkit. Mais si personne d'autre de des développeurs GNOME n'y met la main, la tendance ne risque pas de s'inverser.

Donc GTK (en C) devrait utiliser Qt (en C++) ? C'est complètement absurde. Si le toolkit n'est plus pertinent, alors autant virer GTK et convertir toutes les applications GNOME à Qt plutôt que de faire les mêmes erreurs que wxWidgets en rajoutant un autre intermédiaire avec ses couches de bugs. Mais vu les projets de GTK (fusion avec Clutter), à mon avis, ce n'est pas demain la veille.

Comme gnome-tweak-tool, dconf-editor et extensions.gnome.org ? Ils ne t'ont pas attendu, tu sais.

Juste que ils détestent le C++.

Ah oui, comme GNote, le portage de Tomboy en C++ ? Comme GTKmm, les bindings C++ pour GTK ?

Pour sa défense, je pense qu'il parle des gens qui critiquent beaucoup mais ne font rien pour faire avancer la résolution des problèmes. C'est un peu comme en politique: si tu veux que ça change, s'engager est plus constructif que passer son temps à râler.

Qt est libre depuis plus de 10 ans. Du coup le projet Gnome a-t-il encore un sens?

Mais Qt n'est LGPL que depuis un peu moins de 4 ans. Et les différents écosystèmes avaient déjà suffisamment évolué pour que les 2 environnements soient pertinents, ne visant pas les mêmes utilisateurs.

L'idée n'est pas fausse, il y a bien ces bindings etc…, cependant y'a quand même un paquet d'applis en C (exemple Nautilus)

Je parlais des logiciels pour lesquels il y a une obligation tacite de les développer en C, en gros, toutes les bibliothèques. Pour les applications, il n'y a aucune obligation, les développeurs utilisent ce qu'ils veulent, y compris le C s'ils le souhaitent.

C'est complètement faux, les applications des premières versions de GNOME utilisaient quantité de langages différents, et GNOME a toujours été agnostique du point de vue du du langage. Même le C# a été utilisé dans Tomboy. Il n'y a que les couches basses qui sont en C, afin de pouvoir générer des bindings vers d'autres langages plus facilement. Ce qui ressemblerait le plus au langage de GNOME serait Vala, mais il est encore loin de faire l'unanimité.

KDE et Trolltech ont aussi été contactés pour régler le problème de la licence de Qt a l'époque, et cela n'a débouché sur rien. C'est de là qu'est parti GNOME.

J'en profite pour laisser un lien (que j'ai dû trouver sur linuxfr dans le "en vrac" si ça se trouve) sur des algorithmes de sélection de couleurs.

Hum… Pourquoi pas. Faudra que je voie à l'usage.

Je retire aussi ce que j'ai dit sur le copier/déplacer, on dirait plutôt qu'il a amélioré l'existant. C'est dans 3.4 que j'ai a des sous-menus dans "Déplacer vers" ou "Copier vers". Dans les captures de 3.6, on voit des points de suspension au lieu d'un sous menu, ce qui signifie qu'une nouvelle boîte de dialogue serait ouverte, ce qui serait une amélioration. Toi qui utilises la 3.6, tu peut confirmer ?

J'ai pensé aux menus d'Ubuntu. Je n'ai pas encore pu mettre la main sur GNOME 3.6, et dans la 3.4, les GMenu n'ont qu'un menu quitter pour quasiment toutes les applications. Du coup je ne suis pas encore habitué à les utiliser.

Je suis à -1 sur mon commentaire précédent qui a l'air complètement partial, mais reprendre toutes les approximations d'un article de 14 pages, je ne vais pas faire ça dans un commentaire…

Mc Cann est un développeur et l'un des designers. Si on prend cet exemple en particulier, on peut facilement en déduire que c'est un enfoiré. Mais même en « off » chez GNOME, c'est quelqu'un de controversé. La technique par exemple du « je vire plein de trucs dans nautilus , les gens gueulent, je blogue pour leur dire que c'est pour leur bien », m'énerve au plus haut point. Je suis beaucoup plus proche de l'avis de Federico Mena Quintero, co-fondateur de GNOME, qui pense que les explications doivent venir avant, et qu'il faut plus être à l'écoute de l'utilisateur. Mc Cann est relativement obtus sur pas mal de choses. Il y a des choses qu'il fait qui sont nécessaires, et compréhensibles, d'autres que je trouve tout bonnement ridicules. Exemple: dans Nautilus il a retiré plein de choix du menu contextuel (bien, moins de bordel), pour en rajouter des obscurs et qui correspondent à un worflow complètement parachuté (créer un dossier et le remplir avec les fichiers de la sélection, ou copier/déplacer des fichier vers des dossiers prédéfinis, mais non personnalisables actuellement).

Mc Cann a de l'importance et du poids dans GNOME, mais il ne faut pas réduire GNOME à Mc Cann.

Je suis tout à fait d'accord avec toi qu'une appli comme Transmission n'a pas à choisir son « camp ». C'est une appli GTK multi-plateforme, pas une application GNOME. Elle n'est même pas hébergée sur gnome.org.

Tu confonds pas avec les menus déportés d'Ubuntu là ? Parce que je ne vois aucun menu déporté dans GNOME 3…