fenêtres macOS nécessitant un clic explicite pour être actives, avant de pouvoir cliquer sur les éléments de l'interface utilisateur à l'intérieur

Je suis un nouvel utilisateur Mac, ayant reçu un MacBook Pro lorsque j'ai commencé un nouveau travail il y a trois mois. Un utilisateur Windows et Linux auparavant, je m'habitue maintenant assez aux différences avec l'utilisation de l'environnement de bureau d'Apple.

Une chose qui me ralentit encore un peu est l'exigence de cliquer explicitement dans une fenêtre d'application pour la rendre active, avant que les éléments de l'interface utilisateur à l'intérieur de cette fenêtre puissent interagir avec.

Par exemple, si j'ai deux fenêtres de navigateur ouvertes côte à côte avec celle de gauche active, il faut deux clics pour suivre un lien dans la fenêtre de droite: un pour activer la fenêtre, un pour cliquer sur le lien.

Cela contraste avec Windows ou Linux, où vous pouvez cliquer sur un élément d'interface utilisateur dans une fenêtre inactive et ce simple clic activera à la fois la fenêtre et l'élément qu'il contient.

Un problème similaire essaie de copier et coller du texte entre les fenêtres. Je peux sélectionner et copier du texte dans un terminal ou un éditeur actif, puis le coller dans un autre avec «clic droit, Coller» mais cela n'active pas la fenêtre. Je dois toujours cliquer avec le bouton gauche de la souris sur la fenêtre pour l'activer avant de pouvoir la saisir.

Sous Windows et Linux, le clic droit pour coller activerait également la fenêtre. Si je collais une commande dans un terminal, je pouvais alors simplement appuyer sur Entrée pour l'exécuter, alors qu'un clic de souris supplémentaire est requis sur mon Mac. Cela semble un peu lourd.

Ce comportement peut-il être ajusté pour ressembler à Windows et Linux?

La réponse est en général "non". Il existe cependant quelques exceptions / solutions de contournement, par exemple:

• Vous pouvez cliquer sur n'importe quel contrôle dans une fenêtre non focalisée à l'aide de Cmd-Click. Cela fera fonctionner directement ce contrôle sans focaliser la fenêtre, ce qui pourrait vous faire économiser un clic dans votre scénario de fenêtre de navigateur côte à côte. Malheureusement, il appartient à chaque développeur d'applications de faire en sorte que cela fonctionne de manière raisonnable, et certaines applications non focalisées exécuteront toujours toute action spéciale attribuée à Cmd-Click, plutôt que de la traiter comme un simple clic.
• Dans Terminal.app, Cmd-clic droit collera le contenu de la sélection principale (le dernier texte que vous avez mis en surbrillance dans une fenêtre de terminal) dans le même ou dans un autre terminal, que ce terminal soit ciblé ou non.
• Spécifiquement pour les applications X11 s'exécutant sous XQuartz.app (qui n'est pas très nombreux de nos jours), vous pouvez spécifier l'option "focus follow mouse" afin que les fenêtres X11 soient focalisées lorsque vous passez la souris dessus. (Il y avait également une option cachée de focus-suit-souris pour les fenêtres Terminal.app, je ne sais pas si cela fonctionne toujours dans El Capitan ou Sierra.)

Sous Windows et Linux, tout ce qui concerne une fenêtre, son application sous-jacente est inclus dans la fenêtre du sujet. Premier exemple: la barre de menus, qui se trouve dans la fenêtre. Sur macOS, la fenêtre active trouve sa barre de menus en haut de l'écran, pas dans la fenêtre (à l'exception de quelques bizarreries anciennes), un processus actif pourrait éventuellement avoir un impact ou être reconnu en dehors de sa fenêtre représentative.

Je doute donc que le commutateur requis soit implémenté dans l'interface utilisateur de MacOS ou qu'il puisse être utilisé dans la couche Unix sous-jacente. Je doute en outre que sa mise en œuvre soit réalisable tant que le menu en haut de l'écran appartient au processus actif. Juste mon 2c.