Tel semble être l'opinion de Linus Torvalds .
http://mail.gnome.org/archives/usability/2005-December/msg00(...)
No. I've talked to people, and often your "fixes" are actually removing
capabilities that you had, because they were "too confusing to the user".
That's _not_ like any other open source project I know about. Gnome seems
to be developed by interface nazis, where consistently the excuse for not
doign something is not "it's too complicated to do", but "it would confuse
users".
# LOL !
Posté par blenderman . Évalué à -10.
Gnome c'est de la merde ! Vive KDE !!!
[^] # Re: LOL !
Posté par Xavier Maillard . Évalué à 3.
J'aimerais qu'on aille dire ça à ma mère qui ne s'en sortait pas avec KDE et qui revit avec Gnome.
P.S: je n'utilise pas gnome mais des choses plus exotiques comme Ion, stumpwm et eclipse wm...
[^] # Re: LOL !
Posté par Ramón Perez (site web personnel) . Évalué à 5.
Tu crois vraiment que linux est intelligent à ce point ?
[^] # Re: LOL !
Posté par Xavier Maillard . Évalué à -10.
[^] # Re: LOL !
Posté par Libre (site web personnel, Mastodon) . Évalué à 10.
Il préferait certainemnt des arguments plus technique qu'un simple l'utilisateur va "être perdu"
Y.
[^] # Re: LOL !
Posté par Pascal Terjan (site web personnel) . Évalué à 3.
Je ne vois pas pourquoi il faudrait des arguments techniques dans une discussion de design d'interface. Le fait que l'interface soit agréable à utiliser est pour moi le meilleur argument dans ce genre de choix, et je me fous de savoir que c'est difficile à coder.
[^] # Re: LOL !
Posté par Anonyme . Évalué à 10.
Ce que dit Torvalds n'est pas vraiment qu'il préfèrerait une réponse technique mais qu'il préfèrerait une réponse de gestion de projet, du genre : 'on ne fait pas ça car on n'a pas les moyens actuellement de se permettre d'offrir ce niveau de fonctionnalité de manière propre et correcte', plutôt qu'un 'on ne fait pas ça parce qu'il n'est pas possible de rendre ceci intelligible à l'utilisateur'. D'où la critique de fond : si vous prenez vos utilisateurs pour des idiots, vous n'aurez que des idiots comme utilisateurs.
[^] # Re: LOL !
Posté par Pascal Terjan (site web personnel) . Évalué à 8.
Je suis d'accord que c'est un peu facile de dire qu'on ne le met pas pour ne pas complexifier l'interface mais ce n'est pas ce que je comprenais le mail de Linus.
En fait j'avais lu le premier ou il parlait de prendre les utilisateurs pour des idiots et c'est dans cet esprit que j'avais lu le deuxième. J'avais compris que pour lui c'est une excuse utilisée quand la fonctionnalité est difficile à implémenter, alors qu'en fait il dit bien qu'elle est utilisée quand la fonctionnalité est difficile à faire apparaitre dans l'interface donc je suis plutôt d'accord.
# Fonctionnalités vs. simplicité
Posté par Vincent Richard (site web personnel) . Évalué à 10.
Dans ce cas, il semblerait qu'un développeur se range derrière un "ça va être trop compliqué pour l'utilisateur" plutôt que de repenser l'interface (parfois un gros travail) pour intégrer une fonctionnalité.
Bref, si quelqu'un a mieux compris que moi, merci de m'éclairer !
[^] # Re: Fonctionnalités vs. simplicité
Posté par blenderman . Évalué à -10.
par cet article, Linus a tout simplement voulu dire qu'il n'utilisai pas gnome ...
(Attention je n'ai pas dis qu'il utilisai KDE hein !)
LOL !
[^] # [HS] Re: Fonctionnalités vs. simplicité
Posté par Julien CARTIGNY (site web personnel) . Évalué à 9.
[^] # Re: [HS] Re: Fonctionnalités vs. simplicité
Posté par Anonyme . Évalué à 5.
[^] # Re: [HS] Re: Fonctionnalités vs. simplicité
Posté par Samuel Verschelde (site web personnel) . Évalué à 3.
Ok, ----------------->[]
[^] # Re: Fonctionnalités vs. simplicité
Posté par ndesmoul . Évalué à 6.
I personally just encourage people to switch to KDE.
This "users are idiots, and are confused by functionality" mentality of
Gnome is a disease. If you think your users are idiots, only idiots will
use it. I don't use Gnome, because in striving to be simple, it has long
since reached the point where it simply doesn't do what I need it to do.
Please, just tell people to use KDE.
Linus
Hum..., manifestement il utilise KDE...
Oh, un troll KDE contre Gnome. Ca faisait longtemps ;)
Ceci dit je suis assez d'accord avec ce qu'il dit.
# Re: ...
Posté par Olivier Serve (site web personnel) . Évalué à 9.
Exemple : la boîte de sélection de fichier GTK (utilisée dans Gnome et Firefox au moins) ne présente aucun champ d'entrée de texte. Du coup plutôt que de taper un chemin que je connais, je dois passer par l'énumération de tout /usr/bin pour enfin le trouver. Et je redoute ce moment car c'est looooooooooooonnnnnnng.
Ah, il paraît qu'on peut aussi taper '/' puis le chemin qu'on veut. Ah bon. C'est vrai que c'est bien explicité dans l'interface ça. Un newbie le trouve tout de suite, c'est évident.
C'est pareil pour la navigation 'spatiale' il y a un certain nombre de combinaisons cachées permettant de jouer avec Nautilus dans différentes apparence. Mais si on ne les connais pas, on n'a aucune chance de les trouver.
Si Gnome en est réduit à cacher des fonctionalités basiques de cette manière, c'est quand même qu'il y a un problème, non ?
Même Emacs est plus parlant, c'est dire.
[^] # Re: ...
Posté par Lol Zimmerli (site web personnel, Mastodon) . Évalué à 8.
On pourrait aussi citer le WM qui, pour autant que je sache, ne peut plus du tout afficher les coordonnées XY d'une fenêtre lors d'un déplacement/redimensionnement.
Pfff...
La gelée de coings est une chose à ne pas avaler de travers.
[^] # Re: ...
Posté par el_mickey . Évalué à 4.
[^] # Re: ...
Posté par B16F4RV4RD1N . Évalué à 2.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 8.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ...
Posté par Anonyme . Évalué à -5.
[^] # Re: ...
Posté par el_mickey . Évalué à -1.
[^] # Re: ...
Posté par Anonyme . Évalué à 3.
[^] # Re: ...
Posté par romain . Évalué à 7.
[^] # Re: ...
Posté par Anonyme . Évalué à 6.
[^] # Re: ...
Posté par Miair Patreau . Évalué à 7.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ...
Posté par romain . Évalué à 1.
Un site comme http://www.lemonde.fr/ ne l'est pas.
Et sans vouloir passer pour un maniaque du détail (ce que j'assume parfaitement par ailleurs), ça fait quand même une sacré différence.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ...
Posté par romain . Évalué à 1.
Même sans aller jusqu'aux petits détails, ils sont bien différents. Le centrage est totalement anecdotique par rapport au reste (sens de la lecture, charges et découpages du contenu, des visuels, mise en valeur et respect des alignements, des chartes couleurs et typos, plugins qui ne s'affichent pas bien). Ce sont des _détails_, plus ou moins gros ; justement, ça compte.
Je pensais justement "pour le fun" introduire un test de ce genre pour mes entretiens de stagiaires, histoire d'avoir une idée de la perspicacité graphique de la bête ; ben une réponse comme ça, juste sur le centrage pour deux sites comme ça, ça me donnera pas envie...
C'est une question de point de vue : moi ça me va très bien.
Lorsque j'ouvre mon journal (papier), ça ne me chagrine pas de voir qu'il n'occupe qu'1/10 de ma table ; quelque part, ça m'arrange, même : j'ai d'autres choses sur ma table.
C'est pareil pour mon écran d'ordinateur : c'est un espace de travail, et une page web n'en occupe qu'une partie, permettant d'avoir d'autres choses à côté.
[^] # Re: ...
Posté par pap . Évalué à 7.
J'ai comme l'impression que ton argument va en l'encontre de ce que tu veux démontrer.
Avec un site au pixel près, on t'impose une dimension pour le site. Alors que si tu veux pouvoir gérer ton bureau virtuel comme tu l'entends, tu redimensionnes la fenetre de ton navigateur et c'est donc l'autre site qui s'en sort le mieux.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ...
Posté par Juke (site web personnel) . Évalué à 1.
donc quand on reduit trop, le texte "deborde des cadres.
[^] # Re: ...
Posté par gnujsa . Évalué à 1.
Un site comme http://www.fr.capgemini.com/ est au pixel près.
Un site comme http://www.lemonde.fr/ ne l'est pas.
»
Euh ...
$ GET http://www.lemonde.fr/ | grep 'width='| sed -r s/.*(width="?[0-9]+"?).*/\1/g' | wc -l
83
De toute façon, à faible résolution, ils s'affichent mal aussi bien l'un que l'autre. De plus ils ne contiennent pas du tout la même quantité d'information. Et c'est assez facile de faire un site clair et aèré quant il contient pas trop d'infos. Maintenant le monde.fr est une horreur qu'il soit au pixel prés ou pas (et d'ailleurs, il est au pixel prés)
[^] # Re: ...
Posté par Xavier Maillard . Évalué à 0.
Emacs => OS, bon à tout faire (et à très bien le faire)
Gnome => simple gestionnaire de bureau/fenêtres
;)
=> []
[^] # Re: ...
Posté par Anonyme . Évalué à 2.
Non je rigole, j'aime bien emacs :)
[^] # Re: ...
Posté par Ontologia (site web personnel) . Évalué à 7.
Elle commence par faire ramer la machine lorsqu'on l'utilise la première fois, surtout sous Firefox, qui fige pedant une minute chez moi.
Je plussois quand aux défauts ci-dessus décrits.
C'est l'impression que m'a toujours laissé Gnome : beaucoup de choses intéressantes mais des partis pris très étranges
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: ...
Posté par ccomb (site web personnel) . Évalué à -10.
je pense que, à part peut-être Torvalds, tous les gens qui critiquent Gnome pour son ergonomie et qui ne jurent que par KDE, sont des drogués de Windows qui n'utilisent KDE que parce qu'ils y ont retrouvé globablement la même chose que sous Windows.
(alors c'est pas de la relance de troll, ça ?)
[^] # Re: ...
Posté par Anonyme . Évalué à 6.
Pourquoi faire deux poids et deux mesures ?
« sont des drogués de Windows qui n'utilisent KDE que parce qu'ils y ont retrouvé globablement la même chose que sous Windows. »
Vu que la conclusion de cette discussion de la part d'un développeur de GNOME est que le but de GNOME est de plaire au 99.9 % des utilisateurs de PC qui s'en tapent des PC, si tu vois juste, on peut se dire qu'à ce moment là GNOME devrait faire comme KDE.
Puisque l'environnement de bureau informatique qui marche le mieux à l'heure actuelle, ça reste Windows, non ? Pourquoi penser que ces 99.9 % d'utilisateurs vont s'amuser à changer de système pour ne pas y retrouver ce qu'ils utilisaient ?
[^] # Re: ...
Posté par Yusei (Mastodon) . Évalué à 3.
Et après s'être dit ça, on peut se demander à quoi ça servirait que les deux leaders du desktop libre choisissent d'aller dans la même direction...
[^] # Re: ...
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à -2.
Non, c'est parce qu'on peut faire plus avec kde qu'avec windows et osx réunis, alors qu'avec Gnome, on est encore plus bridé que windows et osx réunis
Explique moi par exemple comme mettre la barre d'application en haut du bureau (comme OSX, pas windows hein...) sous gnome?
</troll>
[^] # Re: ...
Posté par PachaFonk . Évalué à -3.
Tu as du essayer longtemps....
Sinon, si c'est une vrai question .... clic droit... Propriétés...
Installes gnome, essayes et tu me diras si ça a marché !
[^] # Re: ...
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 2.
[^] # Re: ...
Posté par Anonyme . Évalué à 1.
[^] # Re: ...
Posté par Anonyme . Évalué à 2.
[^] # Re: ...
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 2.
Ce que je pense vraiment, et sans balises cette fois, c'est que cette guerre kde-gnome est ridicule, qu'elle concerne d'ailleur plus les utilisateurs que les développeurs de ces 2 desktop (et tant mieux), et qu'il est tout a fait légitime d'avoir différents bureau avec différentes philosophies, a partir du moment ou il existe des standards / espaces de collaboration comme freedesktop pour les souches techniques qui ne concerne pas les utilisateurs (communication inter application, nommage des icones, ....).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ...
Posté par B16F4RV4RD1N . Évalué à 2.
pas besoin d'avoir le 'couper/coller' dans l'explorateur de documents (finder), en plus c'est pas logique dans la logique de la pomme, et cela risque de perturber l'utilisateur (sans compter que si on 'coupe' des fichiers et qu'il y a une coupure de courant à ce moment, les fichiers sont complètement perdus à tout jamais dans les terribles abysses du néant insondable... (par exemple on ne peut pas imaginer qu'un système unix lorsqu'il déplace les fichiers copie avant, et efface près))"
heureusement, on peut encore customiser OSX : on peut choisir entre les boutons rouge jaune vert, ou alors tout "graphite" (gris)
bref, c'est bien(tm) lorsque c'est le système qui nous dit comment on DOIT travailler, cela évite de trop se casser la tête
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: ...
Posté par liberforce (site web personnel) . Évalué à 5.
Problème réglé depuis octobre par Federico Mena Quintero dans "Profiling the file chooser"
http://primates.ximian.com/%7Efederico/news-2005-09.html#gtk(...)
GNOME s'est réellement orienté vers l'optimisation de l'existant http://live.gnome.org/GnomePerformance depuis septembre et la présentation "Making GNOME Fast" de Federico... La mailing list "performance" a été créée, et est assez active....
Plus d'infos sur http://live.gnome.org/GnomePerformance
[^] # Re: ...
Posté par SF . Évalué à 10.
[^] # Re: ...
Posté par Yusei (Mastodon) . Évalué à 9.
Si on part du principe que toutes les fonctionnalités doivent être visibles, c'est sûr que la politique de Gnome semble étrange. Eux partent du principe que les fonctionnalités pour utilisateurs avancés doivent être suffisamment cachées pour ne pas troubler l'utilisateur qui s'en fout.
Qualifier la possibilité de taper le chemin d'un fichier de "fonction pour utilisateurs avancés" peut sembler bizarre, mais quand je vois les autres membres de ma famille utiliser un ordinateur, je me dit que ce n'est peut être pas si idiot que ça.
(Disclaimer: j'avoue que je suis plutôt à l'aise avec les réglages par défaut de Gnome, à part pour metacity. Et que le gestionnaire de fichiers qui me déplaisait commence à me plaire maintenant qu'ils corrigent les bugs)
[^] # Re: ...
Posté par Anonyme . Évalué à 7.
C'est un peu cela le problème de fond. En visant le grand public, GNOME devient absolument inadapté au reste des utilisateurs.
Moi je rebondi sur un truc que je pense depuis des années : lorsqu'un type ouvre une session dans KDM ou GDM, il devrait pouvoir choisir "simple" / "complexe" comme niveau d'utilisation, et tout découlerait de là. Toutes les options complexes seraient dissimulées aux premiers et visibles au second.
Ca ne couterait pas grand chose et ça ferait des environnement de travail un truc correct pour les utilisateurs de base, qui serait par défaut dépouillé avec des paramètres par défauts intelligents, et un truc qui ne laisse pas sur sa faim les autres.
Mais pour l'instant, on navigue entre les deux extrêmes, entre GNOME où il n'y a plus rien et KDE où je me demande toujours pourquoi on me parle de "Sony Vaio" et de "Thinkpad IBM" quand je configure mon PC alors que ce n'est pas un portable... (exemples de base, mais il y en a plein ; et oui, j'ai déjà signalé ceci comme anomalie, je ne me suis pas contenté de critiquer cela dans mon coin).
Et pour l'instant, comme Torvalds, évidemment je recommende KDE parce qu'il est vraiment trop facile d'être insatisfait par GNOME, alors que KDE est tout à fait correct par défaut (même si ça devient compliqué dès lors qu'on configure).
[^] # Re: ...
Posté par Yusei (Mastodon) . Évalué à 5.
Mince alors, je fais partie du grand public. Ça y est, je suis déprimé pour la journée.
C'est un peu fatiguant cette habitude de généraliser: je suis un power-user, Gnome ne me plait pas, donc Gnome ne plait à personne sauf aux débutants.
Dans une certaine mesure, c'est ce qu'essaye de faire Gnome. Les options avancées sont (parfois) là, mais cachées. Certes, ce que tu proposes serait mieux, mais Gnome a déjà du mal à faire son interface "simple", alors je doute qu'ils s'amusent à faire une deuxième interface plus commplexe avant un moment.
Ils avaient déjà essayé ce genre de choses avec Nautilus, d'ailleurs, mais ça n'avait pas eu de succès (probablement parce que Nautilus était une grosse boue à l'époque).
[^] # Re: ...
Posté par Erwan . Évalué à 9.
[^] # Re: ...
Posté par Anonyme . Évalué à 2.
Une interface graphique peut être aussi pratique (si ce n'est plus) qu'une vulgaire ligne de commande. C'est juste que beaucoup de programmeurs Unix et Linux ont la flemme de perdre du temps à en développer qui tiennent la route.
[^] # Re: ...
Posté par ccomb (site web personnel) . Évalué à 5.
C'est vraiment n'importe quoi cette affirmation.
La ligne de commande n'est pas figée comme l'est une interface graphique. Le plus simple argument pour le prouver est que la ligne de commande te donne directement accès à de la programmation, et donc à des tâches qui, soit n'existent pas avec une interface graphique, soit doivent être explicitement pensées, et donc forcément limitées.
Si elle existe encore et qu'elle est très utilisée, c'est bien qu'elle est réellement plus puissante et plus pratique dans la plupart des cas.
Sous Windows elle n'est pas utilisée parce qu'elle est minable. Le terminal DOS est une bouse inutilisable. Mais même avec cette qualité, elle reste utilisée : il suffit de consulter des docs sur Active Directory ou Windows Server, pour s'en convaincre.
[^] # Re: ...
Posté par Anonyme . Évalué à 0.
Moi je soutiens que n'importe quelle application graphique peut te donner directement accès à ses fonctions (dcop sous KDE par exemple), au même titre que tu y as accès en ligne de commande. Je ne vois pas ce qui pourrais fonctionner en ligne de commande mais pas avec une interface graphique.
C'est juste une question de programmation, à savoir si le programmeur a envie de s'emmerder à prévoir une api de communication avec son interface graphique ou pas.
Quand à la ligne de commande, si elle est de moins en moins utilisée, c'est parce qu'elle n'est pas aussi pratique qu'on veut bien le faire croire, et plutôt hors de portée du débutant, en plus d'être anti-ergonomique. Ce n'est pas parce qu'on en trouve encore quelques restes sous Windows et qu'elle est encore partiellement d'actualité sur Linux que ce sera encore le cas dans 10 ou 20 ans. L'évolution actuelle semble montrer qu'au contraire, tout va vers son éradication, pour le plus grand bien de tous (excepté peut-être les dinosaures qui n'ont pas envie de changer leurs habitudes).
[^] # Re: ...
Posté par gnumdk (site web personnel) . Évalué à 1.
Tu vis dans quel monde, l'erradication de la ligne de commande, mais faut que tu sorte ta tete de ton cul quand meme ;)
Si tu veux une info, le prochain windows server aura une install serveur sans interface graphique donc il semble que meme Microsoft se réoriente vers la ligne de commande...
Et dire que la ligne de commande est moins pratique qu'une interface graphique montre que tu n'y comprends pas grand chose et que il est clair que quand on ne prend pas la peine de savoir s'en servir, on trouve ca nul.
[^] # Re: ...
Posté par Anonyme . Évalué à 7.
Il ne parle pas de l'éradiquer, il dit juste qu'elle n'est pas forcément si ultime que ça.
Franchement, quand je grave un CD, je préfère faire 3 clicks avec k3b que lire le man de cdrecord. C'est grave ?
La ligne de commande prend son sens dans des activités régulières. Mais pour beaucoup d'autres trucs, c'est tellement plus simple d'utiliser une interface graphique qu'il serait idiot de s'en priver.
En franchement, naviguer dans des dossiers avec des photos, moi je préfère le faire avec konqueror qu'avec aterm... Ben ouais, dans un cas je vois les images directement.
« Si tu veux une info, le prochain windows server aura une install serveur sans interface graphique donc il semble que meme Microsoft se réoriente vers la ligne de commande... »
Un serveur graphique ne sert à rien sur la plupart des serveurs. Ca n'a rien à voir avec le sujet du jour.
[^] # Re: ...
Posté par Bapt (site web personnel) . Évalué à 1.
Moi je préfère taper "grave monfichier.iso" ou grave est un alias vers cdrecord et toutes mes options qui vont bien.
Si ce n'est pas une iso je mets mes fichiers a graver dans un dossier et "mkiso" ou mkiso est une fonction zsh faite par mes petites mains avec un wizard qui me pose 1 question : nom de mon iso.
bref pour un CD data : mkiso puis grave moniso (plus simple que k3b non ?)
PS : j'ai plein de fonction pour les autres besoins de gravure...
La ligne de commande c'est ce qu'il y a de plus rapide quand on sait s'en servir et que l'on se fait un petit peu chier. Maintenant les GUI c'est très bien aussi quand on ve faire plein de chose sans se faire chier, mais c'est souvent (pas toujours) plus lent.
[^] # Re: ...
Posté par Anonyme . Évalué à 6.
La ligne de commande à un coût d'apprentissage très important par rapport à l'interface graphique.
Je grave 3 CD par an. C'est donc certain que le temps que je perds avec l'interface graphique est ridicule par rapport au temps que me prendrait la lecture des man.
Je pense qu'il y a énormement de choses que l'on fait irrégulièrement, pour lesquelles une interface est très bien.
Et pour un public non-geek, c'est clair qu'idéalement tout devrait se faire par une interface.
Moi je fais des scripts pour tout ce que j'ai à faire régulièrement. Demander à un non-geek de faire de même n'a pas grand sens. Le temps d'apprentissage serait démentiel (manque de motivation = coefficient multiplicateur ahurissant). Pour autant, le non-geek peut avoir envie d'automatiser certaines actions...
Supprimer la ligne de commande n'est pas une bonne idée. La rendre absolument pas nécessaire oui.
La ligne de commande ne devrait jamais être nécessaire et toujours disponible.
[^] # Re: ...
Posté par Juke (site web personnel) . Évalué à 1.
Moi j'aimerais pouvoir le faire avec les 2, un peu comme viewglob
http://viewglob.sourceforge.net/index.html
[^] # Re: ...
Posté par Anonyme . Évalué à 2.
Tu peux aussi installer la nouvelle version de gnu-ls avec preview des images et videos. Bon, c'est vrai t'as une excuse, elle existe pas encore cette version (enfin, pas à ma connaissance). Mais ca serait tout à fait possible de le faire (w3m permet bien de browser le web dans un xterm en affichant les images).
Ca y est, j'ai trouvé une idée de truc à coder :)
[^] # Re: ...
Posté par neriki (site web personnel) . Évalué à 8.
Donc la mort de la ligne de commande, ca me fait bien rire!
Et heureusement, dans un mail d'explication, il est plus facile d'envoyer une ligne de commande que d'expliquer: "tu clique sur machin, puis quand bidule apparait, tu clique droit sur truc..."
[^] # Re: ...
Posté par golum . Évalué à 4.
Un IHM , ca évolue beaucoup plus rapidement qu'un API et ca peut être déstabilisant pour l'utilisateur comme pour le développeur qui programmerait par envoi de message directement à l'IHM. Dans un programme bien conçu, l'interface en ligne de commande n'est qu'un moyen d'exposer l'API parmi d'autres.
Aujourd'hui les langages de script ou (Python, perl, Ruby ) permettent d'être beaucoup plus productifs pour les traitement automatisables et sont surtout plus évolutifs
Les exemples de réécriture de hacks en shell qui devenaient inmaintenables réécrit dans un langage
sont nombreux (CVS, Arch, ....pour le domaine que je connais un peu)
Avec ce genre de langages il n'y a plus de réécriture, ils sont "scalables" (pas trouvé l'équivalent francais désolé) et permettent de lier facilement les parties sensibles avec du code optimisé de plus bas niveau sans tout réécrire
Ce n'est pas pour rien qu'on voit emerger de plus en plus de solution de ce genre (Ubuntu basé sur python, google qui en fait un usage intensif, et les perliens et au rubymen sauront completer la liste)
A terme on en n'arrive à ne plus distinguer les langages de scripts et les shells (cf. MSH, ipython, ....) car on prend le meileur des 2 mondes.
[^] # Re: ...
Posté par Anonyme . Évalué à 1.
Chez les nouveaux utilisateurs et une partie du grand publique peu etre. Chez les admin system certainement pas. Une GUI est à des années lumières d'etre aussi pratique qu'une ligne de commande. Après ca dépend de ce que tu as besoin de faire bien sur, si c'est pour faire de la retouche d'images c'est clair que dans beaucoup de cas une GUI sera plus pratique.
Mais parler de la fin de la ligne de commande c'est un peu comme parler de la fin des livres par ce que maintenant on passe à la video.
Une video peut être aussi pratique (si ce n'est plus) qu'un vulgaire livre. C'est juste que beaucoup d'écrivains ont la flemme de perdre du temps à en filmer et monter une qui tienne la route.
[^] # Re: ...
Posté par golum . Évalué à 3.
Tu parles d'une programmation, celle où il faut parser la sortie, et la rediriger. Celle où on crée tout un tas de programme qui ne servent quà ce genre d'usage (cut, xargs et autres hérésies) pour pallier la syntaxe et ce au détriment des perfs. Celle où le moindre contrôle des arguments ou le traitement des exceptions est un chemin de croix et reste ambigu.Celle où le moindre changement de formatage de sortie engendre tout un tas d'anomalies.
Avec des environnements graphiques, tu as bien souvent un bus de programmation qui te donne accès à la "vraie" programmation, ... structurée, réutilisable. KDE a son DCOP, Gnome son DBUS et Windows que tu critiques son COM/DCOM et même un langage shell orienté traiteme d'objet.
Mais c'est sûr il ne faut pas remettre en cause le sacro saint principe d'unix (faire une chose et le faire bien).
Pourtant appeler du DCOP est aussi simple qu'une infâme bidouille pleine de signes cabalistique illisibles en bash et peremt auatnt d'automatisation des traitements et de souplesse.
[^] # Re: ...
Posté par gnumdk (site web personnel) . Évalué à 2.
>signes cabalistique illisibles en bash et peremt auatnt d'automatisation des
>traitements et de souplesse.
Euh, sauf que DCOP permet de renvoyer des données, pas de les traiter...
Sous windows, y'a WMI qui lui déjà permet de faire des choses plus interessante sur les données que tu récuperes...
Mais ne viens pas dire que le ligne de commande est ambigue, je trouve un script shell bien plus compréhensible que du PERL, ce n'est pas parce que tu ne fais pas l'effort de comprendre comment ca marche que c'est de la merde...
[^] # Re: ...
Posté par golum . Évalué à 2.
Evidemment les données tu les traites dans ton programme et si tu veux réutiliser tu en fais un module pas un programme avec un interface en ligne de commande (sur lequele le monde unix n'a jamais cf. les variation autour de getopt)? tu publie son API et tu fournis un interface graphique..
Pour Windows , oui y'a WMI (c'etait à ca que je pensais en fait)
La ligne de commande est amnmbigue dans les shells unix , car tu n'a pas de traitement d'exception, pas d'interface stabilisée, aucun typage, ....
Le perl j'en mange régulièrement ainsi que du bash parce et je peux dire que c'est anti-productif , oui.
En fait, la ligne de commande est utile (voir Msh) ce que je critique c'est le principe des pipe et le fait qu'on ne fait que du tratement de chaine de carctères pas de données avec les shells unix
[^] # Re: ...
Posté par gnumdk (site web personnel) . Évalué à 2.
[^] # Re: ...
Posté par golum . Évalué à 2.
Au lieu d'apprendre les options de la ligne de commande tu consultes l'API de l'objet concerné.
[^] # Re: ...
Posté par gnujsa . Évalué à 3.
Tu plaisante ?
En bash, tu connait l'expansion arithmetique ? Les tableaux ? La différence entre [ $var -eq 0 ] et [ "$var" == "" ] ?
Et sans même parler des programmes externes comme bc, dd, etc... pour faire du calcule sur des flottants ou manipuler des données binaires
« [...] aucun typage, .... »
$ var1=toto
$ declare -i var2
$ var2=tata
bash: tata: unbound variable
$ mystring="hello"
$ echo $(( $mystring +1 ))
bash: hello: unbound variable
$ [ $mystring -eq 0 ] && echo "Ok"
bash: [: hello: integer expression expected
-> help declare
C'est limité, mais de la à dire aucun...
[^] # Re: ...
Posté par golum . Évalué à 3.
Tu as tout dit et c'est ce qui fait qu'au bout de la 10eme fois que tu as bidouillé ton script pour que ca colle pour gérer tous les effets de bord que tu avais oublié et que tu n'y comprends plus rien , tu te decides à réécrire ton prog avec un langage de script qui n'utilise pas des programme artificiels pour pallier la syntaxe.
En plus avec un langage de script et un bon wrapper tu récupères des objets sur lesquels tu as un contrat clair et qui déclenchent des exceptions et tu n'es pas obligé de faire du formatage de chaine de caractère qui reste ambigu et non fiable.
[^] # Re: ...
Posté par Anonyme . Évalué à 1.
[^] # Re: ...
Posté par serge_kara . Évalué à 3.
Les conventions d'IHM texte sont connues et eprouvees..
Sans compter que le "workflow" est beaucoup plus simple a gerer vu que l'utilisateur a moins de latitude dans ses actions.
Sinon, je dis pas ca pour toi en general, mais parce que je l'ai lu un peu partout dans le fil : une ihm graphique ca peut tout a fait se scripter.
cf Excel ou Textpad avec leurs macros, Automator et surement bien d'autres encore.
Mais pour ca, faut avoir un modele d'ihm bien concu derriere.
[^] # Re: ...
Posté par manatlan (site web personnel) . Évalué à 2.
et ça m'a fait mourrir de rire, merci pour ce post, qui me fera bien commencer la nuit ...
ps : je garde la phrase en stock, dans mon tomboy, pour que je puisse te citer de temps à autres ....
encore bravo, et merci !
[^] # Re: ...
Posté par liberforce (site web personnel) . Évalué à 6.
[^] # Re: ...
Posté par Yusei (Mastodon) . Évalué à 6.
Autrement dit, c'est une toute petite minorité des utilisateurs ;)
Mais bon, plutôt qu'une distinction débutant/expert, une distinction simple/personnalisable reviendrait au même, sans inciter les vaniteux utilisateurs à se prétendre experts.
[^] # Re: ...
Posté par Anonyme . Évalué à 4.
Mais c'est faut de dire que personne n'est utilisateur avancé. L'utilisateur avancé n'est pas forcement quelqu'un qui connait beaucoup de logiciel. C'est quelqu'un qui a compris les principes de fond : hierarchie des fichiers sur le disque dur, rôle des barres d'outils et des menus...
Tout un ensemble de chose qui nous paraissent évidentes mais qui soit loin de l'être pour ceux qui ne se sont jamais interessé au sujet.
Ce public que vise GNOME a des besoins particuliers (cf débats sur le mode spatial du gestionnaire de fichiers), ce public c'est la majorité des utilisateurs de PC de nos jours.
Le problème, c'est que pour viser ce public, GNOME s'est coupé du reste. Franchement, vous vous voyez utiliser un environnement où vous ne pouvez même pas choisir toutes les couleurs de l'apparence des fenêtres ?
Pas moi. Pourtant, la plupart de la planète s'en tape, se contente des couleurs par défaut.
Où tracer la limite ? Pourquoi ne pas faire quelque chose qui s'adapte à mon profil, plutôt que de n'imaginer qu'un seul et unique profil d'utilisateur ?
Il ne faut certes pas multiplier les profils, on s'y perdrait. Mais il y a clairement deux types d'utilisateurs qu'on retrouve couramment. Ceux qui sont vite paumé et qui ne savent pas comment trouver, pour qui le moindre ajout d'info est un problème, et ceux qui veulent pouvoir bricoler.
Et il ne s'agirait pas de fournir deux logiciels différent : le même environnement mais dans un cas avec la possibilité de configurer des choses prédéfinies et figée dans l'autre cas.
[^] # Re: ...
Posté par Yusei (Mastodon) . Évalué à 2.
Gnome tolère tout à fait d'autres gestionnaires de fenêtre que metacity, du moment que ces WM respectent les normes. Quand j'utilise Gnome, c'est avec openbox, parce que j'ai envie d'avoir des bords résistants et que metacity commence à peine à savoir le faire. Si on veut un truc encore plus personnalisable, on peut aussi utiliser Sawfish.
Est-ce qu'on peut encore dire que j'utilise Gnome si j'ai changé un des composants ? Je pense que oui, Gnome, c'est plutôt les services qui tournent en tâche de fond.
[^] # Re: ...
Posté par allcolor (site web personnel) . Évalué à 2.
Donc en gros gnome est un desktop pour ordinatophobe et/ou idiot.
[^] # Re: ...
Posté par Yusei (Mastodon) . Évalué à 4.
[^] # Re: ...
Posté par Larry Cow . Évalué à 5.
[^] # Re: ...
Posté par SF . Évalué à 5.
[^] # Re: ...
Posté par Olivier Serve (site web personnel) . Évalué à 4.
[^] # Re: ...
Posté par SF . Évalué à 3.
Voir toutes les options est sans doute très bien pour celui qui sait déjà à quoi elles servent et qui en a l'utilité mais pas pour les autres.
Moi il y a peu de choses qui me manquent sous gnome et quand elles me manquent je me réfugie le plus souvent bien au chaud dans l'univers rassurant d'un terminal.
Quand je suis sous KDE, je passe mon temps à virer de l'interface tout ce que je peux faire avec mon terminal pour n'avoir sous les yeux que ce dont j'ai besoin dans une interface graphique.
Je ne vois pas ce que je ne peux pas faire avec KDE que je puisse faire avec Gnome par contre il y a des choses que je peux faire avec KDE mais pas avec Gnome. Mais je préfère manquer de quelques trucs que d'en avoir trop.
[^] # Re: ...
Posté par lezardbreton . Évalué à 10.
Voir toutes les options est sans doute très bien pour celui qui sait déjà à quoi elles servent et qui en a l'utilité mais pas pour les autres.
C'est là-dessus qu'à mon avis doit se centrer le débat. Bien que ton discours soit logique, il est à mon avis complètement erroné.
1) Non, tu n'es pas obligé d'apprendre toutes les choses qui apparaissent à l'écran. Si the GIMP n'avait que les options qui me servent, il ne servirait à rien pour la plupart de ses utilisateurs actuels. Je n'ai pas à apprendre toutes les options qu'il a, je n'ai que à comprendre quelles sont les options qui me servent, quitte à être aidé par un forum, une personne, ou de la documentation.
2) Voir toutes les options est important car tous les utilisateurs n'ont pas les mêmes besoins, ni la même utilisation des logiciels qui sont pourtant communs.
Supprimer de l'interface est (encore une fois, c'est mon avis) une connerie, organiser intelligemment pour que l'utilisateur n'ait pas à chercher l'option qu'il recherche l'est. C'est pour ça que selon moi, sur presque chacun des outils de GNOME, il devrait y avoir une interface contenant les options pour utilisateurs avancés, même si celle-ci doit être en second plan. Le but est de mettre en valeur les options qu'utiliseront 90% des utilisateurs, même débutants et donc qu'ils n'aient pas à se soucier des options perturbantes.
Je ne vais pas insister là-dessus, mais je trouve que Linus a 100% raison sur son mail. Par contre, je n'apprécie pas la manière dont il fait preuve, je rappelle qu'il y a des bénévoles qui bossent sur GNOME, qu'ils ont fourni un gros boulot. Même si je pense que ce qu'ils ont fait est une erreur flagrante de conception, jamais je ne pourrais me permettre de les traiter de "nazis de l'interface". Ce qu'on appelle langue de bois est aussi une façon de respecter les convictions et le travail des autres. Si ça permet de faire réagir les développeurs par contre, alors là je serais satisfait. De toute façon, je ne fais pas parti de la cible de GNOME, visiblement...
[^] # Re: ...
Posté par Yusei (Mastodon) . Évalué à 2.
Idéalement, si c'était bien fait, il n'y aurait pas besoin de mémoriser quoi que ce soit: si tu veux taper un chemin, tu tapes un chemin, et ça marche. Et c'est cette conception là que je trouve bien: le fait de masquer cette zone de texte pour les utilisateurs qui ne savent pas s'en servir, mais aussi avoir un comportement correct si un utilisateur essaye de taper un chemin.
[^] # Re: ...
Posté par Olivier Serve (site web personnel) . Évalué à 7.
[^] # Re: ...
Posté par serge_kara . Évalué à 7.
Me demande pas comment ca marche, ni comment on arrive a ce resultat, mais c'est vrament l'impression que me donne Os X.
[^] # Re: ...
Posté par Olivier Serve (site web personnel) . Évalué à 7.
[^] # Re: ...
Posté par Yusei (Mastodon) . Évalué à 5.
- Se dire que ce serait bien si ça existait, et chercher dans l'aide
- Regarder dans l'aide pour voir s'il y a des trucs bien auxquels on n'a pas pensé
- Demander autour de soi
Dans le pire des cas, même si tu ne devines pas que c'est possible, que personne ne te le dit et que tu ne lis pas l'aide, tu peux encore utiliser le sélecteur de fichiers.
Encore une fois, je ne dis pas qu'il ne serait pas mieux de mettre cette **** de boîte de texte dans le dialogue, je n'en sais rien, simplement je ne suis pas plus convaincu par l'approche qui consiste à tout mettre dans l'interface, et laisser l'utilisateur se débrouiller. Quand je lance konqueror, je suis toujours un peu débordé par le nombre d'options et d'éléments dans les menus. Donc cacher des choses, du moment qu'elles ne sont pas strictement nécessaires, ça ne me choque pas a priori.
[^] # Re: ...
Posté par Olivier Serve (site web personnel) . Évalué à 4.
La ligne de commande suppose que l'utilisateur connait les outils mis à sa disposition avant de les utiliser. Il y a donc une phase d'apprentissage assez longue et rebutante.
Une interface graphique permet au contraire de présenter à l'utilisateur les actions et options du programme. L'apprentissage se fait pendant l'utilisation du logiciel. Si des fonctionalités sont cachées _et_ inaccessibles via une configuration quelconque, on retombe dans le problème de la ligne de commande et de son manque d'intuitivité.
Que ce soit le réglage par défaut, soit. Mais qu'on n'ait pas moyen de configurer ce comportement, là franchement c'est trop pour moi.
Tant mieux pour toi si tu es à l'aise avec Gnome, moi je n'arrive pas à m'y faire. Et l'utilisation de cette boîte de dialogue de Firefox me le rappelle sans cesse.
[^] # Re: ...
Posté par Yusei (Mastodon) . Évalué à 2.
Là dessus, on est d'accord: une clé dans gconf pour activer automatiquement la zone de saisie ne gènerait personne, ne va pas contre la philosophie de Gnome, et serait utile à beaucoup de gens.
Ceci dit, je ne crois pas que l'absence de cette clé soit un choix de la part de l'équipe de Gnome, c'est probablement que personne ne l'a fait pour l'instant.
[^] # Re: ...
Posté par Éric (site web personnel) . Évalué à 5.
Et une pour déplier par défaut la liste des répertoires, merci ;)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ...
Posté par totof2000 . Évalué à 3.
Personnellement je suis un adepte des deux, seln l'utilisation que je fais de ma machine.
La ligne de commande suppose que l'utilisateur connait les outils mis à sa disposition avant de les utiliser. Il y a donc une phase d'apprentissage assez longue et rebutante.
C'est faux. Ca laisse une impression de simplicité.
Une interface graphique permet au contraire de présenter à l'utilisateur les actions et options du programme. L'apprentissage se fait pendant l'utilisation du logiciel.
euh .... pas convaincu. C'est vrai que si t'es un adepte des pratiques du style "Je clique ici et je regarde ce qui se passe", tu prend des risques, même avec une GUI.
Si des fonctionalités sont cachées _et_ inaccessibles via une configuration quelconque, on retombe dans le problème de la ligne de commande et de son manque d'intuitivité.
Et si toutes les fonctionnalites sont visibles, tu tombe dans un autre problème: le manque de clarté.
Que ce soit via GUI ou ligne de commande, tout utilitaire qui commence a être un peu complexe necessite un apprentissage pour connaitre les diverses options et paramétrages disponnibles, ainsi que leur effet. Apres certaines choses paraissent intuitives (exemples menu fichier pour connaitre les actions a effectuer sur un fichier), mais c'est une question d'habitude: quelqu'un qui n'a jamais vu une GUI de sa vie ne saura pas que pour enregistrer son document il faut aller dans le menu fichier puis cliquer sur "enregistrer".
Et puis sinon, pour me créer mes propres outils qui utilisent certaines options de ton GUI je ais comment sans ligne de commande? Parce que dans le genre rigide c'est pas mal la GUI.
[^] # Re: ...
Posté par Anonyme . Évalué à 1.
C'est là qu'une interface bien pensée fait la différence. Rien n'interdit de ne présenter que les options utiles en fonction des choix déjà cochés, par exemple
Sauf qu'avec une interface graphique, tu as l'option sous les yeux. Tu n'as pas à te taper moult man, how-to et recherche sur google pour découvrir qu'elle existe.
Apres certaines choses paraissent intuitives (exemples menu fichier pour connaitre les actions a effectuer sur un fichier), mais c'est une question d'habitude: quelqu'un qui n'a jamais vu une GUI de sa vie ne saura pas que pour enregistrer son document il faut aller dans le menu fichier puis cliquer sur "enregistrer".
Tu n'as jamais entendu parler d'API ? Tu ne t'es jamais demandé à quoi pouvait bien servir les dll sous Windows ? ou DCOP sous KDE ? Je ne vois pas en quoi il serait impossible de réaliser la même chose en interface graphique qu'en ligne de commande. Certes, ça demande certainement plus de travail au programmeur, mais c'est aussi vachement plus confortable pour l'utilisateur.
[^] # Re: ...
Posté par totof2000 . Évalué à 6.
Moi si
Tu ne t'es jamais demandé à quoi pouvait bien servir les dll sous Windows ?
Je sais a quoi ça sert merci.
ou DCOP sous KDE ?
Je ne connais pas par contre (j'aime pas KDE donc j'utilise pas).
Excuse moi mais tes propos me font bien rigoler. Tu vas sortir la grosse artillerie (dll and co) joste pour configurer une centaine d'imprimantes ?. (ce n'est qu'un exemple). L'avantage de la ligne de commande est qu'elle permet de se créer ses outils sans trop d'efforts. Malgre ce qu'on en dit elle permet d'automatiser un grand nombre de choses sans être un dieu de la programmation.
Je ne vois pas en quoi il serait impossible de réaliser la même chose en interface graphique qu'en ligne de commande. Certes, ça demande certainement plus de travail au programmeur, mais c'est aussi vachement plus confortable pour l'utilisateur.
Je n'ai rien dit de tel, je dis simplement que l'interface graphique et la ligne de commande n'ont rien a s'envier l'un a l'autre, et qu'il serait stupide d'abandonner la ligne de commande au profit de 'interface ggraphique. Les deux peuvent cohabiter sans problème, parce que l'utilisation de l'un et de l'autre sera plus ou moins aisée selon le contexte. Par exemple je me vois mal faire de la retouche d'image a la ligne de commande, tout comme d'autres tachjes sont plus faciles a faire en ligne de commande.
mais c'est aussi vachement plus confortable pour l'utilisateur.
Parfois (même souvent), l'utilisateur est aussi programmeur (plus ou moins).
C'est pratique de pouvoir automatiser certaines taches répétitives sans avoir forcément besoin d'un dieu de la programmation. Donc comme je disais plus haut, GUI et ligne de commande ont tous les deux leurs avantages selon le contexte d'utilisation.
[^] # Re: ...
Posté par Moonz . Évalué à 3.
Perso, certains de mes scripts shell font appel à dcop (et parfois c'est dcop konsole-xxxx ;)). De plus avec dcop tu ne peux pas faire des choses simples comme assignation de variable, boucles... Je vois mal comment tu peux faire un truc comme for f in *.wmv; do mencoder $f -o `echo $f | sed s/.wma/.avi/` -oac faac -ovc x264; done avec JUSTE dcop... Et je vois mal comment controler kwm avec la ligne de commande sans dcop. Pour moi, les deux sont complémentaires...
[^] # Re: ...
Posté par Anonyme . Évalué à 1.
Bilan des courses, tu me dis que tu peux faire ça avec la ligne de commande mais pas avec une interface graphique. Normal, il n'y a pas d'application suffisamment complète pour le faire à l'heure actuelle.
Mais qu'y-t'il d'insurmontable à faire un programme avec une interface graphique qui puisse te proposer, de faire la même chose en 2 clics ? Tu cliques droit sur le répertoire en question dans le programme, et tu sélectionnes l'entrée « appliquer un traitement », là s'ouvre une fenêtre, te proposant de sélectionner ou non un filtre de sélection du type de fichier, et la commande à exécuter.
Et voilà comment n'importe quel débutant aurait pu faire la même chose que ta commande, alors que n'importe quel débutant n'aurait certainement jamais pu seulement imaginer ta commande en ligne de commande.
Un truc qui par exemple existe sous Windows et par encore sous Linux, c'est de pouvoir sélectionner x fichiers dans l'explorateur, de faire « renommer », de donner le nom, et tous les fichiers seront renommés avec le nom et un indice auto-incrémenté. Sous linux, tu fais encore ça à la ligne de commande, et ce n'est certainement pas plus simple.
[^] # Re: ...
Posté par jjl (site web personnel) . Évalué à 2.
avidemux s'en approche non ? (je connais pas trop)
Ca existe (en tout cas dans certaines distribs):
dans Konqueror, click droit/actions/renommer avec KRename. Il doit suffir d'avoir le bon service menu
[^] # Re: ...
Posté par Prosper . Évalué à 4.
http://www.apple.com/fr/macosx/features/automator/
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ...
Posté par totof2000 . Évalué à 3.
Ben pour dire les choses simplement, aucune interface graphique ne me permet de faire exactement ce dont j'ai besoin de facon simple. Aucune d'erntre elle ne me permet de faire un truc en 1 clic automatiquement.
Par contre effectivement quand le besoin s'en fait sentir je n'hesite pas a utiliser des toolkits graphiques style perl/tk ou python/tk. Ou alors je fais certaines choses via interface personnalisee en PHP via un serveur Apache. Mais mes besoins ne sont pas les besoins de mon voisin, et une interface grapique capable de couvrir tous les besoins de tout le monde j'y crois pas trop. Sinon j'utilise beaucoup la ligne de commande parce que je peux sauvegarder les commandes dans un fichier par exemple pour le rappeler plus tard, ou pour l'executer via cron .... mais pour d'autres choses, ( au taf par exemple), j'essaie de pousser a l'utilisation d'une base de donnee+php+www parce que dans ce cas precis, ca nous permettrai de faire beaucoup de choses repetitives, mais qui demandent d'avoir une vue globale de ce que l'on fait, et dans ce cas precis c'est tres adapte.
Juste une question: pourquoi as-tu un avis aussi negatif sur la ligne de commande?
[^] # Re: ...
Posté par Anonyme . Évalué à 3.
Pour deux raisons.
La principale, c'est que depuis le début, je crois qu'on parle chacun de deux choses différentes. Je me plac e personnellement dans la peau de l'utilisateur lambda, pour qui la ligne de commande est quelques chose d'extrêmement rébarbatif, et toi visiblement dans la peau de l'utilisateur avancé, voire de l'administrateur système, qui n'aura évidemment pas les mêmes besoins.
L'autre, c'est que bien que n'ayant jamais programmé sous Linux, j'ai tout de même eu l'occasion de faire quelques programmes sous Windows (en Delphi principalement), et je sais pertinement que moyennant de l'application et du temps, on peut rendre une interface parfaitement fonctionnelle et aussi pratique, voire davantage, qu'une ligne de commande.
En fait, comme de nombreux commentaires l'ont signalé, il y a des cas de figure où la ligne de commande est adaptée, d'autre où l'interface graphique l'est davantage. Un commentaire de Gnap Gnap aka Yeupou m'a paru à ce sujet très censé : « Supprimer la ligne de commande n'est pas une bonne idée. La rendre absolument pas nécessaire oui. La ligne de commande ne devrait jamais être nécessaire et toujours disponible. »
[^] # Re: ...
Posté par Yusei (Mastodon) . Évalué à 2.
(c'est moi qui souligne)
Pour ma part, j'utilise quotidiennement la ligne de commande, et j'ai l'habitude de programmer des interfaces graphiques, j'irais même jusqu'à dire que j'aime ça. Pourtant, je ne suis pas du tout convaincu qu'on ait à disposition les outils nécessaires pour faire une GUI toujours aussi efficace qu'une ligne de commande, dans tous les cas.
Par exemple, faire une GUI qui permette de faire tous les traitements que l'on peut faire avec des commandes shell comme sed et awk, ça me semble hors de portée. Dans une certaine mesure, on peut obtenir des traitements similaires avec un tableur, mais par exemple faire une bonne GUI pour saisir une expression rationnelle, je ne sais pas faire.
On peut imaginer une GUI à base de graphes, où l'on peut sélectionner des choses comme "une lettre d'un mot", "un chiffre", des quantifieurs, etc. et les relier entre eux, mais est-ce que ça peut être "aussi pratique, voire davantage" qu'une ligne de commande ?
[^] # Re: ...
Posté par Yusei (Mastodon) . Évalué à 2.
[^] # Re: ...
Posté par totof2000 . Évalué à 3.
En fait je me place dans la peau de l'utilisateur dont le metier n'est pas l'informatique, mais qui aurait besoin d'automatiser certaines des taches qu'il accomplit regulierement. On ne peut pas forcément parler dans ce cas d'utilisateur avancé (il ne sait faire que ce dont il a besoin), mais pas de débutant non plus. Dans ce cas il peut faire deux choses: soit demander a quelqu'un de lui realiser son interface en utilisant les API, lib partagées, etc ... ou alors il le fait lui même. Et pour le faire soi meme, le shell reste quand même abordable pour un utilisateur "de base", moyennant une petite (auto-)formation. Et c'est d'ailleurs dans cette optique que le shell a ete inventé: fournir un langage de programmation suffisamment simple pour automatiser les taches des non-spécialiste de la programmation.
[^] # Re: ...
Posté par Pooly (site web personnel) . Évalué à 2.
[^] # Re: ...
Posté par Anonyme . Évalué à -2.
Sinon, un truc bien gavant sous GNOME, c'est de ne pas avoir la possibilité d'afficher les images sous forme d'aperçu dans le sélecteur de fichiers. C'est incroyablement chiant et anti-intuitif ce truc, même Windows 95 proposait mieux.
[^] # Re: ...
Posté par Pascal Terjan (site web personnel) . Évalué à 4.
[^] # Re: ...
Posté par gnumdk (site web personnel) . Évalué à 2.
[^] # Re: ...
Posté par golum . Évalué à 5.
Désolé je corrige, on écrit miniature comme mini pas comme signature
[^] # Re: ...
Posté par gnumdk (site web personnel) . Évalué à 2.
[^] # Re: ...
Posté par Anonyme . Évalué à 2.
La grosse différence, c'est que tu n'es pas obligé de cliquer sur des centaines de fichiers pour retrouver LA photo que tu recherches (ni de mémoriser le nom du fichier). Sous KDE, j'active l'affichage sous forme de miniatures, et je vois pleins de petites images dans le sélecteur de fichiers -> c'est super rapide et pratique pour retrouver une photo/image.
[^] # Re: ...
Posté par liberforce (site web personnel) . Évalué à 1.
[^] # Re: ...
Posté par Anonyme . Évalué à 3.
[^] # Re: ...
Posté par Pooly (site web personnel) . Évalué à 0.
[^] # Re: ...
Posté par Anonyme . Évalué à 1.
[^] # Re: ...
Posté par Pooly (site web personnel) . Évalué à 0.
le 659911 est le commentaire parent, maintenant je le laisse remonter le fil de discussion, pour voir qui effectivement est hors-sujet. A bon entendeur.
[^] # Re: ...
Posté par serge_kara . Évalué à 2.
chez ouam, j'ai 1900 entrees dans ce repertoire (j'avais commence a rediger une reponse et ma machine a freeze, c'est ballot).
Comment un humain peut s'y retrouver dans 1900 entrees?
D'autant plus que les 3/4 ou plus sont inutilisables par une application graphique, puisque ce sont des commandes text only.
On se retrouve a melanger des choses qui n'ont rien a voir.
Bref, mieux vaudrait un repertoire /usr/bin ou on met les commandes systeme, les text only etc, et un /Application et un $HOME/Applications (a la macos en fait) ou on place les applis utilisateur/graphiques, en bref tout ce qui n'est pas directement lie au systeme.
Bref, tout ca pour dire que le probleme, c'est pas la boite de dialogue, mais le repertoire /usr/bin.
still my 2 cents, avis perso, me flammez pas patati patata
[^] # Re: ...
Posté par gnumdk (site web personnel) . Évalué à 3.
>repertoire /usr/bin.
Mwai, enfin le probleme, c'est plus les utilisateurs qui vont faire un tour dans autre chose que leur home dir...
Franchement, t'en a quoi à foutre qu'il y'a 99999999 entrées dans /usr/bin? C'est quoi l'interet d'avoir un rep par application? Tu connais rpm et dpkg?
[^] # Re: ...
Posté par serge_kara . Évalué à 1.
Et ca me gave de me faire mal a la tete de trier 2000 entrees quand je dois indiquer l'emplacement dudit binaire.
Placer toutes les applis utilisateurs dans un repertoire specifique, c'est autrement plus pratique, tu ajoutes (automatiquement) une entree au path et on en parle plus, tout le monde est content.
Sinon, je vois pas ce que rpm et dpkg viennent faire la dedans, ils se contentent de mettre les binaire la ou on leur dit de les mettre (ie generalement dans /usr/bin).
Et j'ai *pas* parle d'un rep par applications, faut arreter d'extrapoler les discours des gens, serieux, ou apprendre a lire.
[^] # Re: ...
Posté par Ozz . Évalué à 2.
Je n'ai pas testé fx 1.5 mais je ne crois pas que ça ai changé. (?)
[^] # Re: ...
Posté par gnujsa . Évalué à 3.
Firefox utilise ~/.mailcap ou /etc/mailcap. Methode un peu oldschool, mais qui a le mérite de ne pas dépendre d'un "desktop" particulier.
[^] # Re: ...
Posté par Yusei (Mastodon) . Évalué à 3.
[^] # Re: ...
Posté par gnujsa . Évalué à 4.
devrait te dire quel application Firefox te propose, par default, pour ouvrir les documents PDF à condition qu'il n'y ai pas d'entrée pdf dans ~/.mailcap ni dans /etc/mailcap.order
mailcap est assez basique: il ne gére pas les alias comme share-mime-info de freedesktop. Effectivement, pour les docs PDF j'ai des entrées 'application/pdf' et 'application/x-pdf' qui renvoient des programmes différents. Ce qui peut expliquer le phénomène d' alternance constaté en fonction du type MIME que renvoie le serveur.
Le bon type MIME pour les docs PDF est : application/pdf
http://www.iana.org/assignments/media-types/application/
http://www.rfc-editor.org/rfc/rfc3778.txt
[^] # Re: ...
Posté par gnumdk (site web personnel) . Évalué à 3.
>indiquer l'emplacement dudit binaire.
Les binaires qui sont dans /usr/bin sont dans ton PATH alors je vois pas pourquoi tu aurais à indiquer le chemin du dit binaire. Je dirais meme qu'il ne m'arrive jamais de faire un ls dans /usr/bin en ligne de commande, alors quand je suis dans une appli graphique...
[^] # Re: ...
Posté par serge_kara . Évalué à 2.
Comment tu choisi ton soft de preview dans aMule ?
quand tu connais pas le nom exact du binaire (genre soffice pour openoffice) ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ...
Posté par serge_kara . Évalué à 2.
on parle d'applications non integrees, qui n'utilisent donc PAS le menu applications.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ...
Posté par serge_kara . Évalué à 2.
Comment tu choisi ton soft de preview dans aMule ?
quand tu connais pas le nom exact du binaire (genre soffice pour openoffice) ?
firefox est integre?
amule est integre?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ...
Posté par serge_kara . Évalué à 5.
on parle de lancer firefox, mais que quand tu dl un fichier, et que tu fais ouvrir avec, t'as un selecteur de ficheir qui te demande le **binaire** a utiliser pour lancer ledit fichier.
Quand tu selectionnes le previewer de fichier dans aMule, meme chose.
Et tu peux en trouver une chiee comme ca, toutes les applications n'utilisant pas explicitement un bureau en fait.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ...
Posté par serge_kara . Évalué à 3.
wouhou!!! boogie!!
c'est ce que je dit depuis le debut, et j'ai jamais reporte la faute du bordel de /usr/bin sur une quelconque distribution..
[^] # Re: ...
Posté par gnumdk (site web personnel) . Évalué à 8.
[^] # Re: ...
Posté par phoenix (site web personnel) . Évalué à 1.
[^] # Re: ...
Posté par gnumdk (site web personnel) . Évalué à 2.
- Ton application non intégré est un package pour ta distrib trouvé sur le net, alors c'est la faute de l'auteur de ce paquet si il ne respecte pas le standard freedesktop.
- Ton application non intégré est un gros tar.gz avec un binaire ou un tar avec le source, ou ...
Dans ce cas la, je place les binaire dans /opt/nom_appli et je place les soft compilé dans /usr/local
[^] # Re: ...
Posté par serge_kara . Évalué à 3.
cette manie de reporter la faute sur le voisin quand on pointe un probleme...
c'est la faute de debian si firefox ne s'integre a rien?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ...
Posté par serge_kara . Évalué à 2.
[^] # Re: ...
Posté par gnumdk (site web personnel) . Évalué à 2.
Non, c'est la faute de Firefox, personne ne t'oblige à l'utiliser...
Et OUI si une application n'apparait pas dans le menu et/ou ne met pas à jour les association avec les types de fichiers, c'est de la faute du packageur! Le boulot de packageur n'est pas juste de compiler un soft à l'arrache...
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ...
Posté par serge_kara . Évalué à 3.
relis le sujet depuis le depart.
l'assertion initiale est :
- quand je fais "ouvrir avec ..." apres avoir dl un fichier dans firefox, je suis olbige d'aller dans /usr/bin et c'est loooooooong.
ce a quoi je reponds : on se demande bien pourquoi on a un foutoir pareil dans /usr/bin.
On me dit que pour ca ya un menu application.
Oui, mias le menu application il apparait que si l'appli en question a ete compilee avec un support pour le bureau en question.
Et sur une machine standard t'es sur et certain d'avoir au moins une appli qui va pas etre integree (et en pratique, t'as au moins une appli qui est souvent ou moyennement utilisee qui va pas etre integree).
Et dans ce cas, c'est la merde.
de tout de facon contrairement a ce qu'il dit firefox apparait tres bien dans le menu K de KDE sous debian/kubuntu.
ha bon?
j'aimerais bien que tu me montres ou j'ai dit que firefox n'apparait pas dans le menu K.
Ou encore ou j'ai dit que c'etait la faute d'*buntu si firefox n'est pas integre a kde.
Ou encore que tu me trouves des personnes qui ont un firefox integre a kde ou gnome. Et integre, ca veut pas dire qu'on peut le lancer depuis un menu demarrer, ca veut dire que firefox est au courant qu'il tourne sur gnome ou kde et qu'il utilise donc les fonctions specifiques de kde ou gnome, comme par exemple, ca c'est une sacre coincidence, on en parle justement depuis quelques posts deja, le menu application au lieu d'un selecteur de fichier pour choisir une application externe.
Bref, relis le sujet.
[^] # Re: ...
Posté par serge_kara . Évalué à 2.
l'integration, c'est pas un alias ou une icone qui fait plouf plouf quand on clique dessus, ca c'est le bureau qui gere ca.
l'integration, c'est utiliser les composants propres du bureau, et ca c'est pas le boulot du packageur.
[^] # Re: ...
Posté par gnumdk (site web personnel) . Évalué à 2.
[^] # Re: ...
Posté par serge_kara . Évalué à 3.
On reprend depuis le debut.
Point numero 1.
Des softs qui ne respectent pas freedesktop ou je sais pas quel autre standard, yen aura toujours.
Ne serait ce que pour ceux qui sont anterieur a freedesktop.
Point numero 2.
La philosphie linux, c'est de tout mettre en vrac dans /usr/bin.
Point numero 3.
Quand un humain doit aller faire un tour dans /usr/bin, il en ressort avec un mal de crane, voir il y rentre meme pas (j'ai toujours capitule devant le "ouvrir avec ..." de firefox et me suis resolu a passer par un navigateur de fichier).
Point numero 4.
Une legere organisation au niveau de /usr/bin ne ferait de mal a personne, bien au contraire, reglerais au passage le point numero 1 et me ferais faire des economies d'aspirine ou profiter d'"ouvrir avec" de FF (point 3).
Ou alors, tu consideres normal d'avoir un bordel monstreux dans /usr/bin et d'avoir besoin d'une surcouche pour y acceder de facon decente.
Et dans ce cas, je te comprends pas.
[^] # Re: ...
Posté par gnumdk (site web personnel) . Évalué à 2.
>d'avoir besoin d'une surcouche pour y acceder de facon decente.
>Et dans ce cas, je te comprends pas.
On en est la alors ;)
Je ne vois pas ce qu'on va gagner à aller organiser /usr/bin! Je ne suis jamais aller faire quoi que ce soit dans ce répertoire!
Et comme toi, quand j'ai vu firefox me demander la premier fois le chemin vers un executable pour ouvrir un pdf, ben j'ai pas chercher à comprendre: "mauvais logiciel, changer de logiciel" tandis que toi tu penses: "mauvais OS, changer l'OS"...
Donc je suis bien d'accord avec toi, dans le cas d'un logiciel mal concu, c'est embetant /usr/bin mais le probleme de base, c'est le logiciel mal concu. Je n'utilise que des applications Kde et je peux te dire que ce probleme ne m'est jamais arrivé!
[^] # Re: ...
Posté par serge_kara . Évalué à 2.
en pratique, c'est rarissime ce genre de comportement.
Perso, j'ai freine tant que possible, et je me retrouve quand meme avec firefox, totem et surement d'autres auquel je pense pas.
Et comme toi, quand j'ai vu firefox me demander la premier fois le chemin vers un executable pour ouvrir un pdf, ben j'ai pas chercher à comprendre: "mauvais logiciel, changer de logiciel" tandis que toi tu penses: "mauvais OS, changer l'OS"...
j'irais pas jusqu'a dire que firefox est bien concu au niveau de l'integration au desktop sous linux, mais avoir besoin d'une surcouche, qui n'existe pas en standard, pour acceder a /usr/bin ne me parait pas etre un bon choix non plus...
[^] # Re: ...
Posté par Yusei (Mastodon) . Évalué à 2.
[^] # Re: ...
Posté par serge_kara . Évalué à 2.
je sais pas comment marche gnome, mais je trouve que le menu de kde est tout bonnement inutilisable.
Cette manie de classer par ordre alphabetique des descriptions et de surcharger avec le nom entre parenthese, le tout saupoudre d'icone incomprehensible, c'est du grand n'importe quoi.
En regle generale, je trouve les menus a la "menu demarrer" totalement depasses et anti ergonomiques.
La premiere chose que je fais sur un kde, c'est virer le menu K, et si je pouvais le faire sur mon windows au taff, ca serait fait depuis loooooooongtemps.
Un dock pour les applis courantes, un repertoire qui contient les binaires *reellement* utilise plus une recherche avancee a la beagle/spotlight est bien plus efficace.
Exit aussi la barre de taches qui bouffe de la place pour rien.
Ca existe deja et ca s'appelle macos, ca peut se faire en partie avec KDE, connais pas gnome je sais pas si ca peut se faire avec.
Le classement par categorie n'est pas pratique du tout car propre a chaque personne (perception des categories) et problematiques pour les applis ambigues.
[^] # Re: ...
Posté par Yusei (Mastodon) . Évalué à 2.
Ceci dit, je m'en sers aussi très peu pour lancer des programmes, mais un menu arborescent est plus efficace qu'une liste de 10000 programmes quand tu en cherches un en particulier. C'est pour ça que je pensais que ça résoudrait ton problème. Dans mon menu Debian par exemple, je n'ai pas les 2100 programmes que j'ai dans mon /usr/bin
À la limite, si c'est le coté hiérarchique qui ne te plait pas, avec très peu de code ça doit pouvoir se désactiver. Ce n'était pas le point que je voulais suggérer. Ce à quoi je faisais référence, c'est que le fait d'avoir tous les programmes en vrac dans /usr/bin n'empêche pas d'avoir une liste des programmes graphiques réellement utilisés dans le menu.
En fait, ton répertoire /Applications, pour moi c'est le menu. Qu'il soit hiérarchique ou pas. Ce n'est pas un endroit physique sur le disque où sont regroupés les programmes, mais c'est un endroit logique qui a la même fonction. ET qui est personnalisable par utilisateurs, ce qui est potentiellement une bonne chose.
[^] # Re: ...
Posté par serge_kara . Évalué à 2.
Donc c'est le menu kubuntu qui est inutilisable, au temps pour moi :-)
À la limite, si c'est le coté hiérarchique qui ne te plait pas, avec très peu de code ça doit pouvoir se désactiver.
ben en fait, je m'en sert pas du tout. Sauf sous la contrainte (genre ajouter une appli au tableau de bord).
Ce à quoi je faisais référence, c'est que le fait d'avoir tous les programmes en vrac dans /usr/bin n'empêche pas d'avoir une liste des programmes graphiques réellement utilisés dans le menu.
ben ouais, mais a la premiere appli non integree au bureau, ca va peter.
Et autant sur un os proprio bien carre, c'est rare, autant sur n'importe quel bureau t'es a peu pres certain d'avoir au moins une appli qui va te faire chier car non integree.
Apres, rien ne m'empeche de me faire un rep dans mon home avec les lien qui vont bien.. m'enfin, faut tenir le truc a jour tout ca, c'est plus que lourd et c'est une enorme perte de temps.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ...
Posté par serge_kara . Évalué à 2.
non, il a une barre de menu, qui change par application, et un dock, qui n'a pas grand chose a voir avec une barre de taches.
Les menus cela se configure il y a des logiciels fournis par defaut pour cela pour Gnome et KDE
ah ouais, en gros j'installe un bureau preconfigure pour tout peter et refaire tout seul derriere.
Si c'est pour faire ca, je m'installe un windowmaker, un xfce ou un truc du genre.
En fait j'ai trouve la solution : j'utilise pas le menu application et je me suis fait un dock a la macos.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ...
Posté par gnumdk (site web personnel) . Évalué à 2.
>avec le nom entre parenthese,
Totalement configurable dans les preferences du kicker...
>Un dock pour les applis courantes, un repertoire qui contient les binaires
>*reellement* utilise plus une recherche avancee a la beagle/spotlight est bien
>plus efficace.
C'est vrai que copier les applications que tu trouves dans applications:/ dans un repertoire MesApplicationsReellementUtilisé c'est super compliqué... Je vois pas pourquoi tu vourdrais te prendre la tete à aller chercher ca dans /usr/bin...
Dis toi que sous Macos, quand tu cliques sur une appli, tu ne lance pas un binaire, tu utilises une couche d'abstraction, ben sous linux la couche d'abstraction, ce sont les .desktop.
[^] # Re: ...
Posté par serge_kara . Évalué à 2.
ah ouais, super pratique.
Et le truc bien c'est que ca fout par terre le concept meme de dpkg ce truc, c'est un reel plaisir a maintenir, pis faut quand meme se farcir le /usr/bin au moins une fois pour trouver le binaire kivabien.
[^] # Re: ...
Posté par Anonyme . Évalué à 2.
Ça se configure ça hein. C'est pas parce que c'est le paramètre par défaut avec KDE/Debian que c'est la cas sur tous les KDE (sur Mandriva et SuSE, c'est bien configuré par défaut).
[^] # Re: ...
Posté par serge_kara . Évalué à 2.
(surtout le prend pas mal, cf ta signature, trop tente, pas pu resiste =) )
[^] # Re: ...
Posté par Anonyme . Évalué à 1.
[^] # Re: ...
Posté par serge_kara . Évalué à 2.
[^] # Re: ...
Posté par inico (site web personnel) . Évalué à 3.
Si tu multiplie les repertoire contenant les binaires (déja qu'avoir /opt et /usr/local/bin ...) , tu vas avoir une variable $PATH qui va devenir énorme et ralentir le systéme.
[^] # Re: ...
Posté par serge_kara . Évalué à 1.
on est d'accord,
/usr/bin c'est l'equivalent de %windir%/system32 sur windows ...
ben chez moi, j'ai mplayer, firefox, konqueror, totem et tout ce genre de choses dans mon /usr/bin, pas franchement l'equivalent de system32 sous windows.
Et windows est l'exemple meme a ne pas suivre : rien n'est accessible en moins de 5 ou 6 clicks dans un repertoire surcharge et plein comme un oeuf, inaccessible (m'etonnerait pas que ca soit volontaire d'ailleurs, pour eviter que l'utilisateur ne fourre son nez dedans justement).
[^] # Re: ...
Posté par phoenix (site web personnel) . Évalué à 1.
/bin => commande de base
/sbin => commande administrateur de base
Elles doivent permettre d'administrer le système quand un gros problème fais que tu ne peux pas monté la partition /usr (ca mets déjà arrivé)
/usr/bin => commande utilisateur (tous les applications accecible à l'utilistaure et ne necessitant pas d'être utilisable en mode single)
/usr/sbin => commande administrateur (par exemple les interfaces grapiques des applis au dessus, ou des applis moin critique)
[^] # Re: ...
Posté par Prosper . Évalué à 2.
et a peu pres tous les démons/serveurs.
[^] # Re: ...
Posté par Nicolas Dumoulin (site web personnel) . Évalué à 2.
Je suis sous KDE, mais je pense pas que ce soit spécifique à KDE. Ce doit venir de là :
http://freedesktop.org/wiki/Standards_2fmenu_2dspec
[^] # Re: ...
Posté par totof2000 . Évalué à 2.
Ben moi aussi. C'est d'ailleurs ce que je reproche aux distributions "modernes": ne pas séparer le système de base des applis.
Personnellement j'aime beaucoup l'approche NetBSD: les softs installes via pkgsrc dans /usr/pkg/(avec les arboresceces bin, etc and co ...), ce qui est installe hors pkgsrc dans /usr/lcal/bin, et le systeme de base dans /bin(/sbin) et /usr/bin(ou sbin) selon la description faite dans un post precedent.
[^] # Re: ...
Posté par Olivier Serve (site web personnel) . Évalué à 1.
[^] # Re: ...
Posté par Bapt (site web personnel) . Évalué à 1.
rien dans usr/local permattant ainsi de pouvoir installer tes softs à la main, sans les mélanger avant ceux de portage.
pkgsrc, ce n'est pas les ports (même si c'est très proche) les ports c'est sur OpenBSD et FreeBSD, le principe pour les install depuis les ports :
dans /usr/X11R6 : tout ce qui lié directement à X
dans /usr/local : tout ce qui n'est pas lié directement à X
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
# Utiliser les mots, les mots justes
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 10.
Que la méthode dénoncée soit une méthode "brutale", admettons, mais la comparer au National Socialism du siècle précédent, j'appelle ça mérite le point Godwin.
Et le titre de ton journal n'aide pas à se décrocher de cette idée.
[^] # Re: Utiliser les mots, les mots justes
Posté par dab . Évalué à 8.
[^] # Re: Utiliser les mots, les mots justes
Posté par B16F4RV4RD1N . Évalué à 10.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Utiliser les mots, les mots justes
Posté par Anonyme . Évalué à -10.
Il faut voir le bon côté des choses : Linus a offert une porte de sortie honorable aux Gnomeux ! Ils ont en effet un prétexte pour couper court à la discussion en invoquant le point godwin, de manière à ne pas avoir la rude et quasi-impossible tâche d'essayer d'argumenter pour défendre les choix souvent débiles fait par des programmeurs à l'égo surdimensionné qui prennent les utilisateurs pour des neuneus.
[^] # Re: Utiliser les mots, les mots justes
Posté par golum . Évalué à 3.
Je connaissais la langue d'Oc et la langue d'Oil, mais je ne savais pas que la ville de Blois avait participé si activement à notre culture nationale.
Je pense que c'est cette forme d'ostracisme à l'égard des blésiens (aurait dit Maître Capelo) qui te vaut cette descente en règle ;-)
[^] # Re: Utiliser les mots, les mots justes
Posté par Anonyme . Évalué à 2.
J'en dis que les Bloiseux n'ont qu'à aller se faire
N'est pas ministre de l'Éducation Nationale qui veut :-)
[^] # Re: Utiliser les mots, les mots justes
Posté par dab . Évalué à 2.
[^] # Re: Utiliser les mots, les mots justes
Posté par golum . Évalué à 3.
J'aurais préféré fasciste on aura gardé le même suffixe comme ca o:)
[^] # Re: Utiliser les mots, les mots justes
Posté par xumelc . Évalué à 0.
# my 2 cents, by Kent Brockman
Posté par serge_kara . Évalué à 8.
Trop facile sinon de s'egarer dans differentes directions et de faire des choses incoherentes/qui collent pas ensemble.
Gnome c'est un gros gros projet, l'IHM c'est deja pas simple, ca l'est encore moins quand on est la tete dans le guidon a developper et utiliser le produit tout les jours, il faut une ligne directrice clairement definie par une et une seule personne.
L'autre concept de base, toujours a mon sens, c'est : si t'es pas capable de savoir _-=*TRES EXACTEMENT*=-_ comment implementer/presenter une feature, tu l'implementes pas.
Mieux vaut rien que quelque chose mal fini/pense/fait.
C'est sur que ca colle pas trop avec un developpement ouvert ces 2 concepts, et je pense que c'est une des raisons qui font que l'experience utilisateur avec un gnome ou un kde n'est pas celle que ces bureau meriteraient.
C'est mon avis a moi que j'ai, zetes pas oblige de le partager, mais si vous le partagez pas, je serais enchante de savoir pourquoi :-P
serge, troll dodger (enfin j'aimerais bien)
[^] # Re: my 2 cents, by Kent Brockman
Posté par Olivier Serve (site web personnel) . Évalué à 7.
Et ne jamais oublier qu'une dictature finit généralement très mal. ;-)
2) Sur le fait de ne pas implémenter..., je ne suis pas d'accord car ça permet de tester des idées potentiellement intéressantes. Le mode de développement libre permet d'expérimenter et d'améliorer ou au contraire abandonner une idée.
Toute innovation ne peut être atomique. Certaines ont besoin de mûrir et sont construites au fur et à mesure.
[^] # Re: my 2 cents, by Kent Brockman
Posté par Yusei (Mastodon) . Évalué à 4.
Ou alors tu l'implémentes, mais dans une branche "de développement", pas dans la release officielle. C'est le principal défaut des releases à dates fixes, d'ailleurs: si tu dois sortir une version tous les six mois, tu hésites à entamer des changements qui prendront plus de six mois.
Ou alors tu le fais quand même et tu te fais engueuler par les utilisateurs frustrés (voir par exemple le cas du nouveau menu xdesktop de Gnome, qui n'était plus éditable dans la branche 2.10).
[^] # Re: my 2 cents, by Kent Brockman
Posté par Anonyme . Évalué à 3.
Ce n'est pas du tout le sujet de la discussion. La discussion ne porte pas sur la rigueur, la cohérence, du processus de décision. Elle porte sur ses critères.
« L'autre concept de base, toujours a mon sens, c'est : si t'es pas capable de savoir _-=*TRES EXACTEMENT*=-_ comment implementer/presenter une feature, tu l'implementes pas.
Mieux vaut rien que quelque chose mal fini/pense/fait. »
Drôle de point de vue. Je ne crois pas que les ultra-perfectionnistes soient réellement capable de pondre quelque chose d'utile. Tout d'abord parce qu'en règle générale, ils sont incapable de tenir des délais. Ensuite, parce que personne n'est assez intelligent pour d'avance saisir l'intégralité des tenants et aboutissant d'un problème.
C'est bien une logique d'ingénieur carré de croire qu'on peut tout planifier à l'avancer, tout préparer sur un petit papier. Fait est que c'est sacrement prétentieux que de penser qu'on peut arriver à la perfection sans se confronter au regard extérieur.
Non, il vaut mieux une fonctionnalité imparfaite qu'aucune. On progresse en voyant comment améliorer les choses, pas en restant dans son coin à philosopher sur un idéal.
Les idéaux ne sont des moteurs que quand il y a un minimum d'agissement matériel.
[^] # Re: my 2 cents, by Kent Brockman
Posté par serge_kara . Évalué à 2.
J'ai dit qu'il fallait avoir une idee tres precise de ce qu'on veut faire et de la facon de l'utiliser, pas que ca devait etre parfait au premier build.
Et ca va de paire avec le dictateur qui impose une chose et n'admet aucun compromis.
[^] # Re: my 2 cents, by Kent Brockman
Posté par Anonyme . Évalué à 3.
Toi.
Cf « si t'es pas capable de savoir _-=*TRES EXACTEMENT*=-_ comment implementer/presenter une feature, tu l'implementes pas. »
Inutile de jouer avec les mots. Tu peux changer de point de vue, mais ce que tu racontais ne portait pas sur « ce qu'on veut faire » mais bel et bien sur la qualité de l'implémentation et de sa planification (en français dans le texte).
[^] # Re: my 2 cents, by Kent Brockman
Posté par serge_kara . Évalué à 1.
on doit pas parler la meme langue, desole.
[^] # Re: my 2 cents, by Kent Brockman
Posté par golum . Évalué à 3.
D'autant que si on compare avec le processus de dev de Linux, Linus serait vraiment mal placé de faire des réflexions sur ce point.
[^] # Re: my 2 cents, by Kent Brockman
Posté par Éric (site web personnel) . Évalué à 3.
Donc jusqu'à récement on n'aurait pas eu du tout de sélecteur de fichier sous gnoe/gtk ? (oui, faut avouer que l'ancien il est clairement pourri)
Ah, ça ça aurait été une super idée tiens...
Hé, les fonctions on peut en avoir besoin. Et quand on en a besoin on préfère souvent l'avoir mal présenté que de ne pas l'avoir du tout.
[^] # Re: my 2 cents, by Kent Brockman
Posté par serge_kara . Évalué à 5.
# Joli Godwin
Posté par Jux (site web personnel) . Évalué à 1.
# Et lui ?
Posté par Nahuel . Évalué à 0.
Et Alan Cox il utilise quoi ?
Stallman on sait qu'il utilise emacs ;)
[^] # Re: Et lui ?
Posté par Pascal Terjan (site web personnel) . Évalué à 3.
http://kerneltrap.org/node/9 qui date de 2002 indique :
Alan Cox: That varies. Of choice I generally run xfce but I am frequently running the Gnome + nautilus set up and occasionally KDE because plenty of time is spent beta testing new releases. The only good way to beta test a new release is to run it.
[^] # Re: Et lui ?
Posté par Jérôme Pinot (site web personnel) . Évalué à 3.
D'un autre cote, vu qu'il bosse chez RedHat depuis un moment, ce n'est pas tres etonnant qu'il soit sous Gnome (interface par defaut pour Fedora et consorts).
En repensant a ce qu'a dit Linus, et s'il utilise regulierement SuSE (a confirmer), on peut en venir a penser que le changement recent de Novell pour sa politique d'interface l'ait rendu chatouilleux...
[^] # Re: Et lui ?
Posté par Infernal Quack (site web personnel) . Évalué à 2.
Ce n'est pourtant pas la vision que donne Mandriva :)
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Et lui ?
Posté par Anonyme . Évalué à 10.
Et le raccourci vers emacs dans kicker par défaut ?
Les outils en perl/GTK avec KDE comme bureau par défaut ?
Si, je trouve que finalement, les incohérences des employés reflètent bien les incohérences de la distribution :-)
[^] # Re: Et lui ?
Posté par Pascal Terjan (site web personnel) . Évalué à 2.
KDE est probablement plus utilisé vu que c'est le défaut utilisé par tout les non informaticiens mais j'avais été surpris de voir qu'autant de gens ici utilisent Gnome.
[^] # Re: Et lui ?
Posté par Anonyme . Évalué à 4.
Moi ça ne m'étonne pas tellement certains choix sont incohérents.
L'avantage de Mandriva reste cependant qu'elle n'a pas réellement tranché pour un environnement de bureau en particulier, et ainsi, on en retrouve tout plein plus ou moins bien intégrés (KDE, GNOME, XFCE, e17, IceWM, WindowMaker, *Step, etc.).
L'inconvénient, c'est que ça n'a pas de véritable consistance et c'est loin de la cohérence d'une SuSE (pour le moment, car il semblerait que le staff Novell n'ait rien compris à ce que faisait SuSE jusqu'à présent).
# Du calme!
Posté par gnumdk (site web personnel) . Évalué à 9.
>will, as Linus has, vote with their feet based on how we envision our
>software into being. and they will likely vote in both directions.
>when we spoke about projects having individual identity in Portland, this is
>exactly the sort of thing i had in mind. i know that we have different
>philosophies on things. who here doesn't know that by now? =)
>i also know that as long as we work on commonalities we'll fix things we can't
>fix on our own and we'll all win, regardless of whose approach is "more
>right", "less wrong", "better for aunt tilly" or "completely screwed up".
>Aaron J. Seigo
Voila les propos éclairé d'un devel Kde, histoire de calmer un peu les esprits... Surtout que je pense qu'il a completement raison... Kde me convient plus que Gnome mais ca ne m'empeche pas d'utiliser Gnome en ce moment meme et quand je trouve un truc frustrant(genre plein de truc dans evolution), j'essaye d'en faire part à certains devel gnome...
[^] # Re: Du calme!
Posté par lezardbreton . Évalué à 4.
[^] # Re: Du calme!
Posté par Anonyme . Évalué à 2.
Ce qu'il y a de bien avec KDE, c'est qu'en quelques clics de souris, hop, tu personnalise l'emplacement des boutons et/ou tu rajoutes quelques espaces entre. Chose que je fais systématiquement après l'installation, après avoir mal cliqué pendant des années ;-)
[^] # Re: Du calme!
Posté par SF . Évalué à 3.
[^] # Re: Du calme!
Posté par gnumdk (site web personnel) . Évalué à 2.
# petite précision sans importance
Posté par Ben (site web personnel) . Évalué à 10.
Tout homme qui dirige, qui fait quelque chose, a contre lui ceux qui voudraient faire la même chose, ceux qui font précisément le contraire, et surtout la grande armée des gens d'autant plus sévères qu'ils ne font rien du tout. -- Jules Claretie
[^] # Re: petite précision sans importance
Posté par golum . Évalué à 2.
Doux euphémisme :)
Trop tard les trolls sont lâchés, Garez vous !
# Bravo !
Posté par dwd . Évalué à 5.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Bravo !
Posté par Bronsophile Tramo . Évalué à 3.
Car, si on accuse Theo de Raadt d'être un trolleur ici, Linus a lui aussi des ressources à revendre :)
En étant un peu moins agressif, tu pourras constater que dès le début de linux il avait de très bonnes ressources de ce côté. Cherches sur google le flame entre tanenbaum et linus. (Tanenbaum lui même n'a pas non plus sa langue dans sa poche. Approximativement, il balance à Linus qu'il aurait eu une très mauvaise note s'il avait été son élève, pour avoir osé faire un kernel aussi primitif.)
Les programmeurs de logiciels libres ne sont pas des saints. Après tout, dans une grande entreprise telle que microsoft on y trouve bien des gens pour y faire de la Monkey Dance.
[^] # Re: Bravo !
Posté par Bronsophile Tramo . Évalué à 0.
Voilà :x
[^] # Re: Bravo !
Posté par Mr_Moustache . Évalué à -3.
Tu serais pas journaliste à TF1 ?
[^] # Re: Bravo !
Posté par Bronsophile Tramo . Évalué à 0.
Si tu veux voir un autre genre de flame, un peu moins épicé, fouille du coin des discussions Torvalds - Hans Reiser. Torvalds n'y va pas avec des pincettes quand il a son mot à dire sur quelque chose.
[^] # Re: Bravo !
Posté par Gniarf . Évalué à 2.
# Bronsoir
Posté par Pierre Tramonson . Évalué à 1.
C'est une bonne occasion de passer sur une interface simple, agréable, intuitive et de gauche.
[^] # Re: Bronsoir
Posté par Jiel (site web personnel) . Évalué à 2.
C'est bien d'avoir une interface politiquement orientée. :-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.