Une carte de recherche avec un véritable effet de verre, sans moteur web

La recherche est une fonction fréquemment utilisée dans un éditeur. Pourtant, nous n’y avions pas touché depuis longtemps, simplement parce qu’elle fonctionnait bien.

La fenêtre de recherche de mote était dans le même cas. Elle occupait toujours deux lignes et, même lorsqu’on l’ouvrait après avoir sélectionné un mot dans le document, le champ de recherche restait vide.

Trois applications apportaient la même réponse

Avant de la modifier, nous avons ouvert la recherche et le remplacement dans un même document sous Typora, MarkText et Obsidian, puis nous avons effectué des captures d’écran. Pour Notion, nous avons consulté la documentation publique. Une fois les résultats réunis dans un tableau, leurs points communs étaient évidents.

La recherche commençait sur une seule ligne. Le remplacement ne se déployait qu’en cas de besoin. Le mot sélectionné était directement inséré dans le champ de recherche. La plupart plaçaient également le nombre d’occurrences dans le champ de saisie et permettaient de passer d’une occurrence à l’autre à l’aide de flèches.

Nous avons décidé que mote suivrait lui aussi ce fonctionnement.

Nous avons réduit l’affichage par défaut à une seule ligne. Le remplacement peut être ouvert avec le bouton de gauche ou avec Ctrl+H. Si la phrase sélectionnée tient sur une seule ligne et comporte au maximum 200 caractères, elle est automatiquement insérée comme terme de recherche.

Lorsqu’il n’existe aucun résultat correspondant, nous indiquons « Aucun résultat » au lieu du chiffre 0. Le champ de saisie est entouré d’une bordure rouge. Cela permet de vérifier immédiatement s’il s’agit d’une faute de frappe ou si le terme est réellement absent du document.

Nous n’avons supprimé qu’une seule ligne, mais une plus grande partie du texte est devenue visible. Le premier résultat de recherche est également moins souvent masqué par la carte.

Nous utilisons bien plus souvent la recherche que le remplacement. Si une fonction occasionnelle reste toujours déployée, chaque tâche fréquente en paie systématiquement le prix.

Nous n’avons pas tout modifié pour imiter les autres éditeurs. Nous avons conservé la carte flottante en haut à droite ainsi que le bouton des options. Si nous avons examiné d’autres produits, ce n’était pas pour les copier. C’était pour distinguer les conventions familières des choix propres à mote.

Le texte sous la carte devient réellement flou

La carte de recherche ressemble à du verre. Ce n’est pas un simple effet. Le corps du texte situé sous la carte est réellement redessiné avec un effet de flou.

Au début, nous avions décidé de supprimer complètement cet effet sous Linux. Le moteur de rendu de GTK ne permet pas d’échantillonner la surface située derrière un widget frère. De plus, comme l’arrière-plan change à chaque défilement du document, il aurait fallu le recalculer à chaque image. Nous avons estimé qu’un affichage rapide était plus important qu’un bel affichage.

La solution a consisté à faire dessiner l’écran flou directement par l’éditeur, au lieu de rendre la carte elle-même floue.

Lorsqu’il dessine le document, l’éditeur redessine une fois de plus uniquement la partie couverte par la carte. Lors de ce second rendu, il applique un flou de 18 px, puis la carte ajoute seulement une légère teinte par-dessus.

Seules les lignes réellement visibles sous la carte sont redessinées, et cette opération a lieu dans une image qui devait de toute façon être rendue. Au repos, le nombre d’images programmées reste donc de 0.

L’en-tête fonctionne de la même manière. Lorsque le document défile, le titre passe sous l’en-tête et devient naturellement flou. Comme l’image nette et l’image floue sont dessinées au même instant, elles restent parfaitement alignées.

Nous avons placé une bordure de 1 px autour du verre à la place d’une ombre. Sur un document blanc, une ombre seule ne permettait pas de distinguer facilement les contours. Nous avons également laissé un espace de 24 px entre la carte et le bord droit de la fenêtre afin que l’ombre reste visible.

Nous n’avons ajouté aucune animation d’apparition. Une personne qui appuie sur Ctrl+F sait déjà ce qu’elle veut chercher. Même une courte mise en scène devient alors une attente. La carte s’ouvre dès que l’on appuie sur la commande et ressemble à du verre dès la première image.

Nous avons aussi retrouvé les résultats de recherche qui nous échappaient

Après avoir allégé l’écran, nous avons remarqué certains endroits où les résultats de recherche n’étaient pas correctement affichés.

Les résultats à l’intérieur des tableaux n’étaient pas colorés. En mode lecture, la position du surlignage était décalée. Dans le code en ligne et les passages déjà surlignés, la couleur d’arrière-plan existante masquait l’indication de recherche.

Chaque problème avait une cause différente.

Dans les tableaux, il fallait calculer séparément la position de chaque cellule. En mode lecture, il fallait réajuster la position des symboles masqués. Pour les textes dotés d’une couleur d’arrière-plan, il fallait dessiner l’indication de recherche en premier.

Nous avons corrigé la méthode de calcul des positions et l’ordre de rendu des couleurs, ce qui a résolu les trois problèmes.

Les résultats de recherche sont affichés en jaune. Seul le résultat actuellement consulté apparaît en orange. Nous utilisons les mêmes couleurs à l’écran ainsi que dans les fichiers PDF et HTML.

Nous n’avons pas modifié la couleur du texte. Un surligneur ne peint pas par-dessus les lettres : sa couleur se place entre le papier et le texte.

Le verre a un coût

Lorsque l’on fait défiler le document avec la carte de recherche ouverte, l’effet de flou est recalculé pour chaque image. Seule la partie située sous la carte est redessinée, mais cela ne supprime pas entièrement le coût.

C’est pourquoi nous n’empilons pas plusieurs couches de verre. Nous ne l’utilisons que pour l’en-tête, la barre latérale et l’unique carte actuellement ouverte.

Le verre n’est pas un matériau décoratif, mais un budget à répartir dans les limites des performances disponibles.

Rendre la fenêtre de recherche plus belle et la rendre plus légère semblaient être deux objectifs opposés. Pourtant, à la fin, il ne restait qu’une seule question.

Quand cet écran doit-il être redessiné ?