1. John Siracusa
    1. Mountain Lion
      1. Introduction
      2. Achat et installation
      3. Changements d'interface (1)
      4. Changements d'interface (2)
      5. Changements d'interface (3)
      6. Applications (1)
      7. Applications (2)
      8. Applications (3)
      9. Applications (4)
      10. Applications (5)
      11. iCloud(1)
      12. iCloud(2)
      13. iCloud(3)
      14. Gatekeeper(1)
      15. Gatekeeper(2)
      16. Retina et HiDPI
      17. Fourre-tout (1)
      18. Fourre-tout (2)
      19. Fourre-tout (3)
      20. Fourre-tout (4)
      21. Fourre-tout (5)
      22. Fourre-tout (6)
      23. Recommandations
      24. Deux pères, un fils
    2. Lion
      1. Introduction
      2. Installation
      3. Revoir les fondamentaux
      4. Redimensionnement des fenêtres
      5. Et voici pour les cinglés
      6. La gestion des fenêtres
      7. Le modèle de document
      8. le modèle des processus
      9. Les éléments internes (1)
      10. Les éléments internes (2)
      11. ARC
      12. Le système de fichiers
      13. Ses modifications dans Lion
      14. Documents, résolution
      15. Le Finder
      16. Mail, Safari
      17. Fourre tout (1)
      18. Fourre tout (2)
      19. Recommendations
    3. Snow Leopard
      1. Introduction
      2. Le ticket d'entrée
      3. L'installation
      4. Nouvel aspect
      5. Détails internes
      6. Quick Time X
      7. Système de fichiers
      8. Faire plus avec plus
      9. LLVM et Clang
      10. Les blocs
      11. Concurrence
      12. Grand Central Dispatch
      13. Asynchronicité
      14. Open CL
      15. La différence...
      16. Quick Time Player
      17. Le Dock
      18. Le Finder
      19. Exchange
      20. Performances
      21. Fourre tout (1)
      22. Fourre tout (2)
      23. Le futur
    4. Leopard
      1. Introduction
      2. L'héritage
      3. Nouvel aspect 1
      4. Nouvel aspect 2
      5. Le noyau
      6. 64 bits
      7. FS Events
      8. Core animation
      9. Quartz GL
      10. Core UI
      11. Détails internes
      12. Le Finder
      13. Le Dock
      14. Time Machine
      15. Performances
      16. Pot pourri
      17. Demain
    5. Tiger
      1. Introduction
      2. Retour sur le passé
      3. Nouvel aspect de Tiger
      4. Mises à jour du noyau
      5. Le lancement
      6. Les méta-données
      7. Attributs étendus
      8. Listes de contrôle d'accès
      9. Spotlight 1
      10. Spotlight 2 : analyse et potentiel
      11. Types de fichiers
      12. Méta-données : la fin
      13. Quartz
      14. Quartz 2D Extreme
      15. Core Image
      16. La vidéo sous Tiger
      17. Dashboard
      18. Le Finder
      19. Les performances
      20. Pot pourri
      21. Conclusion
    6. Panther
      1. Introduction
      2. Les précédents
      3. L'installation
      4. Nouvel aspect
      5. Performances
      6. Changement rapide d'utilisateur
      7. Gestion des fenêtres
      8. Exposé
      9. Le Finder
      10. Performance du Finder
      11. Toujours le même
      12. Safari
      13. XCode
      14. Conclusion
    7. Jaguar
      1. Introduction
      2. Le nom
      3. L'installation
      4. Modifications d'Unix
      5. Dévelopeurs...
      6. Quoi de neuf
      7. Rendezvous
      8. Quartz Extrême
      9. Performance
      10. Compositions
      11. Le Finder
      12. Applications
      13. Sherlock
      14. Le portrait
    8. Puma
      1. Prelude
      2. Introduction
      3. Installation
      4. Réglages système
      5. Performance
      6. Redimensionnement des fenêtres
      7. Utilisation de la mémoire
      8. Diagnostics de mémoire
      9. L'environnement Classique
      10. L'interface Utilisateur
      11. Le Finder
      12. Extensions de fichiers
      13. Divers, conclusion
    9. Cheeta (Mac OS X 10.0)
      1. Qu'est ce que Mac OS X
      2. Installation
      3. Le démarrage
      4. Utilisation de la RAM
      5. Performance
      6. Performance des applications
      7. Stabilité
      8. L'interface utilisateur
      9. Le Finder
      10. Le navigateur du Finder
      11. Le Finder (divers)
      12. L'interface utilisateur
      13. Os X Classique
      14. Système de fichiers
      15. Unix
      16. Applications
      17. Conclusion
    10. Les débuts de MacOsX
      1. 1999 : OSX DP2
      2. 2000 : Quartz et Aqua/a>
      3. Fin de la lune de miel
      4. la première bêta publique
      5. 2001 : Mac OS X 10.0
      6. Un investissement
    11. Finder Spatial
      1. Introduction
      2. Interfaces spatiales
      3. Le Finder spatial
      4. Le concierge
      5. Un nouveau Finder
      6. Le browser
      7. Le browser spatial
      8. Finder et méta-données
      9. Les modèles
      10. Pensées finales

SpotLight




Quand j'ai commencé à parler des méta-données sous Tiger, Spotlight est sans doute la première chose qui me vint à l'esprit. Bien que ce soit la caractéristique de méta-données technologiquement la moins risquée de Tiger, elle va être, de loin, la plus importante dans une utilisation journalière.

C'est un exemple de ce que je voulais dire précédemment quand j'imaginais que Steve Jobs passe plus de temps à voir les choses de haut, et moins à se préoccuper de détails techniques. Spotlight est très simple, technologiquement parlant, mais il résout un problème essentiel. Et ce qui est plus important, c'est qu'il le fait en laissant la porte ouverte à des améliorations dans le futur. Mais, revenons un peu en arrière. Qu'est-ce que Spotlight ?

Je vais décrire Spotlight en 3 parties : ce que fait Spotlight (les fonctionnalités), comment il le fait (l'implémentation), et à quoi ressemble l'interface utilisateur. Commençons par décrire que que fait Spotlight.

Fonctionnalité de Spotlight

Spotlight est un service du système qui accepte une requête, et renvoie tous les objets du système de fichiers (fichiers et dossiers) qui satisfont cette requête. N'importe quelle propriété de l'objet du système de fichiers peut être testée comme élément de la requête : nom de fichier, date, taille, etc...

La requête peut (heureusement) contenir une logique arbitrairement complexe. Voici un exemple (conceptuel) de requête .
listing

Autorisez-moi à faire une digression...

Notez les parenthèses qui délimitent la première sous-clause de la requête. Apple imagine qu'il y a si peu d'utilisateurs finaux qui comprennent ce concept (une logique booléenne imbriquée) que cela ne vaut pas le temps et l'effort d'en rajouter le support dans chacune de ses applications existantes qui inclut des requêtes d'une forme ou d'une autre.

Par exemple, je voudrais être capable de faire une liste de lecture intelligente dans iTunes à l'aide de la requête suivante :
listing

Je ne crois pas que c'est trop demander. (Oui, je sais que ça peut être simulé en créant de multiples listes de lecture, et en les référençant à partir d'autres listes de lecture, mais c'est encore plus compliqué et embarrassant qu'une implémentation directe de la logique booléenne imbriquée).

La même chose vaut pour Apple Mail, et pour être honnête, même pour le client e-mail surdoué de Microsoft, Entourage. Oui, c'est une de mes sources d'ennui. Je pense que les requêtes sans le support d'une logique booléenne imbriquée n'ont à peu près aucun sens.

L'équipe des APIs de Spotlight semble avoir partagé cette opinion. Les requêtes Spotlight peuvent être arbitrairement complexes. Malheureusement, l'interface utilisateur par défaut ne propose pas ces possibilités, mais au lieu de cela, retombe dans le style de construction de requête beaucoup plus limité de iTunes/Mail. (Voyez les copies d'écran dans la section Interface utilisateur de Spotlight) plus loin.

Je crois qu'Apple a une mauvaise opinion insultante de la capacité des utilisateurs à comprendre la logique booléenne imbriquée. Ils peuvent ne pas savoir comment ça s'appelle, mais le concept est compris intuitivement. Même ma mère m'a déjà demandé comment créer une règle sous Mail qui suppose une logique booléenne imbriquée : "(de A ou de B) et le sujet contient C". J'ai dû lui dire que ce n'était pas possible. Quand elle m'a demandé pourquoi, je lui ai dit qu'Apple pense que peu d'utilisateurs ont besoin de cette possibilité, et que cela peut introduire la confusion. Elle ne fut pas particulièrement satisfaite de cette explication, et je ne le suis pas non plus.

Bon, revenons à Spotlight. En plus de renvoyer simplement une liste des objets du système de fichiers qui satisfont une requête, le service système Spotlight peut aussi sur option envoyer des notifications à chaque fois que l'ensemble des résultats d'une requête change.

Spotlight récupère son information sur les objets du système de fichiers qui satisfont une requête en regardant dans les méta-données du système de fichier, et dans les données du fichier lui-même. Cette information est utilisée pour déterminer si l'objet du système de fichiers doit être inclut dans l'ensemble résultat pour une requête donnée.

Bien que j'aie décrit Spotlight comme un service pour indexer et rechercher des fichiers et des dossiers, il est présenté comme étant aussi capable de trouver des contacts dans le carnet d'adresse, des messages dans Mail, des événements dans iCal, les panneaux des préférences Système, et d'autres items apparemment non associés à des fichiers. Toutes ces choses peuvent apparaître dans les résultats de recherche de Spotlight, et chacune d'elle a une présence dans le système qui peut être associée à un fichier.

Les messages Mail sont les plus simples, chaque message constituant un seul fichier. Les panneaux de préférences Système sont en fait des paquetages (bundles, des dossiers en réalité), tout comme les applications. Les contacts du carnet d'adresses, et les événements de iCal présentent un certain mystère.

Les applications Carnet d'adresses et iCal utilisent des fichiers monolithiques de données et d'index pour stocker leur données, plutôt que des fichiers individuels pour chaque item de donnée (contacts, événements). Le Carnet d'adresses utilise un seul énorme fichier de données (AddressBook.data) et deux fichiers d'index du SearchKit (ABPerson.skIndexInverted et ABSubscribedPerson.skIndexInverted). La situation est similaire avec iCal, qui utilise des fichiers index et données pour chaque calendrier plutôt que pour chaque événement séparé.

Et pourtant, Spotlight va trouver et afficher les contacts individuels et les événements du calendrier. En sélectionner un dans les résultats de recherche de Spotlight va ouvrir l'application correspondante et vous mener directement au contact ou à l'événement.

En réalité, il y a bien des fichiers de données individuels pour les contacts de Carnet d'adresses dans ~/Library/Caches/com.apple.AddressBook/MetaData/, et ces fichiers sont indexés par Spotlight. Mais au lieu d'apparaître dans les résultats de recherche de Spotlight comme des fichiers de données avec des noms bizarres, ils se présentent comme des proxies conceptuels pour les données qu'ils contiennent. A la différence des autres résultats de recherche de Spotlight, il n'y a pas de chemins de fichiers affichés pour les contacts de Carnet d'adresses.

Pour extraire ces données, l'importateur de méta-données du carnet d'adresses définit un nom personnalisé kMDItemDisplayName en utilisant le nom de contact pour les fichiers qu'il importe au lieu du nom de fichier. Les fichiers individuels de données cachés dans ~/Library/Caches/com.apple.AddressBook/MetaData ont une extension ".abcdp". En ouvrir un de n'importe où (pas seulement depuis la fenêtre de résultats de Spotlight) provoque le lancement de l'application Carnet d'adresse, et l'affichage de la personne correspondante. Plutôt étonnant.

Cette situation est exactement la même pour les événements calendrier de iCal. Fichiers de données plus cachés encore, avec des noms obscurs, qui arrivent à être compris par l'application iCal. Les importateurs de méta-données indépendants ont le droit de s'arranger pour faire la même chose.

Cela ressemble un peu à une bidouille, -potentiellement du gâchis- de stocker à la fois un fichier monolithique de base de données, et un paquetage de fichiers de données individuelles pour un ensemble de données, mais Spotlight tel qu'il est aujourd'hui fonctionne obstinément à l'échelle du fichier. Il doit y avoir un fichier individuel situé quelque part dans le système de fichiers pour chaque entrée dans le magasin de méta-données de Spotlight.

Apple est apparemment en train de travailler avec un autre développeur (Microsoft) pour voir ce qui peut être fait dans ce domaine. Voilà ce qu'un représentant de Microsoft avait à dire :

[Spotlight] ne va pas indexer Entourage, et c'est seulement lié à la façon dont Spotlight a été fait comparativement à Entourage. Entourage sauve tout dans un format de base de données, et nous sommes en train de travailler avec Apple pour voir comment Spotlight peut indexer la base de données.

Nous verrons comme Spotlight évolue dans le futur. En même temps, il apparaît comme étant strictement au niveau du fichier, avec des résultats de recherche pour toutes les applications non Apple, qui affichent toujours des fichiers individuels.

Pour terminer, on peut empêcher Spotlight d'indexer un ensemble d'items défini par l'utilisateur : des fichiers, des dossiers, et même des volumes entiers. Toute information sur ces items sélectionnés est effacée du système de stockage des méta-données de Spotlight, et elles ne seront pas ré-indexées.

L'implémentation de Spotlight

Alors que la fonctionnalité fournie par le service système Spotlight est conceptuellement simple, et clairement utile, l'implantation - à la fois derrière le rideau et dans l'interface utilisateur- a ses hauts et ses bas. Démarrons à la base, et allons vers le haut.

Pour que Spotlight puisse être utile, elle doit rassembler l'information concernant chaque fichier. Cette recherche pourrait être faite à l'exécution en réponse à chaque requête. En fait, c'était comme ça dans Panther et dans les précédentes versions de Mac OS X. (A l'exception d'une recherche basée sur le contenu du fichier. Panther et les versions précédentes avaient un processus en tâche de fond qui indexait les contenus de fichiers).

Le format de volume HFS+ stocke la plupart des méta-données d'un fichier en un seul endroit (le "catalogue") et est de ce fait bien adapté à des recherches rapides en temps réel basées sur ces méta-données. Dans Panther, je peux explorer la totalité de mon disque de démarrage (95 771 dossiers, et plus d'un demi million de fichiers) pour rechercher, par exemple, tous les fichiers qui contiennent "apple" en 12 secondes environ. C'est très rapide.

Spotlight vise à être beaucoup, beaucoup plus rapide. Pour cela il doit récupérer les méta-données auparavant et les stocker dans un index. Quand la requête est lancée, seul l'index doit être consulté. La totalité du disque, ni même le catalogue entier, n'ont pas besoin d'être explorés.

Les index pré-existants permettent des recherches très rapides, mais elles ont aussi un problème potentiel. Un index peut facilement perdre sa synchronisation avec l'état courant du système de fichiers, et un index dépassé n'est pas très utile. Pour fournir des résultats précis, l'index doit refléter avec précision l'état de tous les fichiers, "en temps réel".

C'est une exigence difficile. Un processus en tâche de fond appelé périodiquement est évidemment insuffisant. Quelle que soit sa fréquence de fonctionnement, il serait impossible de l'empêcher d'être dépassé à un moment ou à un autre. La solution de Tiger a été de faire de l'importation des méta-données un élément qui participe aux entrées/sorties de fichiers au niveau du noyau.

Dans Tiger, les méta-données de fichiers sont rassemblées par un ensemble de greffons d'importation, un pour chaque type de fichier. Tiger est livré avec des greffons d'importation pour la plupart des types de fichiers connus : images JPEG, fichiers texte, PDFs, etc... Les développeurs sont encouragés à écrire des greffons pour importer les méta-données de leurs propres formats de fichiers. S'il y a plusieurs greffons pour un type particulier (par exemple, un importateur de méta-données pour une image générique, et un autre pour une image JPEG), c'est le greffon le plus spécifique qui l'emporte. Autrement dit, un seul greffon est utilisé pour chaque fichier.

Chaque importateur de méta-données est chargé de parcourir le fichier, et de renvoyer les méta-données qu'il a pu récupérer à partir des structures de méta-données du système de fichiers, du contenu du fichier, et de tout ce qu'il veut bien prendre en considération. Les méta-données sont renvoyées sous la forme d'un ensemble de paires clé/valeur, qui est rajouté à l'entrée d'index pour le fichier.

Les greffons d'importation de méta-données sont stockés sous forme de dossier Spotlight dans l'un ou l'autre des dossiers de la Bibliothèque. Comme d'habitude, les localisations les plus spécifiques ont la préséance : ~/Library/Spotlight supplante /Library/Spotlight, et ainsi de suite.

Chaque entrée/sortie de fichier qui passe par le noyau de Tiger déclenche le greffon d'importation approprié. Cette intégration au niveau du noyau garanti que les indexes sont toujours à jour.

Il y a un détail important dans la phrase précédente. Ce n'est vrai que si l'entrée/sortie de fichier passe par le noyau de Tiger. Comment est-il possible pour une entrée/sortie de fichier de ne pas passer par le noyau ? Et bien, cela passera toujours par un noyau, mais pas nécessairement par le noyau de Tiger. Voici quelques exemples de scénarios où des modifications du système de fichiers ne sont pas intégrés immédiatement à l'index de Spotlight.
• Vous redémarrez sous Panther, ou sous une version antérieures de Mac OS X, et créez ou modifiez quelques fichiers.
• Un disque externe est retiré de votre Mac, et utilisé avec un ordinateur non Tiger (Mac ou PC) qui crée ou modifie des fichiers sur le disque
• Votre Mac est monté en disque cible sur un ordinateur non Tiger (Mac ou PC), qui crée ou modifie des fichiers dessus.

Il y a évidemment un autre exemple beaucoup plus courant : le démarrage de Tiger pour la première fois. A ce moment là, rien n'est indexé. Ce cas est traité de la même façon que les trois cas précédents : Tiger va démarrer un processus d'indexation en tâche de fond pour enregistrer les modifications non indexées.

Quand un utilisateur démarre pour la première fois sous Tiger, le processus d'indexation de Spotlight initialise les indexes Spotlight. Pendant que le processus d'indexation est en cours, aucune nouvelle requête Spotlight ne peut être satisfaite. Cependant, les modifications du système de fichiers faites pendant que le processus d'indexation tourne sont encore prises en compte par le noyau. Si bien que, quand l'indexation initiale est terminée, l'index sera réellement à jour.

Spotlight stocke l'information d'indexage dans un ensemble de fichiers d'index sur chaque volume indexé. Ce sont des fichiers normaux, stockés dans un répertoire normal à la racine du système de fichiers. Le nom du répertoire a changé au cours du développement de Tiger. En ce moment, les fichiers d'index de Spotlight sont stockés dans le répertoire /.Spotlight-V100. Les noms de fichiers et de répertoires ne font pas partie de l'interface publique de Spotlight. Personne, utilisant les APIs de Spotlight n'a besoin de savoir ou de se soucier où et comment l'information est stockée.

Autant que je sache, un index Spotlight sur un volume donné ne stocke que l'information sur les fichiers de ce volume..., bien que l'option "publish" de la commande mdutil suggère que cela ne puisse pas toujours être le cas. D'un autre côté, les média en lecture seule comme les CDs et les DVDs ne sont pas indexés par défaut. Spotlight les explore à la manière ancienne, en parcourant leur contenu au moment de l'exécution d'une requête .

Gardez à l'esprit que, tout comme le format de stockage et l'emplacement des index eux-mêmes, c'est un détail d'implantation qui pourrait changer dans l'avenir. Rien dans les APIs de Spotlight ne présuppose quoi que ce soit en ce qui concerne l'emplacement et le contenu des index.

Les requêtes sont construites en utilisant des objets "prédicats" qui sont assemblés en une structure de données arborescente. Un format de requête en texte est aussi supporté par l'API. Il utilise les parenthèses pour l'imbrication, des opérateurs de comparaison de type C (<, >, <=, >=, ==, !=) , et des opérateurs logiques (||, &&), un seul joker de style shell (*), et des chaînes avec simple ou double quotes , avec le backslash (\) utilisé comme caractère d'échappement.

Trois modificateurs sont autorisés, et peuvent s'appliquer à des clauses individuelles dans une requête :
• c- La comparaison est insensible à la casse.
• d- La comparaison est insensible à un signe diacritique
• w- La comparaison se fait sur la base des mots, et détecte aussi les transitions de casse (haut/bas).

Chaque élément de méta-donnée est stocké dans l'index de Spotlight avec une clé. Apple a défini des clés pour de nombreux attributs courants. Ces clés sont définies comme des constantes symboliques dans un fichier d'entête, et utilisent la convention de nommage Carbon pour les constantes, avec le préfixe "k" . Cela va d'attributs génériques comme kMDItemKeywords, kMDItemTitl et kMDItemComment, à des attributs spécifiques au format, comme kMDItemAudioBitRate, kMDItemMaxAperture et kMDItemLyricist. Il y a plus d'une centaine de ces constantes.

Apple encourage les développeurs à utiliser les clés d'attributs pré-définies quand c'est possible. Cela n'a pas de sens, que chaque format de fichier utilise sa propre clé d'attribut pour "auteur", par exemple. Un ensemble des clés d'attributs courantes est indispensable pour obtenir des résultats utiles.

Si un greffon d'importation de méta-données veut ajouter une attribut qui ne fait pas partie de la liste pré-définie d'Apple, le développeur est libre de définir sa propre clé d'attribut, en respectant la syntaxe DNS-inverse, et des soulignés qui remplacent les points (comme pour les attributs étendus). Par exemple, une valeur de clé pour com_adobe_photoshop_useslayer pourrait être définie par un greffon d'importation de méta-donnée créé par Adobe pour des fichiers Photoshop.

Voilà un exemple de requête Spotlight qui utilise le format texte décrit précédemment.
listing

Cette requête va trouver tout fichier qui commence pas "apple" ou "mac"(insensible à la casse), et dont la taille de fichier est supérieure ou égale à 5 000 octets.

Tiger est livré avec une belle collection d'outils en ligne de commande pour Spotlight, tous commençant par le préfixe "md" (qui signifie "méta-données" pour le cas où vous ne l'auriez pas deviné). La commande mdfind accepte des requêtes textuelles comme celle montrée ci-dessus, et renvoie tous les fichiers qui conviennent. La commande mdls liste tous les noms d'attributs et les valeurs dans les méta-données de Spotlight pour un fichier donné. La commande mdimport force Spotlight à ré-indexer un fichier. La commande mdcheckschema est utilisée pour valider la configuration d'un greffon d'importation particulier de méta-données. La commande mdutil qui doit être lancée par root est utilisée pour gérer les magasins de méta-données de Spotlight. Ces outils sont utiles pour les développeurs qui créent des greffons d'importation de méta-données, ou simplement pour les utilisateurs un peu curieux.

L'interface utilisateur de Spotlight

Tiger affiche l'icône d'une petite loupe dans le coin supérieur droit de la barre de menu. Cliquer dessus affiche le champ de recherche de Spotlight.

Menu Spotlight

le menu Spotlight

Ce menu peut aussi être activé par un raccourci clavier définissable par l'utilisateur. Par défaut, c'est Command-Espace, un emprunt évident à LaunchBar et à Quicksilver, deux applications tierces de recherche rapide.

Remplir le champ de recherche lance une requête Spotlight en temps réel au moment de la frappe. Cela marche comme le champ de recherche dans iTunes et c'est à peu près aussi rapide. Cela se ralentit nettement pour la recherche sur des volumes non indexés comme des disques optiques en lecture seule, mais les résultats de la requête se présentent dès qu'ils sont disponibles. L'interface utilisateur ne se bloque jamais, et attend que tous les résultats arrivent. Elle retarde même le chargement des icônes pour les résultats de recherche, si cela permet d'afficher les résultats plus rapidement. Le temps d'attente ressenti est un général très bon.

Spotlight : résultats de recherche

Le manu Spotlight avec des résultats de recherche.

L'inconvénient, c'est que la liste des résultats tend à se modifier à mesure que de nouveaux résultats arrivent. Cela peut rendre la navigation, et la sélection d'un item du menu plus difficile que ce devrait être. Une meilleure solution serait la recherche dès que l'utilisateur a commencé à faire une sélection,ou de commencer à rajouter de nouveaux résultats seulement tout à la fin de la liste. De toute façon, c'est quand même meilleur que d'attendre tout le block d'interface utilisateur jusqu'à ce que tous les résultats soient disponibles.

Le texte entré dans le champ de recherche est implicitement comparé à un grand ensemble d'attributs. Encore une fois, cela ressemble à iTunes, où une chaîne de recherche est implicitement comparée à artiste, album, nom de piste, et autres.

L'ensemble des résultats est tronqué pour ne montrer que les principaux résultats de chaque catégorie. Le nombre et l'ordre de ces catégories peut être personnalisé en utilisant la vitre des préférences de Spotlight dans Préférences Système. Le menu déroulant des résultats de recherche peut être exploré avec les flèches de navigation. Taper return va ouvrir l'item sélectionné. Le choix principal dans le menu déroulant ouvre une nouvelle fenêtre qui affiche un ensemble plus important de résultats.

Recherche Spotlight

Fenêtre des résultats d'une recherche Spotlight

A partir de cette fenêtre, l'utilisateur peut raffiner la recherche, changer l'ordre de tri ou de groupement , et afficher tous les résultats de chaque catégorie. Une information étendue est disponible pour tous les types de fichiers, avec des pré-visualisations disponibles pour la plupart.

images en vignettes

Une fenêtre de Spotlight, montrant des vignettes d'images.

Quelques catégories ont des pré-visualisations plus élaborées. Par exemple, les images peuvent être affichées sur un diaporam en plein écran. pendant le diaporama chaque image peut être zoomée pour remplir l'écran, ou copiée dans la bibliothèque iPhoto de l'utilisateur, à l'aide d'un seul clic (cela se fait avec une animation de type génie). Ii y a aussi en effet planche de contact, qui assemble toutes les images dans une grille plein écran de vignettes.

Les champs de recherche de Spotlight se montent aussi dans les boîtes de dialogue ouvrir/sauvegarder. Je suppose que cette disposition pourra être utilisée encore plus souvent que le champ de recherche Spotlight de la barre de menus quand les utilisateurs l'auront découverte.

Recherche dans open/savre

Les champs de recherche Spotlight apparaissent aussi dans les boîtes de dialogue ouvrir/enregistrer.

Remarquez le fichier TextEditScreenSnapz001.pdf dans la liste de résultats. Quand j'ai pris cette copie d'écran (avec l'excellent utiulitaire de copie d'écran SnapZPro X) j'ai oublié de préciser que je la voulais en format PNG. Snapz a utilisé le format PDF par défaut à la place. quand j'ai corrigé ma faute, et refait la copie d'écran, j'ai remarqué que le fichier PDF de la copie originale était dans la liste de résultats.

En utilisant la commande mdls mentionnée précédemment, j'ai découvert ce morceau de méta-données associé avec le fichier "TextEditScreenSnapz001.pdf".
listing

Il apparaît que chaque copie d'écran PDF que je prends avec SnapzPro se matérialise dans la chaîne de résultats par la chaîne de recherche "quartz". Je ne sais pas si c'est une bogue ou une caractéristique. C'est habituellement pratique, quand les chaînes recherchées sont comparées simultanément à beaucoup d'éléments de méta-données, mais peut-être que c'est un peu trop étendu.

Si dans le menu "Fichier" du Finder, on choisit "Rechercher...", ou si on tape un raccourci-clavier correspondant, par défaut Command-Option_Espace, cela mène à une fenêtre de recherche "avancée" de Spotlight qui inclut un champ pour une chaîne de recherche, (traité comme celui de la barre de menu de Spotlight), et un nombre quelconque de conditions de recherche supplémentaires.

J'ai mis "avancée" entre guillemets, ci-dessus, parce que la toute puissance du système de recherche de Spotlight n'est pas utilisée dans cette interface, ni dans aucune des interfaces fournies par Apple que j'ai pu trouver. A la place, toutes les conditions sont additionnées en une seule chaîne. L'insistance d'Apple sur l'incapacité de l'utilisateur moyen à comprendre (et le manque de volonté de proposer) des requêtes compliquées frappe à nouveau.

Toute recherche effectuée dans cette fenêtre peut être sauvegardée comme "dossier intelligent". Ce "dossier n'est en réalité rien de plus qu'un simple fichier, avec une extension ".savedSearch". Le fichier contient une sérialisation XML de la requête Spotlight.

Le Finder, et les boîtes de dialogue ouvrir/sauvegarder de Tiger, traitent ces fichiers de façon spéciale, en les affichant comme s'ils étaient des fichiers en lecture seule, contenant les items associés aux requêtes. Ces fichiers intelligents peuvent être placés n'importe où on peut mettre un fichier : dans la barre latérale du Finder, sur le bureau, dans d'autres dossier, et même dans le Dock. Malheureusement, le Dock ne traite pas les dossiers intelligents comme des dossiers. En fait, ils se comportent comme de simples fichiers, ce qu'ils sont effectivement. Beu...

En même temps qu'un dossier intelligent est ouvert dans le Finder, la fonctionnalité de notification de Spotlight maintient son contenu à jour en temps réel. Oui, cela fonctionne réellement en temps réel, comme le montre cette naimation. à droite se trouve un dossier intelligent basé sur la requête "boogawooga". Il ne correspond initialement à aucun fichier. A gauche, se trouve un document TextEdit. et maintenant, c'est l'instant magique...


Mise à jour en temps réel du dossier "intelligent'. Cliquez sur l'image pour démarrer.
La Video nécessite QuickTime 6 or plus récent.

C'est étonnant, ce que quelques trucs du noyau peuvent vous apporter, hein ?

Dans l'ensemble, cependant, l'interface utilisateur de Spotlight trahit la puissance du service lui-même. L'interface utilisateur de Spotlight est est bizarre, maladroite, limitée, et souvent vraiment hostile à l'utilisateur.

Pour commencer, les fenêtres de Spotlight ne semblent appartenir à aucune application. Il y a un précédent, pour des caractéristiques du même type (service du système), qui sont lancées par des applications non évidentes dans Mac OS X. (Exposé est lancé par le Dock, par exemple). Mais Spotlight est différent en ce qu'il a ses propres fenêtres : la fenêtre qui montre "tous les résultats" pour une requête lancée à partir du champ de recherche de la barre de menu, et la fenêtre qui apparaît quand vous pressez (par défaut) Control-Option-Espace pour lancer une nouvelle recherche dans une fenêtre au lieu de la barre de menus.

Ces fenêtres existent dans un no-man's land. Il n'y a pas d'icône du Dock à cliquer, pour visualiser toutes les fenêtres de Spotlight. Les fenêtres de Spotlight n'apparaissent dans aucun menu d'application. Si vous déclenchez le mode " fenêtres d'applications" de Exposé, et parcourez l'ensemble des fenêtres avec la touche tabulation, vous ne verrez pas non plus vos fenêtres Spotlight.

Il n'y a que deux façons d'avoir une fenêtre Spotlight. Ou bien vous la trouvez en recherchant parmi toutes les fenêtres et en cachant les autres, ou vous déclenchz le mode "Toutes les fenêtres" de Exposé, et récupérez l'ensemble des fenêtres.

Au moins, le Finder implémente (et par conséquent possède) sa propre fenêtre de recherche Spotlight, déclenchée avec le menu &Fichier&Rechercher, ou en tapant Command-F. malheureusement, ces fenêtres sont tout à fait embêtantes par elles-mêmes.

D'abord, elles exhibent la schizophrénie maintenant habituelle de la fenêtre du Finder de mac OS X, en passant brutalement sous l'effet d'un seul clic, d'une fenêtre en métal brossé, à une fenêtre "standard". Alors que cette transformation est sensée permettre de distinguer les fenêtres de type "navigateur" des fenêtres de type "dossier" dans des circonstances normales, (et porte un coup mortel à la cohérence spatiale de Finder de Mac oS X), cela n'a rigoureusement aucun sens dans le contexte de Spotlight.

Les fenêtres de recherche du Finder sont par essence des fenêtres de navigation. Tout ce que fait cette possibilité de transformation, c'est de créer encore une autre façon pour des fenêtres, des contrôles et des contenus de surgir sur l'écran sans qu'on les ait sollicités. Je m'attends presque à ce que les contrôles du formulaire de recherche se détachent en tourbillonnant de mon curseur.

Et que penser de ces contrôles ? Les deux incarnations des fenêtres de recherche (Jekyll et Hyde, vous décidez lequel est lequel), ont un champ texte. Dans la version métal, c'est un widget champ de recherche (le champ avec extrémités arrondies) dans la barre d'outils. dans une fenêtre standard, c'est un champ texte rectangulaire au dessus de la zone de contenu de la fenêtre.

fenêtre Spotlight

La fenêtre Spotlight "Trouver" dans la version métal...

fenêtre Spotlight

et dans la version non métal.

Dans les deux cas, il y a deux critères supplémentaires de recherche représentés par les menus pop-up pour les filtres "type" (Kind) et "dernier ouvert" (Last Opened). Il vaut mieux vous habituer à ces deux conditions, parce que vous allez les voir beaucoup. Que veut dire beaucoup ? Par exemple, à chaque fois que vous ouvrirez une nouvelle fenêtre de recherche dans le Finder.

Ce n'est pas assez ? Essayez d'ouvrir un dossier intelligent. S'il est en métal, et si vous avez précédemment éliminé des deux conditions, (en utilisant les petits boutons ronds avec le signe "-"), ils sont partis. Mais malheur à vous si vous cliquez sur le widget de la barre d'outils pour transformer la fenêtre en sa variante non métallique. Tenez-vous bien, vos vieux amis "type" et "dernier ouvert" sont réapparus ! Maintenant, repassez à une fenêtre métallique. Et bien, ils ont décidé de s'incruster. Maintenant, fermer simplement la fenêtre pour vous en débarrasser. Puis, rouvrez-la. Nous voilà revenus au Square One.

Mais attendez, il y a plus ! Ouvrez un dossier intelligent, passez de la présentation métallique à la présentation standard, et fermez. Quand vous le rouvrez, il n'est pas en métal (un miracle !), mais il va vous afficher les critères de recherche "type" et "dernier ouvert", et le champ texte de recherche est associé au clavier. Oui, c'est vrai, ouvrez un dossier intelligent, et tapez un caractère accidentellement, pour modifier complètement votre recherche "sauvegardée". Affreux !

C'est vrai, le changement n'est pas sauvegardé immédiatement, et on va vous demander de le confirmer quand vous fermez la fenêtre. Mais quel est l'intérêt d'une "rechercher sauvegardée" qui peut être si facilement modifiée, même si ce n'est que momentané ?

C'est ce dont je parle quand je dis que l'interface utilisateur de Spotlight a un comportement hostile à l'utilisateur. C'est un attrape nigaud, comme le médium pris dans un piège (des critères de recherche éditables, et le focus par défaut sur le champ texte dans les dossiers "intelligents").

Voici une vidéo montrant ce que le Finder sait faire : confondre les attentes de l'utilisateur, et noyer toute apparence de consistance et de comportement rationnel. La vidéo montre le dossier intelligent de vidéo précédente (celle avec la chaîne de recherche "boogawooga"), sans autres conditions de recherche, qui est ouverte et fermée dans les deux modes métal et non métal. En regardant, essayez seulement de deviner à quoi la fenêtre va ressembler quand elle se rouvre après chacune des actions effectuées. Vous devrez peut-être passer la vidéo lentement pour prendre vraiment conscience de la stupidité.


Grrr... Cliquez pour lancer la vidéo
La Vidéo requiert QuickTime 6 ou plus récent.

Sous quel ensemble de circonstance ceci a t-il pu être livré ? Je voudrais voir le document de conception pour l'intégration de Spotlight dans l'interface utilisateur du Finder, si toutefois il existe (j'en doute fortement). Je suis tenté de dire que c'est normal en ce qui concerne les fenêtres du Finder sous Mac OS X. Mais en réalité, c'est bien au dessous du niveau standard d'insulte à l'utilisateur.

J'ai essayé de filmer le comportement hostile de la fenêtre "Rechercher...", mais elle néglige si délibérément de conserver son état (en plus de conserver éternellement les conditions "type" et "dernier ouvert"), qu'elle insiste pour s'ouvrir au même endroit et à la même taille à chaque fois -une taille trop grande pour tenir confortablement dans une vidéo-. Peu importe, je suis sûr que vous allez en devenir très familier à votre tour. Comme disent les enfants, "allez, Apple". (1)

Peut-être pensez-vous que j'en fais un peu trop, mais imaginez seulement les conséquences d'avoir à modifier en permanence ces fenêtres stupides à chaque fois que vous les utilisez dans des conditions autres que celles par défaut. Vous n'aimez pas utiliser une fenêtre métallique dans le Finder ? Vous pouvez vous en tirer en cliquant le widget de la barre d'outil à chaque fois que vous faites une recherche. Vous n'aimez pas la taille par défaut ou la position de la fenêtre ? Amusez-vous à la déplacer et à la re-dimensionner à chaque fois (ou essayez de trouver une bidouille en plist pour définir de nouvelles valeurs par défaut). Peut-être que vous n'utilisez pas de critères de recherche au delà du champ texte ? Et bien vous avez droit à "type" et à "dernier ouvert"et il vaut mieux que vous les aimiez. Peut-être que vous utilisez d'autres critères de recherche plus souvent ? Tant pis.

Et puis il y a encore des petites choses, non ? Allons chercher un peu de sagesse auprès de Steve Jobs lui-même.

Vous savez, j'ai pensé à ceci : combien de gens sont susceptibles d'utiliser Macintosh ? Un million ? Non, plus que cela. Dans 5 ans, je parie que cinq millions de personnes démarreront leur Macintosh au moins une fois par jour.

Et bien, supposons que vous pouvez économiser dix secondes sur le temps de démarrage. Multipliez par cinq millions d'utilisateurs, et cela fait cinquante millions de secondes, chaque jour. Sur une année, c'est probablement plusieurs douzaines de vies. Alors, si vous démarrez dix secondes plus vite, vous avez sauvé une douzaine de vies. Ne croyez-vous pas ce ça vaut vraiment le coup ?

Ce n'est pas à moi qu'il faut le dire, Steve, c'est à l'équipe de l'interface utilisateur de Spotlight.


(1) Note du traducteur...

Une amie m'a finalement révélé le contenu de cette expression GG Apple, c'est "Good Game, Apple", autrement dit "Bien joué Apple". Mon "Allez Apple" initial n'était donc qu'un (petit) faux sens.