[10.5]Développement Plug-In QuickLook

Didier Guillion

Didier Guillion

Membre expert
Club iGen
20 Juillet 2001
3 244
164
63
Toulouse
www.myriad-online.com
Bonjour,

Je suis en train d'écrire un plug-in Quick Look pour Mac OS X 10.5, cela fonctionne maintenant mais j'ai encore de petits problemes. Je propose que nous échangions nos astuces ici...

Par exemple, si l'on coche la case "Dead code stripping", le point d'entrée du module est perdu, il faut le déclarer :

#pragma export on

#define EXPORT __attribute__ ((visibility("default")))

EXPORT void *QuickLookGeneratorPluginFactory(CFAllocatorRef allocator,CFUUIDRef typeID)

#pragma export off


Au niveau déboggage, j'ai suivit la doc, et j'invoque "qlmanage" au niveau de l'executable. Des que j'ai un point d'arret défini dans mon source, GDB plante grave. J'ai trouvé une astuce : supprimer tous les points d'arrets, appeler DebugStr en debut de code (avec "Stop on debugstr activé") ensuite on peut poser des points d'arrets.


Le nouvel XCode est un peu plus convivial au niveau de la config, (mais on pouvait difficilement faire pire n'est ce pas ?), par contre je n'ai toujours pas trouvé le moyen d'explorer des tableaux alloués de manière dynamique sous deboggeur. J'avais envoyé un bugreport a Apple à l'époque et on m'avait répondu que ce serait intégré dans la v3. Mais je ne vois pas où. Quelqu'un a une piste ?

Sinon QuickLook semble, pour moi, la vraie avancée du 10.5, il est cependant regretable de devoir générer toutes les pages du document, ce qui prends du temps, alors que QuickLook aurait pu simplement envoyer le numéro de la page à visualiser.

Cordialement
 
bonjour didier ton poste est tres interessant mais je ne me suis pas interresse a cette api,
en tous les cas je suis ce thread si tu as des choses en complement
as tu essaye

#pragma comment(lib,object) j ai deja pas mal lutte avec le dead-code stripping quand les methodes n etaient pas declarees en virtual en cpp mais c est un autre probleme de visibilite

mais c est marrant qu une methode avec un futur explicit call soit strippee c est le constructeur? c est tout le contraire du concept ? :D

ce que je comprend c est comme le constructeur n est pas appele directement il est strippe
ca a du sens le linker le vire car pas d appel quand tu compiles

as tu essaye de faire un fichier separer ne contenant que le constructeur et tu strippes sur le reste ?
:coucou:

pour ce qui est d xcode je suis pas fane du drag an drop ds IB pour instancier tes controlleurs surtout que l appli ne di pas si c est ok une fois sur deux il ne remet pas jours de suite, enfin c est pas tres naturel peut etre plus rapide, mais bon ca manque de truc user friendly et les petites boites pour linker c est chiant, pour le debug les break pints c est merdique et j ai les meme probs de plantage le truc par dans la semoule, j avais deja envoye un mail Ryan Du Bois, qui m avait assure que cela devrait etre corriger mais je ne vois pas trop d amelioration, un point positif est instruments, mais il te montre une leak sur un objet alloue que tu ne relaches pas car tu runs une loop evidemment que tu perds de la mem mais si c est objet doit etre vivant tout le temps, c est cretin
 
L'entrée du plug-in QuickLook est appellée par le gestionnaire, "on the fly", ce qui fait qu'elle est considérée comme non appellée de maniere interne et supprimée par le DeadCode Stripping.

Au passage, il y a pas mal de trous dans la conception de QuickLook.
Par exemple, si deux plug-ins definissent pouvoir gérer le meme type de fichier, l'utilisateur ne peut attribuer le plug-in qu'il veut (comme on peut deja le faire pour les applications), au pire c'est au hasard.

Voila 15 jours que je suis sur XCode 3 de maniere intense. C'est nettement plus stable, sauf GDB qui a tendance a planter a repetition au lancement quand un point d'arret est posé.

PackageMaker a progressé de manière plus que significative, il est a mon avis maintenant utilisable.

Cordialement
 
Haut Bas