Si tu peux remplacer un long pipe recherchant des fichiers avec de multiples critères de ouf et exécutant des commandes arbitraires sur le résultat par une GUI, je dis bravo mais d'un autre coté je n'ose imaginer la gueule du clickodrome.
Si en plus tu peux récupérer l'équivalent de la commande et la mettre dans un scheduler pour exécution à heure fixe sur tel répertoire, ou encore pour exécution sur réception d'un appel téléphonique en provenance d'un numéro donné, alors là je m'inclinerais.
Mais encore une fois je doute qu'un truc utilisable dans ces domaines existe (et en tout cas l'effort pour développer une interface graphique dédié à un sous ensemble des problèmes de ce type est monstrueux par rapport à la résolution de l'ensemble complet avec des commandes CLI). Par exemple j'ai essayé un jour de programmer un réveil matin avec Automator et ITunes sous Os X. Verdict : strictement impossible à deviner comment faire, obligé de lire de longs tutoriaux et quand j'admire le résultat je ne vois pas en quoi c'est plus "simple"/"convivial"/"whatever" que de lancer un xmms dans un cron (ou tout autre player qui a le bon gout de se signaler à une instance déjà lancée), voir de balancer un "sleep $((8*3600)) ; mplayer muzikireveil.ogg" dans la première console qui passe par là avant de s'endormir. À vrai dire je pourrais apprendre à bien des personnes de mon entourage cette manière de faire, et vraisemblablement pas à configurer le clickodrome d'Os X.
Il faut arrêter de croire que les interfaces graphiques peuvent tout remplacer. Leur principale limite est l'impossibilité de combiner simplement des opérations élémentaires prises dans un ensemble ouvert avec des méthodes de combinaison elles-même prises dans un ensemble ouvert. Au mieux on pourra combiner un ensemble restreint et fixé d'opérations avec un ensemble restreint et fixé de manière de les combiner, sinon la GUI deviendra inutilisable, et en fait simplement inutile ; tout concepteur censé se retrouverait à concevoir un terminal interprétant un espèce de langage de haut niveau s'il devait résoudre ce pb.
En résumé les GUI ne sont bonnes qu'à résoudre ce pour quoi elles ont été conçues (et ce n'est pas une critique négative, certaines le font très bien !) et je trouverais toujours des exemples (par combinatoire, je pourrais en trouver des milliards) montrant des choses impossibles à faire sans clickodrome dédié et trivial avec une CLI. Bien évidemment il y a aussi des domaines dans lesquels utiliser une CLI est inenvisageable, du moins sans GUI associée.
[^] # Re: J'ai une explication!
Posté par Guillaume Knispel . En réponse au journal Tortoise SVN sous Gnome ? Et bien oui.... Évalué à 6.
Si en plus tu peux récupérer l'équivalent de la commande et la mettre dans un scheduler pour exécution à heure fixe sur tel répertoire, ou encore pour exécution sur réception d'un appel téléphonique en provenance d'un numéro donné, alors là je m'inclinerais.
Mais encore une fois je doute qu'un truc utilisable dans ces domaines existe (et en tout cas l'effort pour développer une interface graphique dédié à un sous ensemble des problèmes de ce type est monstrueux par rapport à la résolution de l'ensemble complet avec des commandes CLI). Par exemple j'ai essayé un jour de programmer un réveil matin avec Automator et ITunes sous Os X. Verdict : strictement impossible à deviner comment faire, obligé de lire de longs tutoriaux et quand j'admire le résultat je ne vois pas en quoi c'est plus "simple"/"convivial"/"whatever" que de lancer un xmms dans un cron (ou tout autre player qui a le bon gout de se signaler à une instance déjà lancée), voir de balancer un "sleep $((8*3600)) ; mplayer muzikireveil.ogg" dans la première console qui passe par là avant de s'endormir. À vrai dire je pourrais apprendre à bien des personnes de mon entourage cette manière de faire, et vraisemblablement pas à configurer le clickodrome d'Os X.
Il faut arrêter de croire que les interfaces graphiques peuvent tout remplacer. Leur principale limite est l'impossibilité de combiner simplement des opérations élémentaires prises dans un ensemble ouvert avec des méthodes de combinaison elles-même prises dans un ensemble ouvert. Au mieux on pourra combiner un ensemble restreint et fixé d'opérations avec un ensemble restreint et fixé de manière de les combiner, sinon la GUI deviendra inutilisable, et en fait simplement inutile ; tout concepteur censé se retrouverait à concevoir un terminal interprétant un espèce de langage de haut niveau s'il devait résoudre ce pb.
En résumé les GUI ne sont bonnes qu'à résoudre ce pour quoi elles ont été conçues (et ce n'est pas une critique négative, certaines le font très bien !) et je trouverais toujours des exemples (par combinatoire, je pourrais en trouver des milliards) montrant des choses impossibles à faire sans clickodrome dédié et trivial avec une CLI. Bien évidemment il y a aussi des domaines dans lesquels utiliser une CLI est inenvisageable, du moins sans GUI associée.