As-tu utilisé de façon répétée et en situation réelle les environnement cités ?
Je n'ai pas utilisé intensivement les environnements cités. Juste Unity pendant 2 semaines, ce qui est largement insuffisant.
Par contre, si quelqu'un n'a pas une méthode de travail qui correspond à cet environnement, il aura beau l'utiliser 20 ans, cette personne va toujours trouver l'environnement mal conçu.
Conclusion: le fait de ne pas tester intensivement l'environnement ne permet pas de conclure, mais ça n'implique pas que le fait de tester intensivement l'environnement permet de conclure.
La seule façon de conclure, c'est si TOUT CEUX qui ont testé l'environnement intensivement concluent qu'il y a un problème.
Répondre aux paradigmes de départ est bien sympathique mais si à l'usage on se rend compte que dans de nombreux cas, la solution proposée n'est pas fonctionnelle, je ne vois pas pourquoi il faudrait forcément s'acharner. Peut-être que tout simplement les axiomes n'étaient pas optimums pour un usage réel.
Tout d'abord, je pense que la personne qui s'acharne, c'est la personne qui souhaite rajouter des éléments d'un autre paradigme pour masquer le fait que le paradigme de base est foireux.
Si on déplace les boutons, tu auras l'impression que ça fonctionne mieux. Or, les développeurs continueront à utiliser leur guideline, basé sur les paradigmes foireux, avec ton consentement maintenant que ton problème est réglé.
Pour moi, la solution est bien plus simple: si l'environnement construit autour d'un paradigme A ne me convient pas, j'abandonne l'environnement basé sur A. Au final, si les axiomes sont faux, tout le monde finira par abandonner l'environnement, problème réglé.
Si tout le monde n'abandonne pas l'environnement, c'est qu'il convient à certains. Pourquoi vouloir leur interdire d'utiliser un paradigme avec lequel ils sont à l'aise sous prétexte que tu as calculé que mathématiquement, il faut 0.2 secondes de plus ? Ce qui compte, c'est le bien-être des utilisateurs, pas la longueur des trajets de souris.
C'est d'ailleurs pour ça que j'ai réagi de cette façon à ta critique sur le mouvement de souris et que j'ai accepté les 2 autres: celle sur le mouvement de souris n'est pas en adéquation avec la guideline adoptée par les développeurs (ou du moins sa solution, qui consiste à rendre facile un usage qui n'est pas celui pour lequel l'environnement est conçu).
(c'est un point important: il n'est pas question de refuser de corriger les problèmes, il est question de refuser de mélanger les paradigmes et de partir dans 2 directions opposées avec le même environnement de bureau. Si tu proposes une solution pour diminuer le nombre de trajet sans que cela implique un mélange des genres, alors, je n'ai plus d'objections)
Ensuite, un autre point qui guide ma réflexion est que: il y a de nombreux témoignages de gens qui AIMENT gnome-shell.
La solution la plus réaliste est que l'environnement n'est pas "pas optimum pour un usage réel" mais n'est pas optimum pour TON usage réel.
Quand on regarde la façon d'étudier une matière par exemple, on se rend compte que les gens ont parfois des approches totalement différentes, et que des approches qui fonctionnent très bien pour certains ne fonctionnent pas du tout pour d'autres. Dans ces conditions, je trouve qu'il n'est pas du tout réaliste de prétendre qu'un environnement de bureau qui ne marche pas pour toi implique qu'il ne convient à personne.
Je ne dis en aucun cas dans ce commentaire, comme dans les autres, que j'ai raison, je donne mon opinion. (je ne pensais pas que préciser ça m'aurait été nécessaire dans des commentaires SUR linuxfr)
Donc, nous sommes bien d'accord, tu ne vois pas d'objection à ce que gnome-shell ne soit pas modifié en fonction de tes remarques (puisque tu supposes que tes remarques ne font que refléter ton opinion et ne constituent donc pas des défauts de manière absolue et objective).
[^] # Re: Comparaison de menus Unity/GnomeShell/elementary
Posté par j-c_32 . En réponse au journal GNOME, c'est Apple et Ubuntu c'est Android (Vendredi inside). Évalué à -1.
Je n'ai pas utilisé intensivement les environnements cités. Juste Unity pendant 2 semaines, ce qui est largement insuffisant.
Par contre, si quelqu'un n'a pas une méthode de travail qui correspond à cet environnement, il aura beau l'utiliser 20 ans, cette personne va toujours trouver l'environnement mal conçu.
Conclusion: le fait de ne pas tester intensivement l'environnement ne permet pas de conclure, mais ça n'implique pas que le fait de tester intensivement l'environnement permet de conclure.
La seule façon de conclure, c'est si TOUT CEUX qui ont testé l'environnement intensivement concluent qu'il y a un problème.
Tout d'abord, je pense que la personne qui s'acharne, c'est la personne qui souhaite rajouter des éléments d'un autre paradigme pour masquer le fait que le paradigme de base est foireux.
Si on déplace les boutons, tu auras l'impression que ça fonctionne mieux. Or, les développeurs continueront à utiliser leur guideline, basé sur les paradigmes foireux, avec ton consentement maintenant que ton problème est réglé.
Pour moi, la solution est bien plus simple: si l'environnement construit autour d'un paradigme A ne me convient pas, j'abandonne l'environnement basé sur A. Au final, si les axiomes sont faux, tout le monde finira par abandonner l'environnement, problème réglé.
Si tout le monde n'abandonne pas l'environnement, c'est qu'il convient à certains. Pourquoi vouloir leur interdire d'utiliser un paradigme avec lequel ils sont à l'aise sous prétexte que tu as calculé que mathématiquement, il faut 0.2 secondes de plus ? Ce qui compte, c'est le bien-être des utilisateurs, pas la longueur des trajets de souris.
C'est d'ailleurs pour ça que j'ai réagi de cette façon à ta critique sur le mouvement de souris et que j'ai accepté les 2 autres: celle sur le mouvement de souris n'est pas en adéquation avec la guideline adoptée par les développeurs (ou du moins sa solution, qui consiste à rendre facile un usage qui n'est pas celui pour lequel l'environnement est conçu).
(c'est un point important: il n'est pas question de refuser de corriger les problèmes, il est question de refuser de mélanger les paradigmes et de partir dans 2 directions opposées avec le même environnement de bureau. Si tu proposes une solution pour diminuer le nombre de trajet sans que cela implique un mélange des genres, alors, je n'ai plus d'objections)
Ensuite, un autre point qui guide ma réflexion est que: il y a de nombreux témoignages de gens qui AIMENT gnome-shell.
La solution la plus réaliste est que l'environnement n'est pas "pas optimum pour un usage réel" mais n'est pas optimum pour TON usage réel.
Quand on regarde la façon d'étudier une matière par exemple, on se rend compte que les gens ont parfois des approches totalement différentes, et que des approches qui fonctionnent très bien pour certains ne fonctionnent pas du tout pour d'autres. Dans ces conditions, je trouve qu'il n'est pas du tout réaliste de prétendre qu'un environnement de bureau qui ne marche pas pour toi implique qu'il ne convient à personne.
Donc, nous sommes bien d'accord, tu ne vois pas d'objection à ce que gnome-shell ne soit pas modifié en fonction de tes remarques (puisque tu supposes que tes remarques ne font que refléter ton opinion et ne constituent donc pas des défauts de manière absolue et objective).