GiCalDesktop

tarultarul Membre
mai 2007 modifié dans Vos applications #1
Nom de l'application : GiCalDesktop
Principal service : affichage sur le bureau des 5 premières entrées d'un calendrier google

objectif pour moi même : explorez un peu le framework cocoa de google, et apprendre a faire une application cocoa.

Elle est sans doute loin d'être utile puisqu'il existe un widget dashboard qui fait la même chose.

fonctionnalité :
- récupération de 5 entrées d'un seul calendrier google
- mise à  jour des entrées automatique et personnalisable
- selection du calendrier parmis les autres disponibles.

langue : français, sans doute anglais
je vais rajouter la personnalisation de la couleur de la fenêtre et du texte affiché.

preview image : capture-GiCal.jpg

je vais bientôt mettre une première version (le corps fonctionne),mais merci a objective-cocoa pour les tutos et ressources. :)

Réponses

  • tarultarul Membre
    15:23 modifié #2
    Voilà  la préview si cela vous intéresse.

    le lien : http://jeu.starwars.free.fr/screen/GiCalDesktop.dmg


    Sinon attention, le mot de passe est sauvegardé en clair. Le cryptage du mot de passe sera pour la prochaine version.
  • BruBru Membre
    15:23 modifié #3
    Y a t'il une raison particulière de n'avoir fait qu'une version INTEL de ton appli (mis à  part le fait de vouloir être détesté par la moitié de la communauté Mac) ?

    .
  • tarultarul Membre
    mai 2007 modifié #4
    heu non, c'est pas voulut.
    Je pensais que c'était une option par défaut de xcode intel.

    je vais corriger ça de suite.

    Edit : voilà  la nouvelle version UB est disponible a la même adresse.

    Ah oui j'oubliais, c'est une version debug, et qui a encore tout ces NSLog qui traà®nent.
  • schlumschlum Membre
    15:23 modifié #5
    Passe en "Release" pour diffuser tes trucs... (sinon en plus il risque d'y avoir des problèmes de zerolink)
  • tarultarul Membre
    15:23 modifié #6
    mes connaissances dans le dev sur mac et en particulier sur obj-c et l'utilisation d'x-code sont très sommaire.

    mais cette version n'est pas faà®te pour être diffusé a large échelle, elle a encore trop de défaut(notament le mot de passe stocké en clair  :)beta:)

    je mettrais la version 'release' demain matin, par contre quel est cette histoire de zero link? est-ce des liens qui sont crée par x-code pour le debugging?
  • schlumschlum Membre
    15:23 modifié #7
    dans 1178313889:

    mes connaissances dans le dev sur mac et en particulier sur obj-c et l'utilisation d'x-code sont très sommaire.

    mais cette version n'est pas faà®te pour être diffusé a large échelle, elle a encore trop de défaut(notament le mot de passe stocké en clair   :)beta:)

    je mettrais la version 'release' demain matin, par contre quel est cette histoire de zero link? est-ce des liens qui sont crée par x-code pour le debugging?


    En mode "debug", par défaut 'zerolink' est activé -> le lien n'est pas fait (ln)
  • AliGatorAliGator Membre, Modérateur
    15:23 modifié #8
    dans 1178313889:
    je mettrais la version 'release' demain matin, par contre quel est cette histoire de zero link? est-ce des liens qui sont crée par x-code pour le debugging?
    En fait plus précisément, zerolink permet d'éviter de passer par la phase d'édition des liens, comme l'a dit schlum, ce qui a l'avantage de gagner pas mal de temps surtout quand tu es en train de développer ton appli et que tu n'arrêtes pas de la modifier puis la recompiler pour tester les modifs.

    Ce qui se passe alors c'est que l'édition des liens entre les divers modules n'est pas faite, pour gagner du temps, mais en contrepartie tu n'as pas un vrai executable final utilisable partout : avec zerolink (sans édition de liens donc), tu pourras tester ton appli dans XCode, qui se chargera de faire un linkage dynamique etc, mais il a besoin pour cela d'avoir tous les fichiers intermédiaires qu'a produit la compilation. Ca ne pose donc pas de problème tant que tu restes sur ta machine, mais quand tu diffuses ton appli sur le net ou la passe sur une autre machine, il te manquera tous ces fichiers intermédiaires et l'appli ne pourra pas se lancer.
    Il faudra donc la recompiler sans l'option zerolink (le plus simple étant de la compiler en Release pour ça, et non pas en débug, puisque bien évidemment zerolink est désactivé en Release) pour que cette fois-ci tous les fichiers intermédiaires de la compilation soient linkés et que cela produise un vrai executable final autonome que tu peux diffuser.
  • schlumschlum Membre
    15:23 modifié #9
    En gros, quand je lance ton appli chez moi :

    Command: GiCalDesktop<br />Path:&nbsp; &nbsp; /Volumes/GiCalDesktop/GiCalDesktop.app/Contents/MacOS/GiCalDesktop<br />Parent:&nbsp; WindowServer [65]<br /><br />Version: ??? (1.0a)<br /><br />PID:&nbsp; &nbsp; 1239<br />Thread: 0<br /><br />Exception:&nbsp; EXC_BAD_INSTRUCTION (0x0002)<br />Code[0]:&nbsp; &nbsp; 0x00000002<br />Code[1]:&nbsp; &nbsp; 0xa2bdfd6c<br /><br /><br />Thread 0 Crashed:<br />0&nbsp;  &lt;&lt;00000000&gt;&gt; 	0xa2bdfd6c 0 + -1564607124<br />1&nbsp;  com.apple.zerolink&nbsp; &nbsp;  	0x96bd3bf0 checkForZeroLinkImage + 720<br />2&nbsp;  dyld&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  	0x8fe026c0 dyld::imageNotification(ImageLoader*, unsigned) + 160<br />3&nbsp;  dyld&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  	0x8fe0ddfc ImageLoader::runNotification(ImageLoader::LinkContext const&amp;, unsigned) + 64<br />4&nbsp;  dyld&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  	0x8fe03728 dyld::registerAddCallback(void (*)(mach_header const*, long)) + 176<br />5&nbsp;  libSystem.B.dylib&nbsp; &nbsp; &nbsp; 	0x90001858 _dyld_register_func_for_add_image + 88<br />6&nbsp;  com.apple.zerolink&nbsp; &nbsp;  	0x96bd4164 __zero_link_init_app + 68<br />7&nbsp;  com.tarul.GiCalDesktop 	0x00002610 start + 976<br />8&nbsp;  com.tarul.GiCalDesktop 	0x0000256c start + 812<br />9&nbsp;  com.tarul.GiCalDesktop 	0x00002270 start + 48
    
  • tarultarul Membre
    15:23 modifié #10

    merci pour ces compléments d'information.

    Petite question pour le sotckage du mot de passe gmail, je vois 3 choix

    un nsvaluetransformer avec le cryptage que je souhaite a condition qu'il soit reversible.
    un keychain personnalisé pour mon application
    utiliser le keychain de l'utilisateur.

    Question vaut il mieux utiliser le keychain? si oui, un keychain unique pour l'application, ou un item du keychain utilisateur.

    j'ai mise à  jour le dmg.

  • 15:23 modifié #11
    Les trousseaux d'application, ça n'existe pas: Keychain permet de créer plusieurs trousseaux, mais le but n'est pas d'avoir un trousseau par application, mais de regrouper les mots de passes par "thème" (en général le type thème choisi consiste en des réglages de sécurité différents). Les autorisations par application sont en fait retenues au niveau du mot de passe.

    Sinon pour répondre à  la question, je trouve que le 3 est le mieux: si on veut utiliser ton soft, il y a de très grandes chances qu'on accède déjà  à  ses données depuis un browser. Et si ce browser est Safari (ou tout autre navigateur basé sur le WebKit) ou Camino, le mot de passe est déjà  dans le trousseau, donc il n'y a qu'à  le demander et l'utilisateur ne doit pas le stocker.
Connectez-vous ou Inscrivez-vous pour répondre.