liberforce a écrit 4744 commentaires

Répétez après moi :
http://sensmotdire.gnunux.info/resserrer.html

Ah, j'ai pas entendu parler de ça ? Tu as un lien à me donner ? C'est une info de la desktop-devel-list ?

Parce qu'il faudrai alors remplacer "Fermer sans enregistrer" par "Ne pas enregistrer puis fermer" pour rester cohérent, et là ça devient beaucoup trop long comme formulation...

Alors pourquoi ton amie a gueulé que son texte bavait ? Elle devait bien savoir que ce serait le cas en matriciel... Sinon dans ce cas là, c'est l'article Correspondance_entre_logiciels_ouverts_et_logiciels_propri%E9taires qu'il faut leur faire lire...

où il faut se réjouir. Se réjouir du fait que les décideurs ne sachent pas de quels outils ont besoin leurs équipes ? Du fait qu'ils ne comprennent ni les besoins ni le métier de leurs utilisateurs ? Du fait que les utilisateurs eux mêmes sont incapables de se rendre compte de la différence entre un logiciel de dessin bitmap et un logiciel de dessin vectoriel ?

Ils n'ont pas commencé à travailler à ce moment là, ils devaient bien utiliser des outils avant (InDesign ?), qui eux correspondaient à leur besoin... Et pourtant ils n'ont pas appris quel type de logiciel ils utilisaient. Ça fait quand même peur, moi je vois clairement pas de raison de me réjouir.

Ni les décideurs, ni les utilisateurs n'ont suivi la moindre formation à GIMP, mais la différence entre un le dessin matriciel et le dessin vectoriel c'est quand même la base du graphisme... Et pourtant ils n'ont pas l'air d'avoir été formés à ça non plus.
Alors par pitié pour leurs clients, enjoins les à lire Image_matricielle et Image_vectorielle...

D'ailleurs il y a ce soir un hommage sur la chaîne IDF1. C'est assez spécial...

Franchement, j'y joue pas mal, mais là j'ai trouvé ça clairement abcons. Heureusement que je connais aussi Frets On Fire (FoF), mais je ne connaissais pas FoFiX.
http://en.wikipedia.org/wiki/FoFIX#Frets_on_Fire_X

Au passage, je suis d'accord que Frets On Fire est lent, il me semble que c'était en C à l'origine, et qu'ils l'ont porté en python, mais je ne suis plus sûr... Sur sourceforge, il n'y a plus que du python sur le SVN...

... dans son sketch "Journée d'un fasciste", que je vous enjoins à écouter si vous ne le connaissez pas.

Je ne suis pas un expert, mais il me semble que dès que tu utilises des templates, le compilo doit générer une version de la fonction par type existant dans le programme. Donc si tu as N types et M fonctions utilisant des templates, tu te retrouves avec N * M fonctions générées... En C tu utiliseras du (void *) et tu n'auras donc que M fonctions en tout, mais tu n'auras pas la vérification de type à la compilation...

J'aimerais bien savoir ce qui a justifié ce choix...

On parle des environnements sur le wiki, après, difficile de tout mettre dans l'installateur...
http://wiki.mandriva.com/fr/
http://wiki.mandriva.com/fr/Les_environnements_et_bureaux_de(...)

Ce serait donc :
- "Fermer sans enregistrer" et "Fermer en enregistrant"
ou bien :
- "Ne pas enregistrer et fermer" et "Enregistrer et fermer"
Il y a aussi
- "Ne pas enregistrer" et "Enregistrer"
sachant
Le premier est pas mal, mais j'ai peur que la formulation un peu trop proche soit trop confuse pour l'utilisateur.
Le deuxième, afin de conserver l'ordre des opérations est un peu long.
Le troisième prend le parti de ne pas parler de fermeture, sachant que ce n'est pas l'opération critique, et qu'elle est évoquée dans le texte de la boite de dialogue...

Je n'ai pas réussi à trouver de doublon pour ce problème dans le bugzilla, mais il y a beaucoup de bugs/demandes d'évolution... Allez y si le coeur vous en dit, vous avez ma bénédiction pour l'ouvrir et poster ici l'URL (histoire d'éviter les doublons) :-)
http://bugzilla.gnome.org

C'est vraiment très productif, comme si c'était pas pas déjà assez le bordel...

Ah, j'oubliais, je ne me fais aucune illusion pour ce cycle, le boulot qui va être fait doit viser la 2010.1. Et d'ailleurs, les XXXX.1 ne sont elles pas toujours meilleures chez Mandriva ? Ça nous fera une occasion de plus de le confirmer.

Ce n'est pas aux idées de venir à Mandriva, c'est à Mandriva de dire sur quoi ils veulent bosser et on leur donnera notre avis... J'ai appris que netprofile était remanié avec ce post de blog également... Une fois que le boulot était terminé. Sans compter que chaque nouveau canal de communication amène encore plus de boulot pour un bénéfice pas franchement perceptible...
Il faut donc se taper :
- les améliorations dans bugzilla
- les requêtes des forums
- les idées pour la nouvelle version sur le wiki
et maintenant les idées sur un nouveau site web, où en allant jeter un coup d'oeil je n'ai pas vu une idée potable... C'était à chaque fois le gars qui s'y prend mal pour faire un truc et te demande quelque chose qui existe déjà dont il n'a pas connaissance, ou ceux qui demandent quelque chose d'irréaliste vu les moyens de la société...

Attention, je ne suis absolument pas contre que tout le monde s'exprime... Seulement plus il y a de gens qui donnent leur avis, et moins ça laisse de temps à ceux qui font vraiment le boulot d'avancer...

Tu stigmatises le cas particulier de gedit, et ton problème n'a absolument rien à voir avec les HIG. Les HIG te disent uniquement d'utiliser des verbes d'action dans le texte des bouttons plutôt que du oui/non, ce que fait gedit. Après, ils ont peut être mal choisi leur intitulé, mais ça n'a rien à voir avec les HIG, juste avec les développeurs de gedit.
http://library.gnome.org/devel/hig-book/stable/controls-butt(...)

Je cite:
Label all buttons with imperative verbs, using header capitalization.

Et toi tu embraies sur Apple qui fait ça mieux alors qu'ils font la même chose... Dis moi, ils montrent des boutons oui/non chez Apple ?

Déjà, position du "Annuler" au milieu, on sait pas trop pourquoi

Il y a aussi celui-ci qui est pas mal : http://developer.apple.com/documentation/UserExperience/Conc(...)

C'est marrant, le même défaut chez Apple ne te gêne plus on dirait. Tes remarques sont déjà plus constructives, mais faudrait rester cohérent. Tes propos ne changent absolument rien à ce que j'ai dit, à savoir, qu'il faut éliminer les boutons oui/non...

Tu demandes de fermer, et il reste du travail non sauvegardé, tu as 4 possibilités:
1. Enregistrer et fermer
2. Enregistrer et ne pas fermer
3. Ne pas enregistrer et ne pas fermer
4. Ne pas enregistrer et fermer

Chez GNOME (mono et multi document):
1. "Enregistrer"
2. Pas de bouton
3. "Annuler"
4. "Fermer sans enregistrer"

Chez Apple (mono document):
http://developer.apple.com/documentation/UserExperience/Conc(...)
1. "Save"
2. Pas de bouton
3. "Cancel"
4. "Don't save"

Chez Apple (multi document):
http://developer.apple.com/documentation/UserExperience/Conc(...)
1. "Review Changes"
2. Pas de bouton
3. "Cancel"
4. "Discard changes"

Vous préférez "Ne pas enregistrer" plutôt que "Fermer sans enregistrer", c'est ça ?

J'avais commencé ça :
http://wiki.mandriva.com/en/Improving_Drakxtools_usability

J'avais commencé un peu à bosser sur l'ergonomie des drakxtools il y a un an, mais si je n'ai aucun signe que ça va changer, est-ce que ça vaut le coup de bosser dans le vide ? En général c'est un peu la dernière roue du carosse, et les dev concernés n'ont pas forcément un sens de l'ergonomie très affûté... Contacte moi si tu veux du monde sur ce sujet, mais il faut la garantie d'un engagement de Mandriva à retranscrire des idées en provenance des groupes de travail, quantitativement. Qu'on regarde ensemble ce qui serait faisable, et qu'ils nous disent "si vous le dégrossissez, on l'implémente". J'avais déjà évoqué le fait qu'on puisse se concentrer sur un drakxtool par release, pour mener de campagnes de lifting... Sauf qu'à chaque fois c'est la même chose : manque de bras chez Mandriva.

Bon, maintenant, au moins tu es prévenu pour la numérotation de version, si tu tiens à ton karma, mieux vaut t'abstenir l'année prochaine ;-)

Ensuite, pousser "une" distrib est une erreur. N'oublions pas qu'il y a des sociétés derrière, et qu'en gros ça revient à faire la fortune d'un nouveau Microsoft et éliminer les autres acteurs du jeu. Ça tue la concurrence, qui reste aussi un moteur du libre. Je ne veux pas d'un nouveau géant à la Microsoft, donc je continue d'encourager ma distribution. Et quand un débutant me demande conseil, je ne l'oriente pas fanatiquement vers Ubuntu et Mandriva, mais je lui cite les 3 plus user-friendly selon moi actuellement : Ubuntu, Mandriva et OpenSuSE. Je conseillais aussi Fedora avant mais ils sont trop orientés nouveauté d'où pas mal de régressions inacceptables pour un novice.

La dispersion n'est pas bonne, il faut sortir quelques acteurs du panier, mais trop de concentration sur un seul acteur tuera certaines sociétés qui vivent du libre et y contribue, ce qui serait pire encore.

Enfin, pour l'ancien système de numérotation, on évite la course aux numéros de version qu'il y a eu pendant quelques années, et au moins le système de date permet de s'y retrouver et d'être plus neutre.

Ce n'est pas pour le défendre, mais tu réponds assez ironiquement, alors qu'il a raison sur certains points. L'outil de 2004, je ne sais pas de quoi il parle, mais je sais que netprofile est connu depuis au moins 2004 pour faire n'importe quoi dans certaines conditions. Il m'a flingué il y a encore 1 an ½ une configuration réseau que j'ai été incapable de restaurer après une après midi de lutte acharnée -> réinstallation complète. netprofile a néanmoins continué d'être livré, et n'a pas été corrigé.

Dasn ces cas là, oui, il vaut mieux ne pas livrer un composant que de livrer un truc bogué jusqu'à l'os. Mandriva l'admet elle même en annonçant une refonte de netprofile, comme si c'était une feature alors que ça fait 4 ans que le truc moisit. Je vais pas leur dire que c'est génial qu'il refassent netprofile maintenant, j'aurais plutôt tendance à leur demander pourquoi ils n'ont rien fait les 4 années précédentes...

Après, nous sommes d'accord que la mauvaise image que Mandriva pouvait trainer, elle est finie depuis un bon moment pour moi (plusieurs années), le plus gros point noir ayant été le manque de dialogue avec la communauté. La direction a changé et fait des promesses, ça commence à bouger, il y a un peu d'inertie, mais globalement, depuis deux bonnes années on va largement dans le bon sens.

Tout à fait, l'idée d'origine des fondateurs, c'est de fournir une RedHat avec KDE...

La One GNOME n'a que GNOME, logique qu'elle mette GNOME par défaut. Moi j'installe la Free, et devine ce qui est coché par défaut ? KDE...

Je ne dis pas que c'est le parent pauvre (même si ça a été le cas à une époque), sinon je serais sous Ubuntu, pas Mandriva/GNOME.

Règle n°1: l'utilisateur ne lit pas les messages.

C'est comme ça. Avoir des boutons Oui/Non demande une connaissance du contexte, et la compréhension du contexte. C'est une source majeure d'erreurs, qui peut notamment provoquer de la perte de donnée (question mal comprise). C'est un des trucs les plus énervants dans le monde Windows, et plein d'applications Linux ont encore cette mauvaise habitude (au pif, easytag qui est un summum de ce qu'il ne faut pas faire au niveau IHM).
Les GNOME HIG sont un des meilleurs trucs que j'ai lu au niveau design d'interface et bonnes pratiques. Après, faudrait les mettre un peu plus à jour, mais rien que si les applications implémentaient ses consignes, on aurait un truc super utilisable, autant par les débutants que par les gens expérimentés.

Ce genre de truc m'a suffisamment énervé pour ne plus vouloir de m*rdes pareilles...
http://www.madhumenon.com/images/remove-dll.gif

Si tu as des garanties qu'il y aura des réunions avec le décisionnel chez Mandriva, tu peux compter sur moi pour me joindre à l'équipe et partager des idées et orientations. En revanche, il ne faut pas se disperser, pour justement éviter que tout cela n'aboutisse à rien de concret comme par le passé.