Re: lyx-1.5 - encodage
Charpentier == Charpentier Philippe [EMAIL PROTECTED] writes: Je ne suis pas sur du rapport entre ca et les menus en francais... Charpentier Je ne sais pas... Mais je pense qu'une telle structure Charpentier rendrait nécessaire la lecture des layouts correcte (et Charpentier donc un encodage sûr) alors que l'on peut toujours Charpentier discuter sur l'intérêt de menus supplémentaires. Enfin, Charpentier les menus restant alors ceux de base il n'y aurait plus Charpentier de problèmes récurrents avec les fichiers ui. Par curiosite, qu'est-ce que tu ajoutes aux menus? Des changements de layouts? Ce qu'il faudrait faire, c'est permettre de définir une hierarchie des styles dans les fichiers layouts. Comme ca, la combox pourrait etre remplacée par un menu hierarchique. Cela n'empeche pas qu'une 'sidebar' avec ces styles serait tres utile. JMarc
Re: lyx-1.5 - encodage
> "Charpentier" == Charpentier Philippe <[EMAIL PROTECTED]> writes: >> Je ne suis pas sur du rapport entre ca et les menus en francais... Charpentier> Je ne sais pas... Mais je pense qu'une telle structure Charpentier> rendrait nécessaire la lecture des layouts correcte (et Charpentier> donc un encodage sûr) alors que l'on peut toujours Charpentier> discuter sur l'intérêt de menus supplémentaires. Enfin, Charpentier> les menus restant alors ceux de base il n'y aurait plus Charpentier> de problèmes récurrents avec les fichiers ui. Par curiosite, qu'est-ce que tu ajoutes aux menus? Des changements de layouts? Ce qu'il faudrait faire, c'est permettre de définir une hierarchie des styles dans les fichiers layouts. Comme ca, la combox pourrait etre remplacée par un menu hierarchique. Cela n'empeche pas qu'une 'sidebar' avec ces styles serait tres utile. JMarc
Re: lyx-1.5 - encodage
Jean-Marc Lasgouttes a écrit : Par curiosite, qu'est-ce que tu ajoutes aux menus? Des changements de layouts? C'est simple: j'utilise lyx pour écrire mes articles de math, et comme j'envoie ceux-ci à des revues, généralement, américaines, j'utilise amsart. La classe en standard de lyx (article AMS) ne conviens pas pour plusieurs raisons: - elle ne respecte pas exactement les règles de amsart.cls (je suppose pour des raisons d'internationalisation): toutes les entrées ne sont pas présentes, certaines formatent le texte différemment (adresse...), d'autres ne sont pas présentes (classification AMS 2000) et il y a le bug amsart babel - j'utilise toujours une numérotation séquentielle sur les sections (ou sans) pour les théorèmes: compteur différents pour les Théorèmes, les Propositions, les Définitions..., et spéciaux pour les Corollaires (attachés au théorème ou à la proposition) et les Lemmes. - pour les figures et les diagrammes (ce qui n'arrive que très rarement) j'utilise pstricks et je n'ai pas envie de me replonger dans la doc à chaque fois Je me suis donc écris des classes strictes pour amsart, amsbook (et aussi smfart), en anglais et en français (avec traduction complète du maketitle) où tout ce dont j'ai besoin est prédéfini: des paramètres de document supplémentaires, toutes les entrées du maketitle, un certain nombre d'environnements, tous les théorèmes et des entrées permettant d'obtenir facilement des diagrammes commutatifs avec psmatrix et des figures de base avec pstricks. Cela produit des classes contenant un très grand nombres d'entrées (pour les théorèmes seuls il y en a près de 90), et la combobox des layouts devient inutilisable. Je me suis donc écris des fichiers ui correspondant à chaque classe où toutes les entrées sont rangées dans des sous-menus logiques: Par exemple le menu "amsart anglais" contient les sous-menus: -Paramètres généraux (compatibilité amsart-babel, utilisation de certaines polices de math...) -En tête (maketitle complet: 15 entrées) -Sections (numérotées, non numérotées et d'autres choses...) -Caractères (accents, séries et graisses...) -Environnements (formats, environnements...) -Théorèmes (numérotés sur sections et sans sections (on peut avoir les deux dans un même document!), non numérotés) -Diagrammes et figures (position normale ou à coté du texte...) J'obtiens ainsi, dans la barre des menus, un accès rapide aux différents layouts que je veux utiliser, et je n'utilise plus jamais la combobox des layouts. De plus, sauf cas exceptionnel, je n'ai plus besoin d'utiliser le préambule latex. Je déplore seulement que, la non lecture logique des layouts, et l'affichage peu commode de leur contenu m'a conduit à écrire des fichiers lourds qu'il faut remettre à jour presque à chaque nouvelle version de lyx. De plus, comme toutes les entrés d'un fichier ui sont actives dans les menus (qu'elles apparaissent ou non dans la classe utilisée), je suis obligé de faire un menu pour chaque classe, alors que l'intersection de deux layout est loin d'être vide. S'il était possible de faire en sorte qu'une entrée (layout) de menu ne soit active que si elle existe dans la classe j'aurai procédé autrement. Ce qu'il faudrait faire, c'est permettre de définir une hierarchie des styles dans les fichiers layouts. Comme ca, la combox pourrait etre remplacée par un menu hierarchique. Cela devrait pouvoir se faire en rajoutant un tag? Cela n'empeche pas qu'une 'sidebar' avec ces styles serait tres utile. JMarc C'est certain: on aurait constamment la liste des layouts sous les yeux, et uniquement ceux existant dans la classe utilisée. S'il sont en plus rangés par groupes logiques sous forme d'un arbre que l'on peut dérouler ou non ce serait parfait. C'est aussi valable pour le panel math qui est toujours gênant lorsque l'on tape. PhC
Re: lyx-1.5 - encodage
Philippe == Philippe Charpentier [EMAIL PROTECTED] writes: Philippe Bonjour, je viens de tester lyx-1.5 (SVN) et j'ai constaté Philippe que mes fichiers layout et ui plantent lyx. Ceux-ci étaient Philippe écris en ISO-8859 et marchaient avec lyx-1.4.x Je les ai Philippe traduits en UTF-8 et cela ne change rien. Il semble que la Philippe seule solution soit de les écrire en ASCII, donc sans aucune Philippe lettre accentuée, ce qui n'est pas très agréable pour Philippe l'interface. Qu'en sera-t-il avec la future version lyx-1.5? Philippe Ces fichiers devront-ils être écris en ISO, en UTF-8 ou Philippe nécessairement en ASCII? Avant la version 1.5, LyX considérait juste les entrées comme du texte 8bits, rien de plus. Maintenant, avec unicode, ce n'est plus aussi simple. Pour les fichiers layouts, on va peut-être se diriger vers une solution ou le nom du style sera ascii et une nouvelle entrée GUIName permettra de dire comment afficher ce nom (en utf8). En y repensant, je vois plein de problèmes (comment utiliser les anciens fichiers avec des noms 8bits, par exemple ?) Je pense que ce serait bien d'envoyer un message sur lyx-devel en indiquant exactement quels sont les cas où le iso8859 n'est plus accepté, et parmi ceux-ci, quels sont les cas qu'il faudrait absolument corriger. JMarc
Re: lyx-1.5 - encodage
Jean-Marc Lasgouttes a écrit : Philippe == Philippe Charpentier [EMAIL PROTECTED] writes: Philippe Bonjour, je viens de tester lyx-1.5 (SVN) et j'ai constaté Philippe que mes fichiers layout et ui plantent lyx. Ceux-ci étaient Philippe écris en ISO-8859 et marchaient avec lyx-1.4.x Je les ai Philippe traduits en UTF-8 et cela ne change rien. Il semble que la Philippe seule solution soit de les écrire en ASCII, donc sans aucune Philippe lettre accentuée, ce qui n'est pas très agréable pour Philippe l'interface. Qu'en sera-t-il avec la future version lyx-1.5? Philippe Ces fichiers devront-ils être écris en ISO, en UTF-8 ou Philippe nécessairement en ASCII? Avant la version 1.5, LyX considérait juste les entrées comme du texte 8bits, rien de plus. Maintenant, avec unicode, ce n'est plus aussi simple. Pour les fichiers layouts, on va peut-être se diriger vers une solution ou le nom du style sera ascii et une nouvelle entrée GUIName permettra de dire comment afficher ce nom (en utf8). En y repensant, je vois plein de problèmes (comment utiliser les anciens fichiers avec des noms 8bits, par exemple ?) Je pense que ce serait bien d'envoyer un message sur lyx-devel en indiquant exactement quels sont les cas où le iso8859 n'est plus accepté, et parmi ceux-ci, quels sont les cas qu'il faudrait absolument corriger. JMarc Franchement, je ne sais pas trop quoi écrire sur lyx-devel : il y a deux problèmes : celui des layout et celui des ui. Pour le premier, il m'est difficile de dire ce qui va et ce qui ne va pas: par exemple, si j'écris uniquement un LabelString avec des caractères accentués, quelque soit l'encodage, lyx ne plante pas, mais rien ne s'affiche. Il semble, mais il faudrait faire plus de tests, que ce qui plante ce sont les noms de style qui ne sont pas en ASCII. Pour les second, il n'y a pas beaucoup de choix: si on veut une interface en français il faut bien mettre des caractères accentués et donc choisir l'encodage: qu'il soit en ISO ou en UTF-8 cela plante lyx (mais cela est peut être dû à un autre problème...). La question que je posais était donc: pour la future version de lyx, les fichiers layout et ui devront-ils être, théoriquement, encodés en ISO ou en UTF-8 (ceci se pose même s'il y a un GUIName). PhC
Re: lyx-1.5 - encodage
Philippe == Philippe Charpentier [EMAIL PROTECTED] writes: Philippe Franchement, je ne sais pas trop quoi écrire sur lyx-devel : Philippe il y a deux problèmes : celui des layout et celui des ui. Philippe Pour le premier, il m'est difficile de dire ce qui va et ce Philippe qui ne va pas: par exemple, si j'écris uniquement un Philippe LabelString avec des caractères accentués, quelque soit Philippe l'encodage, lyx ne plante pas, mais rien ne s'affiche. Normalement, les labelstring en utf8 devraient marcher. Sinon, c'est un bug. Philippe Il semble, mais il faudrait faire plus de tests, que ce qui Philippe plante ce sont les noms de style qui ne sont pas en ASCII. Oui, ca c'est normal, et il va falloir discuter de ce que l'on fait pour resoudre ca. C'est pour cela que l'avis de quelqu'un qui a des fichier layout de ce genre est utile. Philippe Pour les second, il n'y a pas beaucoup de choix: si on veut Philippe une interface en français il faut bien mettre des caractères Philippe accentués et donc choisir l'encodage: qu'il soit en ISO ou Philippe en UTF-8 cela plante lyx (mais cela est peut être dû à un Philippe autre problème...). Le probleme si je comprends bien est que l'on ne peut passer a gettext (qui traduit nos menus) que du ascii (a verifier). Il y a donc une solution a inventer pour quand on veut faire des menus en francais directement dans les fichiers. Pour que cela arrive, la encore il faut se manifester. Philippe La question que je posais était donc: pour la future version Philippe de lyx, les fichiers layout et ui devront-ils être, Philippe théoriquement, encodés en ISO ou en UTF-8 (ceci se pose même Philippe s'il y a un GUIName). utf8, je pense. JMarc
Re: lyx-1.5 - encodage
Jean-Marc Lasgouttes a écrit :
Normalement, les labelstring en utf8 devraient marcher. Sinon, c'est
un bug.
Cela ne plante pas actuellement.
Philippe Il semble, mais il faudrait faire plus de tests, que ce qui
Philippe plante ce sont les noms de style qui ne sont pas en ASCII.
Oui, ca c'est normal, et il va falloir discuter de ce que l'on fait
pour resoudre ca. C'est pour cela que l'avis de quelqu'un qui a des
fichier layout de ce genre est utile.
Je vais faire des essais en ayant tous les styles en ASCII.
J'ai une autre question: peux-t-on avoir la ligne suivante:
\DeclareLaTeXClass[amsart]{article (AMS, Français)}
avec bien sûr un ç , le tout en UTF-8?
Le probleme si je comprends bien est que l'on ne peut passer a gettext
(qui traduit nos menus) que du ascii (a verifier). Il y a donc une
solution a inventer pour quand on veut faire des menus en francais
directement dans les fichiers. Pour que cela arrive, la encore il faut
se manifester.
JMarc
Je veux bien comprendre qu'il y ait des difficultés pour obtenir des menus
suplémentaires en Français. Ce besoin provient de la structure de
l'interface de lyx. Une structure ressemblant à celle de Kile me
semblerait bien meilleure (c'est aussi l'avis de beaucoup de gens
qui, pour cette raison n'utilisent pas lyx): un paneau latéral où
l'on trouverai (entre autres) la palette mathématique et les
layouts de la classe utilisée rangés de façon intelligente (la combobox
des layouts de lyx est difficilement utilisable dans lyx-1.5 avec les
classes
standard et inutilisable avec des classes possédant un nombre
important de layouts) renderait l'utilisation de lyx beaucoup
plus conviviale.
PhC
Re: lyx-1.5 - encodage
Charpentier == Charpentier Philippe [EMAIL PROTECTED] writes:
Charpentier J'ai une autre question: peux-t-on avoir la ligne
Charpentier suivante:
Charpentier \DeclareLaTeXClass[amsart]{article (AMS, Français)}
Charpentier avec bien sûr un ç , le tout en UTF-8?
Pour l'instant non, parce que les decriptions sont stockees dans des
string normales. C'est typiquement un bug qui doit etre signale.
Charpentier Je veux bien comprendre qu'il y ait des difficultés pour
Charpentier obtenir des menus suplémentaires en Français. Ce besoin
Charpentier provient de la structure de l'interface de lyx. Une
Charpentier structure ressemblant à celle de Kile me semblerait bien
Charpentier meilleure (c'est aussi l'avis de beaucoup de gens qui,
Charpentier pour cette raison n'utilisent pas lyx): un paneau latéral
Charpentier où l'on trouverai (entre autres) la palette mathématique
Charpentier et les layouts de la classe utilisée rangés de façon
Charpentier intelligente (la combobox des layouts de lyx est
Charpentier difficilement utilisable dans lyx-1.5 avec les classes
Charpentier standard et inutilisable avec des classes possédant un
Charpentier nombre important de layouts) renderait l'utilisation de
Charpentier lyx beaucoup plus conviviale.
Je ne suis pas sur du rapport entre ca et les menus en francais...
JMarc
Re: lyx-1.5 - encodage
Jean-Marc Lasgouttes a écrit : Charpentier Je veux bien comprendre qu'il y ait des difficultés pour Charpentier obtenir des menus suplémentaires en Français. Ce besoin Charpentier provient de la structure de l'interface de lyx. Une Charpentier structure ressemblant à celle de Kile me semblerait bien Charpentier meilleure (c'est aussi l'avis de beaucoup de gens qui, Charpentier pour cette raison n'utilisent pas lyx): un paneau latéral Charpentier où l'on trouverai (entre autres) la palette mathématique Charpentier et les layouts de la classe utilisée rangés de façon Charpentier intelligente (la combobox des layouts de lyx est Charpentier difficilement utilisable dans lyx-1.5 avec les classes Charpentier standard et inutilisable avec des classes possédant un Charpentier nombre important de layouts) renderait l'utilisation de Charpentier lyx beaucoup plus conviviale. Je ne suis pas sur du rapport entre ca et les menus en francais... JMarc Je ne sais pas... Mais je pense qu'une telle structure rendrait nécessaire la lecture des layouts correcte (et donc un encodage sûr) alors que l'on peut toujours discuter sur l'intérêt de menus supplémentaires. Enfin, les menus restant alors ceux de base il n'y aurait plus de problèmes récurrents avec les fichiers ui. PhC
Re: lyx-1.5 - encodage
> "Philippe" == Philippe Charpentier <[EMAIL PROTECTED]> writes: Philippe> Bonjour, je viens de tester lyx-1.5 (SVN) et j'ai constaté Philippe> que mes fichiers layout et ui plantent lyx. Ceux-ci étaient Philippe> écris en ISO-8859 et marchaient avec lyx-1.4.x Je les ai Philippe> traduits en UTF-8 et cela ne change rien. Il semble que la Philippe> seule solution soit de les écrire en ASCII, donc sans aucune Philippe> lettre accentuée, ce qui n'est pas très agréable pour Philippe> l'interface. Qu'en sera-t-il avec la future version lyx-1.5? Philippe> Ces fichiers devront-ils être écris en ISO, en UTF-8 ou Philippe> nécessairement en ASCII? Avant la version 1.5, LyX considérait juste les entrées comme du texte 8bits, rien de plus. Maintenant, avec unicode, ce n'est plus aussi simple. Pour les fichiers layouts, on va peut-être se diriger vers une solution ou le nom du style sera ascii et une nouvelle entrée GUIName permettra de dire comment afficher ce nom (en utf8). En y repensant, je vois plein de problèmes (comment utiliser les anciens fichiers avec des noms 8bits, par exemple ?) Je pense que ce serait bien d'envoyer un message sur lyx-devel en indiquant exactement quels sont les cas où le iso8859 n'est plus accepté, et parmi ceux-ci, quels sont les cas qu'il faudrait absolument corriger. JMarc
Re: lyx-1.5 - encodage
Jean-Marc Lasgouttes a écrit : "Philippe" == Philippe Charpentier <[EMAIL PROTECTED]> writes: Philippe> Bonjour, je viens de tester lyx-1.5 (SVN) et j'ai constaté Philippe> que mes fichiers layout et ui plantent lyx. Ceux-ci étaient Philippe> écris en ISO-8859 et marchaient avec lyx-1.4.x Je les ai Philippe> traduits en UTF-8 et cela ne change rien. Il semble que la Philippe> seule solution soit de les écrire en ASCII, donc sans aucune Philippe> lettre accentuée, ce qui n'est pas très agréable pour Philippe> l'interface. Qu'en sera-t-il avec la future version lyx-1.5? Philippe> Ces fichiers devront-ils être écris en ISO, en UTF-8 ou Philippe> nécessairement en ASCII? Avant la version 1.5, LyX considérait juste les entrées comme du texte 8bits, rien de plus. Maintenant, avec unicode, ce n'est plus aussi simple. Pour les fichiers layouts, on va peut-être se diriger vers une solution ou le nom du style sera ascii et une nouvelle entrée GUIName permettra de dire comment afficher ce nom (en utf8). En y repensant, je vois plein de problèmes (comment utiliser les anciens fichiers avec des noms 8bits, par exemple ?) Je pense que ce serait bien d'envoyer un message sur lyx-devel en indiquant exactement quels sont les cas où le iso8859 n'est plus accepté, et parmi ceux-ci, quels sont les cas qu'il faudrait absolument corriger. JMarc Franchement, je ne sais pas trop quoi écrire sur lyx-devel : il y a deux problèmes : celui des layout et celui des ui. Pour le premier, il m'est difficile de dire ce qui va et ce qui ne va pas: par exemple, si j'écris uniquement un LabelString avec des caractères accentués, quelque soit l'encodage, lyx ne plante pas, mais rien ne s'affiche. Il semble, mais il faudrait faire plus de tests, que ce qui plante ce sont les noms de style qui ne sont pas en ASCII. Pour les second, il n'y a pas beaucoup de choix: si on veut une interface en français il faut bien mettre des caractères accentués et donc choisir l'encodage: qu'il soit en ISO ou en UTF-8 cela plante lyx (mais cela est peut être dû à un autre problème...). La question que je posais était donc: pour la future version de lyx, les fichiers layout et ui devront-ils être, théoriquement, encodés en ISO ou en UTF-8 (ceci se pose même s'il y a un GUIName). PhC
Re: lyx-1.5 - encodage
> "Philippe" == Philippe Charpentier <[EMAIL PROTECTED]> writes: Philippe> Franchement, je ne sais pas trop quoi écrire sur lyx-devel : Philippe> il y a deux problèmes : celui des layout et celui des ui. Philippe> Pour le premier, il m'est difficile de dire ce qui va et ce Philippe> qui ne va pas: par exemple, si j'écris uniquement un Philippe> LabelString avec des caractères accentués, quelque soit Philippe> l'encodage, lyx ne plante pas, mais rien ne s'affiche. Normalement, les labelstring en utf8 devraient marcher. Sinon, c'est un bug. Philippe> Il semble, mais il faudrait faire plus de tests, que ce qui Philippe> plante ce sont les noms de style qui ne sont pas en ASCII. Oui, ca c'est normal, et il va falloir discuter de ce que l'on fait pour resoudre ca. C'est pour cela que l'avis de quelqu'un qui a des fichier layout de ce genre est utile. Philippe> Pour les second, il n'y a pas beaucoup de choix: si on veut Philippe> une interface en français il faut bien mettre des caractères Philippe> accentués et donc choisir l'encodage: qu'il soit en ISO ou Philippe> en UTF-8 cela plante lyx (mais cela est peut être dû à un Philippe> autre problème...). Le probleme si je comprends bien est que l'on ne peut passer a gettext (qui traduit nos menus) que du ascii (a verifier). Il y a donc une solution a inventer pour quand on veut faire des menus en francais directement dans les fichiers. Pour que cela arrive, la encore il faut se manifester. Philippe> La question que je posais était donc: pour la future version Philippe> de lyx, les fichiers layout et ui devront-ils être, Philippe> théoriquement, encodés en ISO ou en UTF-8 (ceci se pose même Philippe> s'il y a un GUIName). utf8, je pense. JMarc
Re: lyx-1.5 - encodage
Jean-Marc Lasgouttes a écrit :
Normalement, les labelstring en utf8 devraient marcher. Sinon, c'est
un bug.
Cela ne plante pas actuellement.
Philippe> Il semble, mais il faudrait faire plus de tests, que ce qui
Philippe> plante ce sont les noms de style qui ne sont pas en ASCII.
Oui, ca c'est normal, et il va falloir discuter de ce que l'on fait
pour resoudre ca. C'est pour cela que l'avis de quelqu'un qui a des
fichier layout de ce genre est utile.
Je vais faire des essais en ayant tous les styles en ASCII.
J'ai une autre question: peux-t-on avoir la ligne suivante:
\DeclareLaTeXClass[amsart]{article (AMS, Français)}
avec bien sûr un ç , le tout en UTF-8?
Le probleme si je comprends bien est que l'on ne peut passer a gettext
(qui traduit nos menus) que du ascii (a verifier). Il y a donc une
solution a inventer pour quand on veut faire des menus en francais
directement dans les fichiers. Pour que cela arrive, la encore il faut
se manifester.
JMarc
Je veux bien comprendre qu'il y ait des difficultés pour obtenir des menus
suplémentaires en Français. Ce besoin provient de la structure de
l'interface de lyx. Une structure ressemblant à celle de Kile me
semblerait bien meilleure (c'est aussi l'avis de beaucoup de gens
qui, pour cette raison n'utilisent pas lyx): un paneau latéral où
l'on trouverai (entre autres) la palette mathématique et les
layouts de la classe utilisée rangés de façon intelligente (la combobox
des layouts de lyx est difficilement utilisable dans lyx-1.5 avec les
classes
standard et inutilisable avec des classes possédant un nombre
important de layouts) renderait l'utilisation de lyx beaucoup
plus conviviale.
PhC
Re: lyx-1.5 - encodage
> "Charpentier" == Charpentier Philippe <[EMAIL PROTECTED]> writes:
Charpentier> J'ai une autre question: peux-t-on avoir la ligne
Charpentier> suivante:
Charpentier> \DeclareLaTeXClass[amsart]{article (AMS, Français)}
Charpentier> avec bien sûr un ç , le tout en UTF-8?
Pour l'instant non, parce que les decriptions sont stockees dans des
string normales. C'est typiquement un bug qui doit etre signale.
Charpentier> Je veux bien comprendre qu'il y ait des difficultés pour
Charpentier> obtenir des menus suplémentaires en Français. Ce besoin
Charpentier> provient de la structure de l'interface de lyx. Une
Charpentier> structure ressemblant à celle de Kile me semblerait bien
Charpentier> meilleure (c'est aussi l'avis de beaucoup de gens qui,
Charpentier> pour cette raison n'utilisent pas lyx): un paneau latéral
Charpentier> où l'on trouverai (entre autres) la palette mathématique
Charpentier> et les layouts de la classe utilisée rangés de façon
Charpentier> intelligente (la combobox des layouts de lyx est
Charpentier> difficilement utilisable dans lyx-1.5 avec les classes
Charpentier> standard et inutilisable avec des classes possédant un
Charpentier> nombre important de layouts) renderait l'utilisation de
Charpentier> lyx beaucoup plus conviviale.
Je ne suis pas sur du rapport entre ca et les menus en francais...
JMarc
Re: lyx-1.5 - encodage
Jean-Marc Lasgouttes a écrit : Charpentier> Je veux bien comprendre qu'il y ait des difficultés pour Charpentier> obtenir des menus suplémentaires en Français. Ce besoin Charpentier> provient de la structure de l'interface de lyx. Une Charpentier> structure ressemblant à celle de Kile me semblerait bien Charpentier> meilleure (c'est aussi l'avis de beaucoup de gens qui, Charpentier> pour cette raison n'utilisent pas lyx): un paneau latéral Charpentier> où l'on trouverai (entre autres) la palette mathématique Charpentier> et les layouts de la classe utilisée rangés de façon Charpentier> intelligente (la combobox des layouts de lyx est Charpentier> difficilement utilisable dans lyx-1.5 avec les classes Charpentier> standard et inutilisable avec des classes possédant un Charpentier> nombre important de layouts) renderait l'utilisation de Charpentier> lyx beaucoup plus conviviale. Je ne suis pas sur du rapport entre ca et les menus en francais... JMarc Je ne sais pas... Mais je pense qu'une telle structure rendrait nécessaire la lecture des layouts correcte (et donc un encodage sûr) alors que l'on peut toujours discuter sur l'intérêt de menus supplémentaires. Enfin, les menus restant alors ceux de base il n'y aurait plus de problèmes récurrents avec les fichiers ui. PhC
