Thank you for the bug report, Robert!
I forward it to the upstream developer, with a message in French below:
bonjour Jean-Marie,
je vois qu'optgeo a du succès à travers son paquet Debian. En général
quand des rapports de bug bien sentis comme celui-là remontent, je le
vois comme un bon signe. Le rapport d'origine est en anglais,
ci-dessous.
Il se trouve que le bug que rapporte Robert ne concerne pas Debian
seulement, mais tous les systèmes multi-utilisateurs où tu sais porter
Optgeo.
Robert a raison de dire qu'on ne peut pas repérer les fichiers de
configuration par rapport à la position de l'exécutable dans le système
de fichiers, il faut prendre en compte la spécificité de l'utlisateur,
sitôt que celui-ci est amené à modifier un fichier de configuration.
Une petite recherche dans le code source m'amène à voir que le même
problème affecte de nombeux autres chemins, je cite en vrac les variables
repertoire_config_perso, nom_fichier_config_optgeo,
nom_fichier_config_perso, repertoire_simul_perso, nom_ini_file, etc.
que trouve gérés de façon déconcentrée, dans des fichiers unit222.pas,
ray1.pas, unit17.pas, etc.
J'imaginerais volontiers le type de solution suivant :
- calcul d'un répertoire personnel de données liées aux applications ;
sous Linux, selon les règles de Freedesktop.org, ça donne
/home/${USER}/.local/share/optgeo ; sous Windows, ça donne : ?
- *tous* les fichiers qu'un utilisateur peut être amené à modifier
concernant les configurations, préférences, simulations, etc. seront
dans un sous-répertoire du précédent, sans exception.
- au cas où un des fichiers à créer par l'utilisateur descend d'un
modèle (un template comme on dit en français), le modèle sera dans
/usr/share/optgeo/modeles
Comme faire ces changements sans entraîner de bugs subtils suppose
d'être familier avec les sources, je souhaiterais te demander si tu
accepterais de prendre en charge ce rapport de bug ; dans le cas où tu
ne pourrais pas, puis-je compter sur tes conseils et tes tests pour les
interventions maladroites que je tenterais ?
D'autre part, Robert fait justement remarquer que comme Optgeo a été
bien internationalisé, ça vaut certainement la peine d'interroger les
variables d'environnement pour établir la langue au démarrage. Sous
GNU/Linux, il y a une variable d'environnement LC_ALL. Chez moi,
$ echo $LC_ALL... ça donne :
fr_FR.UTF-8
On doit pouvoir extraire les parties intéressantes de ça presque à coup
sûr, pour chaque langage des traductions en prenant en compte les deux
ou les cinq premiers caractères de la valeur de cette variable.
Question : comment récupère-t-on la valeur d'une variable
d'environnement sous Lazarus ?
Merci d'avance pour ton aide, et bonne année 2012 !
Amitiés,Georges.
Robert Jacobs a écrit :
Package: optgeo
Version: 2.10a-1
Severity: normal
Choosing Options / Language / en+fr tries to write the choice to
/usr/bin/optgeo.ini, which is to say
ray1.pas:extractfilepath(application.ExeName)+'optgeo.ini';
But that just causes an error because the program shouldn't be run as
root.
(Also, shouldn't it default to the language in the environment
variable LANG, not just always fr?)
Thank you-
- Robert Jacobs
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages optgeo depends on:
ii libatk1.0-0 2.2.0-2
ii libc6 2.13-24
ii libcairo2 1.10.2-6.2
ii libgdk-pixbuf2.0-0 2.24.0-2
ii libglib2.0-02.30.2-4
ii libgtk2.0-0 2.24.8-2
ii libpango1.0-0 1.29.4-2
ii libx11-62:1.4.4-4
optgeo recommends no packages.
optgeo suggests no packages.
-- no debconf information
--
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70
signature.asc
Description: Digital signature
