• [^] # Re: Interrupteur

    Posté par (site web personnel, Mastodon) . En réponse à la dépêche Sortie officielle de GTK+ 3.0 !. Évalué à 3.

    Quittons le monde du logiciel, et faisons une promenade IRL :

    Si par exemple dans un circuit électrique non alimenté je met sur "on" l'interrupteur en face de ma lampe, elle ne s'allume pas.
    Lorsque je vais mettre le courant, la lampe va s'allumer.

    Si j'ai un écran à diode, avec autant d'interrupteurs que de diodes, je peux préparer un joli dessin lumineux qui ne s'affichera que lorsque je mettrais le courant. C'est exactement la même chose que de cocher des cases et d'appuyer sur "valider".

    De même, je pourrais faire ma manipulation alors que le courant est là, et alors au fur et à mesure de mes actions sur les interrupteurs, mes lampes vont s'allumer.

    L'interrupteur n'implique une réaction immédiate que parce que la logique de mon système est conçu ainsi. Je ne peux avoir un interrupteur qui implique une réaction immédiate que parce que j'ai conçu mon système ainsi.

    Un pilote d'avion avant d'allumer son moteur il doit appuyer sur plein de boutons et actionner un certain nombre d'interrupteurs. Par contre, il a des boutons et divers actionneurs qu'il actionnera ou devra actionner en cours de route.

    Ce qui fait que l'interrupteur implique une action immédiate ou non, c'est une question de conception du système, pas d'interrupteur.
    Dans la vraie vie il n'y a pas de case à cocher, il n'y a que des interrupteurs.

    Dans la vraie vie, un actionneur à deux états c'est un interrupteur.
    Une case à cocher dans une IHM c'est un interrupteur. Pourquoi avoir fait visuellement des cases à cocher plutôt que des interrupteurs ? c'est une autre question, mais une case à cocher ou un interrupteur c'est la même chose : c'est une machine logique à deux états vrai/faux, oui/non, tout de suite/plus tard, toujours/jamais...

    Le fait que l'action sur l'interrupteur soit prise en compte à l'exécution ou seulement après un autre évènement, c'est la conception du système qui détermine cela, pas le bouton.

    Que je coche la case "couper le son" et que cela se fasse tout de suite parce qu'il faut que je réponde au téléphone, ou bien que je coche la case "éteindre l'ordinateur à la fin de la gravure" et que cela soit pris en compte effectivement à la fin de la gravure, parce que je vais me coucher, c'est l'application qui veut ça, pas le widget.

    En électricité, je peux mettre mes interrupteurs en parallèle (action immédiate pour chacun) ou en série (action dans un futur lointain pour le second), par exemple. Je n'ai pas deux types d'interrupteurs pour ces deux montages.

    Je dénonçais le fait que le widget "interrupteur" n'était en fait qu'un doublon pour coder en dur une apparence différente, et bien je dénonce (grave :) le fait que le widget "interrupteur" ne soit en fait qu'un doublon pour coder en dur une gestion des évènements différentes et un schéma logique différent.

    De plus, dans Gnome, la philosophie c'est d'avoir des actions actives et propagées dès l'action, de ne pas avoir un bouton "valider les préférences" mais "fermer les préférences", le doublon case/interrupteur est d'autant plus idiot pour Gnome qui veut simplifier l'IHM. Au final, même si l'effet est dans un avenir lointain, la configuration est prise en compte tout de suite.

    Dans Gnome il y a des cases à cocher "ne pas demander de mot de passe à la sortie de veille", ou bien "mettre en veille à l'inactivité" ou bien "couper le son", etc. Les effets sont immédiats ou dans un avenir lointain, ou soumis à d'autres évènements ou non, ce sont dans tout les cas des cases à cocher, on peut toutes les remplacer par des interrupteurs, c'est la même chose.

    ce commentaire est sous licence cc by 4 et précédentes