Bonjour Sophie,
Merci pour tes réponses toujours rapides et cordiales, c'est très
agréable et cela change de certaines listes (que je laisserai non
identifiées) où poursuivre une discussion après avoir reçu un avis un
tant soit peu différent d'un "officiel" équivaut à se faire lyncher.
:D
Sophie Gautier wrote:
À mon avis, il y a deux différences fondamentales entre "Enregistrer
sous" et "Exporter" :
Exporter veut dire enregistrer des données dans un format qui n'est pas
celui du logiciel utilisé.
Enregistrer veut dire sauvegarder des données sur un support permanent
(cf le jargon français, mais d'autres reprennent ces notions
http://www.linux-france.org/prj/jargonf/)
<snip>
Dans ce sens, "Exporter..." pourrait
très bien s'appeler "Enregistrer une copie...".
Non, comme tu le disais dans le titre de ton premier message, il y a
conversion de données, ce n'est donc pas une copie
Je suis tout à fait d'accord, encore faudrait-il qu'OOo travaille selon
ces définitions.
À mon sens, tout enregistrement demande une conversion entre un "état du
document chargé en mémoire" et un "état du document enregistré sur le
disque". Il faut faire des tas de trucs du style (je crois) sérialiser
les objets en xml et souquer les artibuses. C'est pas ça ? Je vous
l'avais dit : je suis pas programmeur.
Bref, tout enregistrement demande une conversion.
Bien entendu, il doit y avoir _un_ format de référence, celui qui permet
d'enregistrer toutes les possibilités possibles dans un document et de
les récupérer à l'ouverture.
Dans le cas d'OOo v2, il s'agit - je suppose - des formats OpenDocument.
Même les formats les plus proches (formats OOo v1, StarOffice) demandent
une conversion (à l'écriture, à la lecture). Les formats plus différents
demandent des conversions plus extensives (doc, xml MS, pdf).
En appliquant (trop) strictement ta définition, on ne peut Enregistrer
que dans le format OpenDocument ad hoc et Exporter vers tous les autres.
En l'appliquant un peu moins strictement, on peut Enregistrer les
formats "proches" et Exporter les formats "trop éloignés"... Mais où
fixer la limite ? La fixer selon les mécanismes utilisés par le
programme n'a aucun sens pour l'utilisateur puisqu'il ne peut et ne doit
pas les voir.
À l'heure actuelle, OOo ne fonctionne pas selon les définitions que tu
présentes. À partir d'un fichier odt, doc ou sxw (je n'ai pas testé les
autres), on peut Enregistrer dans un foultitude de formats (plus ou
moins étrangers) et Exporter uniquement vers pdf ou xhtml.
Tous les formats disponibles dans la liste de Enregistrer peuvent être
ouverts directement sous OOo.
Le pdf ne peut pas être lu par OOo. Le xhtml peut être ouvert de façon
brutale, mais alors on voit du code, et je ne sais pas comment l'ouvrir
"correctement" de manière à récupérer le document d'origine ou quelque
chose d'approchant.
C'est la différence pratique et observable aujourd'hui entre Enregistrer
et Exporter. Je ne sais pas si elle est correcte, mais elle est là.
Donc, àma et à l'heure actuelle, la différence conversion / pas (ou peu)
de conversion n'est pas ce qui mène le choix entre Enregistrer et
Exporter. Je pense également que le classement actuel est plus sensé du
point de vue de l'utilisateur que la définition technique que tu proposes.
>> 2) Le point 1 permet à "Exporter..." de proposer des formats
>> inéditables par OOo : OOo ne peut pas lire ni modifier un pdf, mais il
>> peut en enregistrer un. Ce qui est impossible pour un "Enregistrer
>> sous..."
>
> pas forcément, tu peux très bien réouvrir un format .html ou un format
> .gsi exporté au départ. L'exportation sert alors à gérer les balises ou
> les éventuels scripts du document et donc conversions du fichier.
On ne peut pas Exporter en html, seulement Enregister sous. (Pour gsi,
je ne trouve pas d'un côté ni de l'autre et j'ignore de quel type de
fichier il s'agit. Données géographiques ?)
Je trouve cette limitation dommageable et je pense qu'il est possible
de la lever tout en rendant l'interface plus simple cohérente.
Tous les formats de fichiers devraient être disponibles partout. Peu
importe que l'on soit dans "Enregistrer sous..." ou dans
"Exporter...". Il y a une difficulté à lever : que faire quand on
désire "Enregistrer sous..." vers un format de fichier non éditable ?
Amha, les formats de fichiers doivent être disponibles lorsque la
fonction correspondante l'est, sinon, cela devient difficile à gérer ;).
Je ne pense pas q'un utilisateur essaiera d'enrichir un caractère avec
une fonction d'édition, il en est de même pour l'enregistrement ou
l'export, je suis d'accord sur le fait que ce n'est pas clair.
Je suis désolé, je ne comprends pas ce que tu veux dire... Je relirai
cela plus tard à tête plus reposée.
Deux propositions :
1) Conserver les menus tels quels. Lorsqu'un utilisateur enregistre
vers un format de fichier non éditable, un message apparaît et
explique qu'OOo peut écrire mais pas lire le format de fichier choisi
et que, par conséquent, le fichier restant ouvert à l'édition sera le
fichier original, pas la copie enregistrée sous le nouveau format. Ce
message devra être particulièrement clair pour éviter qu'un
utilisateur n'enregistre un nouveau document uniquement sous un format
non éditable.
Ce n'est qu'une question d'implémentation, si un développeur fournit un
filtre d'import PDF, OOo saura lire du PDF. Ce que l'utilisateur doit
savoir c'est qu'il va travailler dans un autre format que le format
natif de OOo et qu'il y aura donc une conversion des données pour
assurer la compatibilité.
Le risque de perte de donnée est déjà bien annoncé par OOo lors d'une
conversion. Il "suffit" que OOo regarde s'il a ou non un filtre de
lecture pour savoir s'il doit afficher le message d'information relatif
à la capacité de lecture et d'édition.
2) (que je préfère) supprimer le menu "Exporter...". Ajouter dans le
dialogue de "Enregistrer sous..." une case à cocher "Enregistrer une
copie et continuer à éditer le document en cours". Cette case à coche
est sélectionnée et désactivée si l'utilisateur choisi un format non
éditable. De nouveau, un message d'information, avec une case à cocher
"ne plus montrer ce message".
Il y a aussi le menu Fichier>Envoyer>Créer un document HTML, qu'en
fais-tu ;)
Rien, jusqu'à présent. En quoi pose-t-il un problème ? On pourrait avoir
"Envoyer le document" et "Convertir et envoyer le document", ce qui
permettrait par exemple d'envoyer un document au format MSO sans passer
par le disque dur. (À propos, les intitulés des 6 dernières entrées de
menu [après, il y a des plats et des desserts de menu ?] me paraissent
curieux dans ce contexte.)
Remarque : il y a un cas particulier à régler : que faire si un
utilisateur tente d'"Exporter..." un fichier remplaçant le fichier en
cours ? Un message d'erreur est nécessaire dans ce cas. (Dans la
seconde solution solution, la case à cocher devrait être désactivée et
déselectionnée.) Je tiens à préciser que le problème existe déjà en
OOo mais qu'il nécessite deux fichiers ouverts. Le message d'erreur
existe déjà (mais il vient àma trop tard dans le processus de
sauvegarde : après la demande de remplacement et après l'avertissement
de risque de perte de données causée par un changement de format).
Là encore, dans la mesure où il s'agit de deux fonctionnalités
différentes, que fais-tu dans le cas de champs de formulaires par
exemple dans un fichier html ?
De nouveau je ne comprends pas... Tous ces test ont du m'anesthésier le
cerveau.
Qu'en pensez-vous ? En feriez-vous une RFE ?
Tu le peux, mais comme nous ne sommes déjà pas assez nombreux pour les
valider, pour le moment je te conseille d'attendre avant de la soumettre
que le nouveau processus de travail soit en place.
Pas de problème : j'attends très très bien. Je ne crois d'ailleurs pas
obtenir quelque chose avant la v3.
Merci de m'avoir lu jusqu'ici (j'espère ne pas vous avoir filé mon mal
de tête...).
Non, non, tout va bien :) A mon sens, et ton questionnement est vraiment
le bienvenu à ce sujet, je pense qu'il faut préciser aux utilisateurs ce
que sont les notions d'export, d'import et de conversion.
Attention que beaucoup d'utilisateurs n'auront aucune formation. Surtout
ceux qui passeront de MSO vers OOo qui devront se débrouiller.
Il me semble honorable de cacher aux utilisateurs les basses contraintes
techniques (quand on le peut et que l'utilisateur n'y perd rien) pour
lui offrir une interface simple et efficace.
> En relisant
tes mails ce matin, le sujet de ton message m'a vraiment fait comprendre
que l'interface n'est pas assez intuitive et l'aide pas assez détaillée
à ce niveau. Ce que je disais hier à propos des catégories de fonctions
doit être plus évident qu'un simple séparateur dans un menu et doit
renvoyer à une explication claire dans l'aide (qui pour le moment ne
liste que l'utilisation de la fonction, mais ne l'explique pas).
Amen !
Bien cordialement,
Philippe Debar
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
