Discussion :

[ApproxDev]

Bonjour,

j'ai inclus dans un fichier ressource de mon projet, 3 fichiers liés à Hunspell :

fr_FR.* ne sont ouverts qu'en lecture seule.
usrDict.txt est copié en xxDict.txt (xx étant les initiales de l'utilisateur). C'est le dictionnaire perso de l'utilisateur xx. le fichier usrDict.txt contient initialement la ponctuation qui ne figure pas dans fr_FR.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
QFile *mFileUsr;
mFileUsr = new QFile(gDirDico+QDir::separator()+gUSabrv+"Dict.txt");
if (! mFileUsr->exists()) {
    QFile::copy(":/dico/dictionary/usrDict.txt", gDirDico+QDir::separator()+gUSabrv.toLower()+"Dict.txt");
    [...]
}

Lorsqu'un utilisateur ajoute des mots dans son dictionnaire, le code initial est :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
if(!_userDictionary.isEmpty()) {
    QFile userDictonaryFile(_userDictionary);
     if (userDictonaryFile.open(QIODevice::Append)) {
        QTextStream stream(&userDictonaryFile);
        stream << word << "\n";
        userDictonaryFile.close();
     } 
     else
         [...]

A chaque utilisation de cette portion de code, j'ai une erreur (ie on passe par else). Pour une raison que j'ignore l'attribut du fichier copié est en lecture seule !? alors que le fichier original ne l'était pas évidemment.

J'ai modifié le code ainsi.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
if(!_userDictionary.isEmpty()) {
    QFile userDictonaryFile(_userDictionary);
    if(!userDictonaryFile.setPermissions(QFile::ReadOwner|QFile::WriteOwner|QFile::ExeOwner|QFile::ReadGroup|QFile::ExeGroup|QFile::ReadOther|QFile::ExeOther)) {
        qDebug("Erreur");
        return;
    }
    if(userDictonaryFile.open(QIODevice::Append)) {
        QTextStream stream(&userDictonaryFile);
        stream << word << "\n";
        userDictonaryFile.close();
     } 
    else
        [...]

J'avais peur de rencontrer éventuellement un problème d'encodage [les 3 fichiers sont encodés nativement en ANSI] mais je ne m'attendais pas à ce problème. C'est curieux, non ? Placer un fichier en ressource modifie ses attributs ? Pourquoi ?

Cordialement. AD.

[koala01]

Salut,

Si je ne dis pas d'erreur, tout simplement parce qu'un fichier ressource n'est pas une archive comme les autres : c'est une archive dont le "contenu binaire" sera automatiquement rajouté à ton application.

(tu n'as besoin du qrc que lors de la compilation de ton application. Une fois qu'elle a été compilée, il n'est plus utile de le fournir avec l'application )

Or, si ce que je pense est juste, toute tentative de modification des fichiers qu'il contient risque d'en modifier la taille, et, pire encore, de modifier (une partie) du code binaire de ton application. Et un programme qui modifie son propre code binaire, on appelle cela "virus"

Il semble donc "normal" qu'une fois que l'on place un fichier dans les ressources, il soit placé automatiquement en permission "read only".

Ceci dit, il n'y a absolument rien qui t'oblige à mettre tous tes fichiers dans le fichiers ressources. Je pense essentiellement à tous les fichiers "personnels" dont tu pourrais avoir besoin (configuration, dico personnalisé, liste des fichiers ouverts récemment, ...)

Ces fichiers seront bien mieux à leur place dans le dossier qui contient les données personnelles de l'utilisateur, idéalement, dans un dossier spécifique à ton application (comme AppData sous windows ou /home/<nomDutilisateur> sous linux).

[ApproxDev]

Une fois qu'elle a été compilée, il n'est plus utile de le fournir avec l'application

Oui et non : un dico cela s'efface par inadvertance... comme une libmysql.dll (sous Windows). Avec cette méthode, le logiciel s'auto-répare au démarrage. Je pourrais évidemment inclure des chaines en dur dans le programme... mais pour le dico

/home/<nomDutilisateur> sous linux).

... sauf si on utilise un compte générique. Et dans ce cas, c'est l'identification dans le logiciel qui permet d'identifier le bon dictionnaire.

Je ne dis pas que cette démarche est meilleure, loin de là, mais j'ai souvent eu à faire à des bidouilleurs (ie mes élèves) et cette "pratique" diminuait notablement ma maintenance. J'ai gardé cette habitude.
En tout cas, l'explication "lecture seule" me semble convaincante.

Cordialement. AD

[loupium]

salut,
sinon il y a bool QFile::setPermissions(Permissions permissions)

[koala01]

Oui et non : un dico cela s'efface par inadvertance... comme une libmysql.dll (sous Windows). Avec cette méthode, le logiciel s'auto-répare au démarrage. Je pourrais évidemment inclure des chaines en dur dans le programme... mais pour le dico

Apparemment, tu ne m'as pas compris...

Ce que je dis c'est que quoi que tu mettes dans ton qrc, ce sera d'office rajouté au code binaire de ton exécutable, et, à partir de là, impossible à modifier "depuis l'extérieur". Le contenu du qrc, quel qu'il soit se retrouve donc forcement "écrit en dur" dans le programme

Après, si on veut disposer de quelque chose de "modifiable", libre à nous de placer un "modèle" (non modifiable) dans le qrc qui sera ... réécrit à la place à laquelle on s'attend à l'y trouver. De cette manière, si le fichier existe, l'application peut décider de "switcher" vers ce fichier plutôt que d'utiliser la version qui se trouve dans le qrc (ou plutôt de le créer avant de l'utiliser). Mais il s'agit ... d'une copie de ce qui est dans le qrc

... sauf si on utilise un compte générique. Et dans ce cas, c'est l'identification dans le logiciel qui permet d'identifier le bon dictionnaire.

Ben, même avec un compte générique, l'idée reste la même : on place l'élément "modifiable" dans un dossier sur lequel l'utilisateur ait des droits suffisants que pour y écrire les modifications (ce pourrait tout aussi bien être une clé USB ).

Après, que les droits sur le dossier soient temporaires (souvent le cas avec un compte générique) ou définitifs (parce que l'on utilise un compte utilisateur existant), que le fichier perdure après la fin de session ou non, ce sont des décisions qui devront être prises au cas par cas, en fonction de ce que l'on veut faire

Je ne dis pas que cette démarche est meilleure, loin de là, mais j'ai souvent eu à faire à des bidouilleurs (ie mes élèves) et cette "pratique" diminuait notablement ma maintenance. J'ai gardé cette habitude.

C'est, effectivement, une saine habitude, pour s'éviter les tracas quotidiens dus aux utilisateurs peu... scrupuleux.

Mais un fait subsiste : si on veut (pour une raison ou une autre) pouvoir modifier le contenu d'un fichier qui a été placé dans le qrc, hé bien, il faudra bien qu'il se trouve "ailleurs", pour que ce soit cette version qui se trouve "ailleurs" qui soit modifiée, et non la version ... interne à l'application.

Bien sur, je n'ai pris (dans mon explication) que "le cas simple" d'un utilisateur enregistré sur le système, et non d'un invité inconnu. Bien sur, je n'ai pas d'avantage tenu compte des "bourdes que font les utilisateurs". Mais, même si ces considérations sont importantes de manière générale, elles sont "sans rapport direct" avec le problème auquel j'essayais d'apporter... une solution simple. Même si elle mérite d'être étoffée par la suite