avec
Le 6 déc. 08 à 22:41, KOENIG Yvan a écrit :
(...)
> RCDefaultApp me montre que mon système 10.5.5 ne connais pas l'UTI
> com.apple.appleworks.cwk
> alors qu'il connait com.apple.appleworks.document.
>
> %% mdls -name kMDItemContentType /Users/yvan_koenig/Desktop/
> ChequesYK2004.cwk
> retourne alors:
> kMDItemContentType = "com.apple.appleworks.document"
>
> Par contre, après avoir demandé à Onyx de reconstruire la base
> LaunchService, la même préférence n'affiche même plus l'entrée
> com.apple.appleworks.document par contre elle sait toujours qu'un
> fichier de type CWSS est un com.apple.appleworks.document .
Pour reconstruire la base de LaunchServices :
(Sources <http://www.macosxhints.com/article.php?story=20071102084155353
>)
%% /System/Library/Frameworks/CoreServices.framework/Versions/A/
Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -
kill -r -domain local -domain system -domain user
>
> %% mdls -name kMDItemContentType /Users/yvan_koenig/Desktop/
> ChequesYK2004.cwk
> kMDItemContentType = "dyn.ah62d4rv4ge80g75p"
>
> et cela même après avoir exécuté:
>
> %% mdfind "kMDItemContentType == 'com.apple.appleworks.cwk'"
>
> Je pensais que le fait de lancer AppleWorks allait remettre l'UTI
> 'perdu' en place mais bernique. Pourtant, c'est bien ce programme
> qui ouvre les fichiers AppleWorks suite à un double clic.
Une application peut déclarer des UTI et ne pas les gérer (ouvrir,
éditer, afficher etc...). Si, si...
Voir plus loin la mise en œuvre que je vous propose.
> En outre ce n'est pas un comportement limité à mon système.
> Je me suis rendu compte du problème à la suite d'un message de
> détresse d'un utilisateur d'un de mes scripts. En juillet celui-ci
> fonctionnait alors que maintenant il ne fonctionne plus.
Pour résumer:
Il semble qu'il y ait deux UTI qui se fassent concurrence, (même s'ils
ne sont pas sur le même disque/système):
com.apple.appleworks.document et com.apple.appleworks.cwk.
Est-ce qu'ils déclarent même choses?
Ne pouvez-vous pas utiliser les deux dans vos filtres?
Chez moi c'est <
file://localhost/Library/Spotlight/AppleWorks.mdimporter/
> qui déclare com.apple.appleworks.cwk.
Et com.apple.appleworks.document est inconnu au bataillon. Confirmé
par mdfind.
Je ne sais pas ce qui a installé cet importer Spotlight.
C'est d'origine Leopard/Tiger?
Peut-être une très antique version démo de iWork?
Je pense ne jamais avoir installé AppleWorks (ClarisWork dans la
préhistoire, oui).
À ce propos, ils n'ont toujours pas brûlé les sources de ce truc
périmé qu'est AppleWorks?
> Comme le script n'a pas changé, j'ai pensé au système.
> Mais c'est peut-être une des mise à jour de sécurité qui a créé le
> problème.
> Est-ce que vous les avez toutes installées?
TIens, bonne idée, ça faisait longtemps, je vais regarder avec Mise à
jour de logiciels....
...
...
Il me manque de trucs très lourd à télécharger et pas urgents. Mais je
suis à jour sur les "sécurités". C'est peut-être dans le dernier
Safari, itunes, Java etc.. que ça change.. Je n'en sais rien, tout est
possible.
> Maintenant, il me faut trouver une combine pour remettre en place
> l'UTI perdue.
Vous pourriez essayer ceci (ce n'est pas testé exhaustivementl):
Un applet AS qui déclare automatiquement les UTI dont il a besoin.
Leopard uniquement pour cette forme de déclaration. Voir les docs pour
compatibilité avec 10.4.
Dans un applet "monApplet.app", avec bundle, vous ajoutez l'extrait ci-
dessous à ".../monApplet.app/Contents/Info.plist"
----------------------------------
<key>CFBundleDocumentTypes</key>
<array>
<dict>
<key>CFBundleTypeRole</key>
<string>None</string>
<key>LSItemContentTypes</key>
<array>
<string>com.apple.appleworks.cwk</string>
<string>com.apple.appleworks.cws</string>
</array>
</dict>
</array>
<key>UTImportedTypeDeclarations</key>
<array>
<dict>
<key>UTTypeConformsTo</key>
<array>
<string>public.composite-content</string>
<string>public.data</string>
</array>
<key>UTTypeDescription</key>
<string>AppleWorks Document</string>
<key>UTTypeIconFile</key>
<string>Document.icns</string>
<key>UTTypeIdentifier</key>
<string>com.apple.appleworks.cwk</string>
<key>UTTypeReferenceURL</key>
<string>http://www.apple.com/appleworks.html</string>
<key>UTTypeTagSpecification</key>
<dict>
<key>com.apple.ostype</key>
<array>
<string>CWWP</string>
<string>CWSS</string>
<string>CWGR</string>
<string>CWPR</string>
<string>CWPJ</string>
<string>CSSJ</string>
<string>CGRJ</string>
<string>CPRJ</string>
</array>
<key>public.filename-extension</key>
<array>
<string>cwk</string>
</array>
</dict>
</dict>
</array>
--------------------------------------------
Utilisez TextEdit pour insérer cet extrait dans le plist juste à la
fin, avant:
</dict>
</plist>
Pour nettoyer et tester le fichier plist modifié:
<x-man-page://1/plutil>
%% plutil -convert xml1 fichier
Si vous avez des outils dédiés aux plist/xml n'hésitez pas...
Cet extrait est piqué tel quel à /Library/Spotlight/
AppleWorks.mdimporter/Contents/Info.plist.
J'ai uniquement modifé CFBundleTypeRole à None au lieu de MDImporter.
Vous pouvez évidemment ajouter/retrancher des éléments si besoin est.
Il faut ensuite remuer l'applet dans tous les sens (un changement de
dossier devrait suffire) pour que le système prenne en compte le
changement.
Ça a marché chez moi sur d'autres tests.
--
Daniel
_______________________________________________
Applescript_fr mailing list
Applescript_fr@???
http://listes.patpro.net/mailman/listinfo/applescript_fr
