Bon, j'ai enfin pris le temps de lire tout le sujet.
Et je vous livre mes impressions sur quelques points :- zip ou 7z, je préfère le 7z pour ses capacités de compression. Ça réduit la taille des paquets à uploader (donc en fait ça ne touche vraiment que les mainteneurs qui ont un petit upload comme moi - 128kbps), par exemple la dernière version de PMBPortable pèse 30 Mo en zip contre 15 en 7z. Ben c'est pour ça qu'elle attend d'être envoyée que je sois au boulot où je dispose de 2Mbps en upload.
- exe : ça n'a d'intérêt que si c'est de l'autoextractible (zip ou 7z), ça laisse alors la possibilité aux utilisateurs Linux ou OS X de les décompresser sans souci. Enfin si, y'a un souci : Tata Jeanine sur son Mac ne sait pas qu'elle peut décompresser un exe. Et Tonton Robert sur son Ubuntu ne le sait pas non plus
Conclusion sur ce point : bon ben on reste au zip alors.
Reprise du format PortableApps :Là c'est plus simple : je rêve d'un format clairement défini, peu m'importe que ce soit celui de PA ou le notre. M'enfin, comme dit pyg, réinventer la roue ça n'a pas vraiment d'utilité.
Et si en plus on peut adapter le format PA pour y rajouter les spécificités Framakey, pourquoi se priver.
Bon, l'inconvénient majeur c'est qu'il va falloir tout repackager.
Enfin c'est pas non plus un gros boulot si on s'y met à plusieurs avec l'outil qui va bien (sauf changement radical de l'appli, il me faut moins de 10 minutes pour créer une mise à jour avec FramaWizard, et encore c'est en changeant le NSI). Le plus long c'est de tout uploader
Conclusion : y'a plus qu'à peaufiner ce qu'on veut y mettre.
Gestion des dépôts :Je rejoins complètement pyg sur la remarque à propos de resaisie des infos. C'est clair que s'il doit y avoir une resaisie, c'est mort dans 6 mois : il manquera plein d'infos.
Il n'y a qu'à voir le nombre d'appli actuelles où les infos ne sont même pas saisies une seule fois (XyzPortzable.xml vide).
Et la solution KISS proposé par pyg à un autre avantage : il doit même pouvoir être possible de modifier les pages wiki des applis avec les infos prélevées dans les appinfo.ini (et hop une resaisie d'évitée, avec en prime des infos formatées qu'il est plus simple de récupérer par extraction dans l'HTMl si besoin).
Je pense notamment aux tailles compressées et aux sommes MD5 qu'il est difficile de mettre dans le paquet zip alors qu'on n'a pas encore les infos.
Le splashscreen (ouais, j'y tiens), les icônes et les screenshots.Bon on peut profiter du repackaging pour harmoniser mais je voudrais juste faire part d'une remarque : à force de rajouter du texte on obtient un effet "trop d'infos tue l'info".
Donc s'y on cherche à placer le nom de l'appli, son icône, les différentes mentions "vous venez de lancer un logiciel portable FramaKey" + "Framakey est un projet du réseau Framasoft" + "basée sur PortableApps format", on arrivera à gêner l'utilisateur plus qu'à l'informer.
Pour les icônes et Screenshots, il me parait plus intéressant de les mettre dans le dossier Appinfo de manière à ce que le script mentionné plus haut (KISS) puisse les récupérer pour compléter éventuellement la page wiki (certainement une idée très bête mais bon). D'ailleurs si on pousse le raisonnement au bout : ne serait-il pas envisageable (z'avez vu je prends des précautions) lors du dépôt d'une nouvelle appli de créer une ébauche de page wiki à partir des infos contenues dans appinof.ini ?
Comment respecter le format PA avec certaines applis nativement portables sous conditions ?Je pense notamment à Notepad++ qui est portable s'il détecte ses fichiers de préférence utilisateur dans son répertoire ou à Audacity qui l'est aussi si un dossier Portable Settings existe là aussi dans son répertoire.
Une solution basique consiste à recopier les préférences à la sortie du logiciel vers \Data. Quid en cas de pépin ?
Ça me semble toutefois la meilleure solution pour faciliter d'éventuelles mises à jour.
Et puisqu'on parle de Data, je relance la discussion sur
les applis qui utilisent ApplicationData pour sauvegarder tout ou partie des réglages. C'est le cas notamment d'Avidemux ou de VLC.
À l'heure actuelle, avidemux utilise une méthode couramment employée par PA : backup de l'existant, utilisation d'AppData, sauvegarde en sortie et remise en place de la version locale.
Pour VLC, c'est pire : il laisse des traces, notamment un fichier vlc-qt-interface.ini, qui chez moi contient le/les derniers fichiers joués.
N'est-il pas envisageable d'utiliser la méthode du backup (ça limite forcément l'emploi du logiciel à une seule de ses deux version - locale ou portable) et en cas de crash d'avoir un petit système de détection (genre fichier lock) qui lors de la relance va vérifier si la sortie c'est correctement effectuée (absence du lock) et dans le cas contraire va parser AppDAta pour remettre en place proprement les versions locales ?
Attention, je parle bien uniquement des applis qui utilisent AppData, pas de celles qui touche la base de registre.
Mieux vaut prendre le temps de tout bien définir avant pour automatiser au maximum le repackaging mais aussi le développement de futures applis
Vécu : "J'ai une version crackée d'OpenOffice, c'est pour ça qu'elle est en anglais"
