Re: Dynamic insets
Am Dienstag, dem 18.05.2021 um 17:33 +0200 schrieb Jean-Pierre Chrétien: > > Probably all should use info insets. > > Is it correct to state that all the recognised strings are given in > the LFUNS > mùanual, under 'dialog-show' ? I'd say so. Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Dynamic insets
Le 18/05/2021 à 07:52, Jürgen Spitzmüller a écrit : Am Montag, dem 17.05.2021 um 16:07 +0200 schrieb Jean-Pierre Chrétien: Finally, it seems that not all menu entries appear in dynamic insets. What are exactly those which are liable to do so (the list in the inset parameters is not very explicit)? And is it done everywhere where it can be in the English docs? If not, is this a target to achieve? Probably all should use info insets. Is it correct to state that all the recognised strings are given in the LFUNS mùanual, under 'dialog-show' ? As a conclusion, where is the dynamic inset feature documented? I do not remember to have translated it. User Guide A.4.4 Thanks, indeed, it needs to be translated in French. -- Jean-Pierre -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Dynamic insets
Am Montag, dem 17.05.2021 um 16:07 +0200 schrieb Jean-Pierre Chrétien: > Then I wondered if the UI should be dynamic in the translated > manuals, as a > reader of the e.g. French manual will have the UI in French. Not necessarily. I reader of the German manual could prefer to have an English UI (or vice versa, a user of German UI could prefer to read to English manuals). In both cases it is good that the manuals describe the current UI. > Finally, it seems that not all menu entries appear in dynamic insets. > What are exactly those which are liable to do so (the list in the > inset parameters is not very explicit)? And is it done everywhere > where it can be in the English docs? > If not, is this a target to achieve? Probably all should use info insets. > As a conclusion, where is the dynamic inset feature documented? I do > not remember to have translated it. User Guide A.4.4 Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Dynamic insets
Dear Developers Following a discussion on lyx-docs about the Text Style menu, I g=have a couple of questions about the dynamic insets feature. First of all, the advantages of such a feature, as far as menus are concerned, is twofold: A/ the menu names appears translated in the UI language when the reader opens a manual; B/ any change in the po file is corrected automagically in the docs. Initially I thought that the translation in the language of the UI should not appear in the pdf export, but I understood that it was easy to create a PDF in English by changing the locale before calling LyX. Then I wondered if the UI should be dynamic in the translated manuals, as a reader of the e.g. French manual will have the UI in French. But feature B remains an incentive to keep it dynamic there also. I'm not sure to have it a all places, I will check that. Finally, it seems that not all menu entries appear in dynamic insets. What are exactly those which are liable to do so (the list in the inset parameters is not very explicit)? And is it done everywhere where it can be in the English docs? If not, is this a target to achieve? As a conclusion, where is the dynamic inset feature documented? I do not remember to have translated it. -- Regards Jean-Pierre -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: microscripting in lyx-documents - dynamic insets ?
> "Joachim" == Joachim Heidemeier <[EMAIL PROTECTED]> writes: >> Did you have a look at external insets? Joachim> Do you mean the include or input insets? But they are static Joachim> insets, so no database input etc. when generating the Joachim> document External insets can be configure to use scripts to generate their contents. As an example, it is possible to insert chess position PGN files and have latex do the right thing. For more information, have a look at chapter 8 of the Customization manual. JMarc
Re: microscripting in lyx-documents - dynamic insets ?
On 22 Jul 2002, Jean-Marc Lasgouttes wrote: > Date: 22 Jul 2002 10:40:23 +0200 > From: Jean-Marc Lasgouttes <[EMAIL PROTECTED]> > To: J. Heidemeier <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: microscripting in lyx-documents - dynamic insets ? > > >>>>> "Joachim" == Joachim Heidemeier <[EMAIL PROTECTED]> writes: > > Joachim> Hello lyx-developers, I now have the problem, that parts of a > Joachim> document I'm working on has very often changing tables, > Joachim> generated from csv-tables or even a database-backend. So I > Joachim> have the idea to process template files with included > Joachim> tcl-code. This code is substituted and the result ist the > Joachim> actual lyx-document, which in turn can be cached. Well, to be > Joachim> honest, this is not my idea but the mechanism how Brent > Joachim> Welch's tclhttp server handles its templates and I'd adapt > Joachim> this code to handling lyx-documents. The problem I have is > Joachim> how to best mark the tcl-code best in a .tlx (template-lyx > Joachim> :-) file. > > Did you have a look at external insets? Do you mean the include or input insets? But they are static insets, so no database input etc. when generating the document > > Joachim> One idea is to use: \begin_inset x-tcl-subst tclcode > Joachim> \end_inset. So a template file: ... \layout standard > > Joachim> blah \begin_inset x-tcl-subst [clock format [clock seconds]] > Joachim> \end_inset ... would become ... \layout standard > > Joachim> blah Mon Jul 22 10:19:08 CEST 2002 ... . But how does lyx > Joachim> react on unknown inset-types or does this idea breaks any > Joachim> existing concepts? Comments welcome. > > When finding unknown inset types, LyX just ignores them, I believe. > Not very useful in your case. As the template processor could run outside lyx it would do no harm, but is of course not integrated into lyx which means you can't trigger a document generation from the template from within lyx > > JMarc > joachim -- Dr. Joachim Heidemeier Tel. +49-30-8903-2780 Fachgebiet II 3.2 [EMAIL PROTECTED] Umweltbundesamt, Bismarckplatz 1 D-14191 Berlin
Re: microscripting in lyx-documents - dynamic insets ?
> "Joachim" == Joachim Heidemeier <[EMAIL PROTECTED]> writes: Joachim> Hello lyx-developers, I now have the problem, that parts of a Joachim> document I'm working on has very often changing tables, Joachim> generated from csv-tables or even a database-backend. So I Joachim> have the idea to process template files with included Joachim> tcl-code. This code is substituted and the result ist the Joachim> actual lyx-document, which in turn can be cached. Well, to be Joachim> honest, this is not my idea but the mechanism how Brent Joachim> Welch's tclhttp server handles its templates and I'd adapt Joachim> this code to handling lyx-documents. The problem I have is Joachim> how to best mark the tcl-code best in a .tlx (template-lyx Joachim> :-) file. Did you have a look at external insets? Joachim> One idea is to use: \begin_inset x-tcl-subst tclcode Joachim> \end_inset. So a template file: ... \layout standard Joachim> blah \begin_inset x-tcl-subst [clock format [clock seconds]] Joachim> \end_inset ... would become ... \layout standard Joachim> blah Mon Jul 22 10:19:08 CEST 2002 ... . But how does lyx Joachim> react on unknown inset-types or does this idea breaks any Joachim> existing concepts? Comments welcome. When finding unknown inset types, LyX just ignores them, I believe. Not very useful in your case. JMarc
microscripting in lyx-documents - dynamic insets ?
Hello lyx-developers, I now have the problem, that parts of a document I'm working on has very often changing tables, generated from csv-tables or even a database-backend. So I have the idea to process template files with included tcl-code. This code is substituted and the result ist the actual lyx-document, which in turn can be cached. Well, to be honest, this is not my idea but the mechanism how Brent Welch's tclhttp server handles its templates and I'd adapt this code to handling lyx-documents. The problem I have is how to best mark the tcl-code best in a .tlx (template-lyx :-) file. One idea is to use: \begin_inset x-tcl-subst tclcode \end_inset. So a template file: ... \layout standard blah \begin_inset x-tcl-subst [clock format [clock seconds]] \end_inset ... would become ... \layout standard blah Mon Jul 22 10:19:08 CEST 2002 ... . But how does lyx react on unknown inset-types or does this idea breaks any existing concepts? Comments welcome. Yours -- Dr. Joachim Heidemeier Tel. +49-30-8903-2780 Fachgebiet II 3.2 [EMAIL PROTECTED] Umweltbundesamt, Bismarckplatz 1 D-14191 Berlin
