PAC2 a écrit:A chaque fois que ça s'est passé, c'était à chaud, c'est-à-dire quand je redémarre framafox.
Je m'en doutais
Et malheureusement, il n'y a pas de solution correcte à ce souci.
À la fermeture, l'interface graphique de Framafox disparait rapidement mais le programme n'est pas terminé réellement, cela prend quelques secondes (selon la vitesse du support) pour qu'il quitte définitivement.
De plus, il y a une tempo de 2 secondes à la sortie de Framafox.exe qui est gérée par le lanceur FramafoxPortable ET une commande de compression des bases de données sqlite de Framafox. C'est le seul contournement que j'ai trouvé pour être en mesure de gérer le redémarrage lors de l'ajout d'une extension. Je me suis d'ailleurs rendu compte après l'avoir mis en place qu'il y avait la même chose dans la version PA.c.
Ce qui se passe c'est donc qu'alors que Framafox parait terminé, vous relancez FramafoxPortable. Celui-ci détecte que le processus FramafoxPortable existe toujours (en fait, il teste un mutex), il lance donc Framafox sans préciser les options du profil (obligatoire sinon message d'erreur, on ne peut passer le profil en paramètre qu'une seule fois). Et au moment où Framafox est lancé, bin la première instance a terminé sa sortie ... donc le profil n'est plus ouvert.
Conclusion Framafox cherche à utiliser un profil "fixe", profil qui n'existe pas d'où la demande de création de celui-ci commençant par l'import des signets.
Une possibilité pour réduire ce temps de latence en sortie est de désactiver la compression des bases sqlite avec un fichier FramafoxPortable.ini. Il faut mettre CompressDB à false. C'est expliqué en détail dans \FramafoxPortable\Other\Source\readme.fr.txt.
Mais ça ne réglera pas le problème définitivement.
Vécu : "J'ai une version crackée d'OpenOffice, c'est pour ça qu'elle est en anglais"