Sélection de la fenêtre X

Les sélections , les tampons de coupe et le glisser-déposer sont les mécanismes utilisés dans le système X Window pour permettre à un utilisateur de transférer des données d'une fenêtre à une autre. Les sélections et le tampon de coupe sont généralement utilisés lorsqu'un utilisateur sélectionne du texte ou d'autres données dans une fenêtre et les colle dans une autre. Le glisser-déposer est utilisé lorsqu'un utilisateur sélectionne quelque chose dans une fenêtre, puis clique sur la sélection et la fait glisser dans une autre fenêtre.

Étant donné que les deux fenêtres peuvent être gérées par deux applications différentes, ces mécanismes nécessitent deux clients différents connectés au même serveur X pour échanger des données. Le protocole de base du système X Window comprend certaines requêtes et certains événements spécifiques à l'échange de sélection, mais le transfert s'effectue principalement à l'aide de l'envoi d'événements et des propriétés de fenêtre, qui ne sont pas spécifiques au transfert de sélection.

Différents types de données peuvent être transférés : il s'agit généralement de texte, mais peut également s'agir d'une image, d'un nombre, d'une liste d'objets, etc. Dans ce qui suit, seul le cas du texte est considéré.

Les méthodes de transfert de données peuvent être classées en actives et passives, selon que le client qui manipule les données sélectionnées doit participer activement au transfert vers un client qui le demande :

Passif

Lorsqu'une donnée est sélectionnée, le client qui gère la fenêtre où cette sélection est effectuée la transfère quelque part, et n'a plus besoin de s'en soucier ;

Actif

Le transfert de données à un client nécessite que le client « détenant » la sélection participe activement à l’échange.

Les sélections et le glisser-déposer sont des mécanismes actifs : après la sélection d'un texte dans une fenêtre, le client qui gère la fenêtre doit prendre en charge activement un protocole de transfert des données vers l'application qui en fait la demande. En revanche, les tampons de coupe sont un mécanisme passif : après la sélection d'un texte, celui-ci est transféré vers un tampon de coupe et y reste même si l'application qui gère la fenêtre se termine et que la fenêtre est détruite. Le presse-papiers X est un mécanisme passif tel que perçu par le client qui détient la sélection, mais il nécessite que le xclipboardclient prenne en charge activement tout transfert de données ultérieur.

Un des avantages des mécanismes actifs est que les données peuvent être converties dans un format différent avant le transfert. En particulier, le client qui reçoit les données peut demander que les données de sélection soient converties dans un format approprié. Si le client expéditeur refuse de le faire, le récepteur peut demander un format différent. Par exemple, un morceau de texte restituant un code HTML peut être transféré sous forme de texte à un demandeur qui ne peut gérer que du texte, mais peut également être transféré sous forme de code HTML si le demandeur peut le gérer. Une telle négociation de format ne peut pas être effectuée par des mécanismes passifs, dans lesquels le client qui détient la sélection (et lui donne la sémantique) transfère la sélection et n'est pas impliqué dans le transfert ultérieur vers un client qui la demande.

Un autre avantage des mécanismes actifs est que de gros volumes de données peuvent être transférés en une séquence de transferts plutôt qu'en un seul. Les mécanismes passifs nécessitent en revanche que toutes les données soient transférées quelque part depuis le propriétaire de la sélection, puis transférées à nouveau vers le client qui en fait la demande.

L'avantage des mécanismes passifs est que le transfert peut être effectué même après la fin de la connexion du client détenant les données. Cela n'est pas possible avec les mécanismes actifs, qui nécessitent que le client détenant les données participe activement au transfert.

Le système X Window prend en charge un nombre arbitraire de sélections ; chaque sélection est identifiée par une chaîne (plus précisément, un atom). La sélection la plus utilisée est la PRIMARYsélection.

Les demandes suivantes sont spécifiques au transfert de sélection, bien que le transfert implique également d’autres demandes :

1. demande de savoir à quelle fenêtre appartient la sélection
2. demande de définition de la fenêtre à laquelle appartient la sélection
3. demande de conversion de la sélection

Le propriétaire de la sélection est généralement la fenêtre dans laquelle se trouve le texte sélectionné, le cas échéant. Lorsque l'utilisateur sélectionne du texte dans une fenêtre, le client qui gère la fenêtre doit indiquer au serveur que la fenêtre est le propriétaire de la sélection.

Lorsque l'utilisateur tente de coller la sélection dans une autre fenêtre, le gestionnaire de cette fenêtre lance un protocole pour obtenir le texte sélectionné de l'autre client. Ce protocole implique les deuxième et troisième requêtes de la liste ci-dessus et n'est pas spécifié par le protocole X mais comme une convention dans le Manuel des conventions de communication inter-clients (ICCCM).

En particulier, le client de destination commence par demander au serveur à quelle fenêtre appartient la sélection. Ensuite, les deux clients transfèrent la sélection via le serveur. Cet échange implique une propriété d'une fenêtre et une donnée arbitraire attachée à la fenêtre. Si le contenu de la sélection est considéré comme suffisamment petit pour être transféré en une seule fois, les étapes qui se déroulent sont les suivantes :

1. le destinataire de la sélection demande que la sélection soit convertie en spécifiant une propriété d'une fenêtre (cela peut être la fenêtre où le texte doit être collé)
2. en réponse, le serveur envoie au propriétaire actuel de la sélection un SelectionRequestévénement ;
3. le propriétaire place le texte sélectionné dans la propriété de la fenêtre que le demandeur a spécifiée en envoyant une ChangePropertyrequête au serveur
4. le propriétaire envoie une requête au serveur pour envoyer au demandeur un message SelectionNotifypour notifier que la sélection a été transférée
5. le demandeur peut désormais lire la sélection dans la propriété de la fenêtre en envoyant une ou plusieurs GetPropertyrequêtes au serveur ;
6. le demandeur détruit le bien ; si le propriétaire a demandé à en être informé, un PropertyNotifyévénement lui est envoyé.

Si le contenu est volumineux, il doit être transféré par morceaux. Dans ce cas, les deux clients expriment leur intérêt pour PropertyNotifyles événements : de cette façon, le propriétaire de la sélection sait quand la sélection a été lue et le demandeur sait quand un autre morceau a été placé dans la propriété.

L' extension XFixes permet aux clients d'écouter les changements de sélection.

La sélection la plus utilisée est la PRIMARYsélection, et est utilisée lorsque l'utilisateur sélectionne des données. La CLIPBOARDsélection est utilisée lorsque l'utilisateur sélectionne des données et demande explicitement qu'elles soient « copiées » dans le presse-papiers, par exemple en appelant « Copier » dans le menu « Édition » d'une application. Une demande associée de « Coller » entraîne l' CLIPBOARDutilisation des données de la sélection.

Au niveau du protocole de base, les sélections PRIMARYet CLIPBOARDne diffèrent pas. Mais le xclipboardclient les fait se comporter différemment. En particulier, lorsqu'un autre client revendique la propriété de la CLIPBOARDsélection, ce programme la demande et l'affiche dans une fenêtre. Toute demande ultérieure pour cette sélection est gérée par xclipboard. De cette façon, le contenu de la sélection survit au client qui l'a copiée.

Les tampons de coupe sont un autre mécanisme de transfert de données, en particulier du texte sélectionné. Ce sont des propriétés de fenêtre de la fenêtre racine , nommées CUT_BUFFER1, etc. Contrairement aux sélections, les tampons de coupe n'impliquent pas d'interaction directe entre les clients. Au contraire, lorsque du texte est sélectionné dans une fenêtre, le propriétaire de la fenêtre copie ce texte dans la propriété de la fenêtre racine appelée CUT_BUFFER1. Lorsque l'utilisateur colle le texte dans une autre fenêtre, le propriétaire de la fenêtre lit cette propriété de la fenêtre racine.

Le xcutselprogramme transfère des données entre les sélections et les tampons de coupe, et le xcbprogramme permet différents types d'accès aux tampons de coupe.

Les tampons de coupe sont considérés comme obsolètes.

Le glisser-déposer dans le système X Window est réglementé par la convention Xdnd. Lorsque l'utilisateur fait glisser le texte sélectionné dans une fenêtre et relâche le bouton de la souris, l'échange de données se fait comme pour la sélection principale. Le glisser-déposer est compliqué par ce qui se passe pendant le glisser-déposer. En effet, lorsque l'utilisateur fait glisser la sélection vers différentes parties du bureau ou d'une fenêtre, il s'attend à pouvoir savoir si le texte peut être déposé ou non. En particulier, la cible doit afficher un retour visuel indiquant si elle accepte ou non le dépôt, et le curseur doit changer pour indiquer l'action qui sera effectuée, par exemple copier ou déplacer.

Dans le protocole Xdnd, la fenêtre où le texte est sélectionné et où le glisser-déposer commence est appelée la source ; la fenêtre sur laquelle le curseur survole est appelée la cible . La communication entre la source et la cible est pilotée par la source car la source « saisit » le curseur. Un échange entre la source et la cible est donc nécessaire pour que la cible sache même que le glisser-déposer est en cours. Puisque la source décide de la forme du curseur, la source doit recevoir une réponse de la cible afin de mettre à jour le curseur. De plus, puisque la cible peut avoir besoin de dessiner un viseur pour indiquer où le largage aura lieu, et puisque l'acceptation du largage peut dépendre de l'emplacement exact du curseur, cet échange doit se produire de manière répétée au fur et à mesure que le curseur se déplace. En fait, même si le curseur ne bouge pas, des messages doivent être échangés pour permettre à la cible de défiler lorsque le curseur est proche d'un bord de la zone de visualisation. Sinon, l'utilisateur ne pourra déposer que sur la partie visible de la cible.

Un programme peut indiquer qu'une fenêtre peut être la cible d'un abandon en créant une propriété nommée XdndAwarequi contient la version la plus élevée du protocole que le programme prend en charge. De cette façon, les applications qui prennent en charge les versions plus récentes peuvent revenir à des versions plus anciennes afin d'interagir correctement. De plus, toutes les applications écrites sans prise en charge de Xdnd seront ignorées.

Lorsque le curseur entre dans la fenêtre cible, la source vérifie la présence de la XdndAwarepropriété sur cette fenêtre. Si cette propriété est présente, un échange commence :

• la source indique à la cible que le curseur est entré dans la cible tout en faisant glisser des données en envoyant un événementXdndEnter
• la cible peut savoir quel type de données est déplacé (texte, image, etc.) en regardant cet événement et éventuellement par une interaction supplémentaire avec la source

Pendant que le curseur est à l’intérieur de la fenêtre cible :

• la source envoie XdndPositiondes événements pour indiquer à la cible où se trouve actuellement le curseur
• la cible répond avec XdndStatusdes événements pour indiquer à la source si les données peuvent être déposées dans la position actuelle
• la source envoie un message XdndLeaveou XdndDroplorsque le curseur a quitté la fenêtre ou que le bouton a été relâché, respectivement

Si l'utilisateur abandonne, la cible demande la sélection à la source comme d'habitude. Lorsque le transfert de la sélection est terminé, la cible envoie un XdndFinishévénement pour indiquer à la source que le transfert a réussi.

En résumé, le protocole est piloté par la source, qui informe la cible de ce qui se passe avec le curseur. En réponse, la cible indique à la source si un dépôt sera accepté ou non. La cible doit également être informée lorsque l'utilisateur relâche le bouton de la souris, car cet événement déclenche une demande régulière de sélection, qui est un protocole piloté par la cible.

Ce qui précède est la description de la convention Xdnd pour le glisser-déposer. Différentes conventions pour le glisser-déposer sont utilisées dans Motif, OffiX et Amulet.

Le protocole Direct Save , abrégé XDS (pour X Window Direct Save Protocol ), est un protocole logiciel qui permet de sauvegarder des fichiers en les faisant glisser vers les fenêtres du gestionnaire de fichiers . XDS est basé sur le protocole XDND .

Les programmes suivants fonctionnent spécifiquement sur des mécanismes de transfert de données :

• xcutsel transfère les données des sélections vers les tampons de coupe ou vice versa
• xclipboard, glipper ( Gnome ), parcellite ( LXDE ) et klipper ( KDE ) sont des gestionnaires de presse-papiers , peut-être aussi wmcliphist
• xcb montre le contenu des tampons coupés et permet à l'utilisateur de les manipuler
• xselection, xclip, xsel et xcopy sont des programmes en ligne de commande qui copient des données vers ou depuis la sélection X. xcopy dispose d'une option de verbosité qui permet de déboguer les problèmes de sélection X. parcellite a également la capacité de lire et d'écrire dans des sélections X spécifiques à partir de la ligne de commande.
• synergy est un outil multiplateforme qui vous permet de partager un presse-papiers sur plusieurs ordinateurs exécutant plusieurs systèmes d'exploitation
• xfce4-clipman-plugin est un « plugin d'historique du presse-papiers pour le panneau Xfce4 » et également un gestionnaire de presse-papiers
• xtranslate recherche des mots dans la sélection X dans un dictionnaire multilingue
• autocutsel synchronise le tampon de coupe et le tampon de sélection