Christophe Fergeau a écrit 1255 commentaires

A priori mono marche pas trop mal, cf
http://www.gnome.org/projects/f-spot/(...)
http://muine.gooeylinux.org/(...)
par exemple

Le monsieur il s'appelle Robert pour de vrai, tout de suite c'est moins cool comme prénom ;)
http://ometer.com/(...)

En fait, il y a quand même certains trous dans son argumentation, en particulier en ce qui concerne ses interrogations au sujet de .NET et des brevets, comme le souligne MDI par ex ( http://primates.ximian.com/~miguel/all.html#3%2F18%2F04%202%3A00%3A(...) ), Sun a probablement breveté certains bouts des API de Java.

> Ca c'était pour avoir une arborécense.

L'ancien sélecteur de fichier avait pas d'arborescence non plus... Les gens passent leur temps à raler "gnome ca pue, le sélecteur de fichier est pas beau patati patata". Quand le sélecteur de fichier est changé "Ouais, le nouveau sélecteur de fichier pue, il fait pas le café"
En ce qui concerne les filtres, je suis pas sûr du tout que l'ancien sélecteur de fichier les géraient, et le créateur de l'appli peut ajouter un système de filtres pour que l'utilisateur puisse filtrer certains types de fichiers en relation avec l'appli.
Enfin, pour les niveaux d'utilisation, les principaux problèmes sont que c'est a priori super chiant à maintenir parce qu'il y a un des modes que les développeurs testent quasiment jamais, les rapports de bug ça peut être le bordel "oui, ça vous fait ça, mais dans quel mode êtes vous?". Et surtout, t'as les utilisateurs qui voient "mode simplifié/mode normal" ou "mode simplifié/mode expert" ou ce que tu veux, et qui font "mwahaha, on me la fait pas à moi, je suis un pro de l'informatique, je veux tout" et qui au final trouve ça trop compliqué mais ne reviendra jamais au mode normal, donc au final, le mode simplifié n'est quasiment pas utilisé.

- ouvre le répertoire parent

=> alt+fleche du haut (comme dans nautilus 2.5/2.6)
et alt+fleche du bas te remmene dans le répertoire où tu étais

Un des buts du sélecteur de fichier était de cacher l'arborescence autant que possible, d'où l'absence de treeview.

La sélection des fichiers cachés est effectivement un pb, ça me surprendrait pas que ça soit un bug
Par contre, l'entrée de texte cachée, c'est fait exprès, la plupart des utilisateurs ne tapent pas le chemin directement, ils se balladent avec leur souris... D'où l'inutilité d'avoir cette zone de texte...

> En plus, on peut ajouter un effet d'apparition au fur et à mesure (si tu as downloadé un dixieme de l'image tu vois grosso-modo le résultat).

oui, avec le jpeg aussi.

Non, là c'est un nouveau widget, donc une nouvelle api.
L'ancien file selector s'appelait GtkFileSelector, le nouveau s'appelle GtkFileChooser.
La compatibilité source et binaire, ça veut dire que tous les anciens widgets sont encore présent, mais il peut y avoir des nouveaux widgets/nouvelles apis.

« - utilisateur débutant:
Quelle est la différence entre les "dossiers" à gauche, à les "dossiers" à droite ? Quelle est la différence entre "Ajouter" un dossier à gauche et créer un dossier à droite ? »

A mon avis, utilisateur débutant: « c'est quoi ces bidules dans la colonne de gauche ? je sais pas ce que c'est, j'y touche pas, de toute facon mes fichiers ils sont à droite. »

Celui là n'a pas d'existence officielle, ça doit être un patch de Ximian ou de je sais pas qui. Si tu compiles un gtk 2.2 à partir des tarballs, t'auras pas ce fileselector là.

Ouais, je suis d'accord que la boite de dialogue a des bouts plutot pourris (je hais l'espèce de système de boutons pour représenter le chemin en cours), mais la suppression de la zone de texte me paraît être une bonne idée par contre, surtout qu'elle est facilement accessible à ceux qui en ont besoin

« - Comment je vais directement à un endroit sans cliquer sur chaque dossier du chemin ?
J'ai lu: en tapant C-l, mais c'est pas intuitif. »

la motivation principale pour ce ctrl+l planqué, c'est probablement que d'une manière générale, les gens s'en foutent de taper un chemin, mais qu'il y aura quand meme des personnes pour raler (très fort), donc on file un moyen de taper le chemin sans encombrer l'interface.

Je suis 100% d'accord avec toi, mais pour moi une "image à palette" est un truc bien spécifique qui consiste à ne pas coder un pixel en donnant ses composantes RGB, mais en donnant un index dans une palette qui elle contient les descriptions RGB. Et dans le cas des captures d'écran, c'est plutôt hors sujet de parler de ça.

Opera plutot

> les images à palette

dans le monde d'aujourd'hui, la plupart des ordis utilisent un mode d'affichage 24bits tu sais, les modes graphiques basés sur des palettes ça doit faire qques années que plus personne utilise ça sur ses machines de bureau ;)

Les captures sont du gnome 2.6/gtk 2.4 (les versions de gnome et gtk sont pas synchronisées)

Le dialogue n'est pas modifié, c'est un petit popup qui s'ouvre

Si tu veux taper un nom de fichier, t'as déjà les doigts sur le clavier, donc le temps de taper ctrl+l est négligeable à mon avis. Pour savoir si y amoyen de toujours l'afficher, faudrait regarder dans l'api doc du gtkfilechooser

ctrl+l ouvre une entrée de texte où tu peux taper le nom du fichier

GNOME2 ou Gimp 2 ? Pour gnome2, la réponse est oui, il est utilisé, pour gimp2 j'en sais rien

Donc on compte en nb de société ? Plus il y a de société, plus le projet obtient de contributions ? Dans ce cas, c'est vraiment des branleurs chez GNOME, y a aussi HP et IBM à la GNOME foundation il me semble, faudrait les compter hein...

KDE: Trolltech (40 employés)
GNOME: Sun (1 employé, sinon peu de contribs en dehors de traductions), Ximian (qques employés (1 ou deux) bossant vraiment sur GNOME, le reste bosse evolution, redcarpet, ...), RedHat (qques employés bossant sur GTK+, qques autres sur GNOME), SuSE (rien pour l'instant)

Les chiffres que je donne sont plus ou moins fantaisistes, et probablement inexacts, c'est juste pour souligner que c'est pas comme si y avait des dizaines de personne dans chaque boite payées pour bosser sur GNOME.

> C'est plutot que quand je vois des gens qui soutiennent Gnome, je me ressens le besoin de les informer d'une part sur les problemes de Gnome, d'autre part sur l'interet de KDE. Je le fais de facon plus ou moins objective, en avancant en tout cas des arguments que je juge valide. Et meme plus le temps passe, plus mes arguments se verifient.


Joli.....
Tes "arguments" sont un mélange d'arguments valides, d'arguments acceptables (ie on n'est pas forcément d'accord avec, mais le point de vue est défendable) le tout mélangé avec du FUD ou de la désinformation.
Personnellement, pour défendre GNOME, bah je réponds aux critiques concernant GNOME, je ne m'aventure pas à critiquer KDE (ou très peu), ça m'évite de dire n'importe quoi, et surtout c'est pas très productif de raconter tout et n'importe quoi pour montrer que "chez nous c'est bien, les autres c'est des nuls". Si t'aime pas GNOME, tant mieux pour toi, merci de rester dans ton coin et de pas raconter n'importe quoi. En fait je crois que c'est ce qui me saoule le plus chez KDE, c'est les gars qui peuvent pas s'empêcher de critiquer GNOME, et de critiquer le soutien de Ximian et RedHat et tout ça. De mon côté, je préfère soutenir GNOME, et laisser les gars de chez KDE tranquille (ie pas les agresser inutilement), c'est plus productif.

Et donc QT ça compte pas non plus ? C'est une petite lib toute pourrie que KDE utilise à peine, donc ça sert à rien de compter les devels qui bossent dessus à temps plein, c'est ça ?

>Redhat livrant majoritairement aux americains, il s'en foutent un peu des accents et des conneries comme ca

Pas sûr ça, ils ont quand même payé Owen pendant très longtemps pour bosser sur Pango dont le seul but est de pouvoir afficher correctement du texte dans n'importe quel langage.