Re: RefStyle, Again

Richard Heck wrote: I'm really unsure now how to proceed. So comments welcome. I'm unsure as well. We should get rid of prettyref eventually, because of its shortcomings (especially i18n). On the other hand, it just works for people who currently use it, and the risk of breaking working

Re: r34866 - lyx-devel/branches/BRANCH_1_6_X/development

spitz wrote: Author: spitz Date: Mon Jul 12 10:17:13 2010 New Revision: 34866 URL: http://www.lyx.org/trac/changeset/34866 Log: * Makefile.am: fix file name. Uwe, is it really necessary to rename this file at every release? I have to fix the Makefile at every release at make dist step;

branch still frozen

Please no commits to branch whatsoever without discussion on this list. Jürgen

Re: LyX 1.6.7

Peter Kuemmel wrote: It's a bug in the STL implementation of msvc10: http://connect.microsoft.com/VisualStudio/feedback/details/572376/msvc1 0-c-std-numpunct-has-a-hardcoded-dllimport-in-definition We already had a workaround in trunk, which is now also in branch, so now I have no

Re: r34810 - lyx-devel/trunk/src

Stephan Witt st.w...@gmx.net writes: With some googling I've learned we're not alone. Perhaps the theory mentioned above doesn't hold for c++ code. That would be bad. I'll then forced to build with 10.5 SDK or maybe 10.4 and cannot use the new 10.6 features. When compiling with 10.5 SDK I

Re: r34829 - in lyx-devel/branches/BRANCH_1_6_X: . lib/doc/fr

Enrico Forestieri for...@lyx.org writes: Translators should be advised not to translate neither LYX_USERDIR_VER nor LYX_DIR_VER, as they will be replaced by the correct values at install time. Translating them, prevents this mechanism and they can have wrong values if one forgets to update

Re: LyX 1.6.7

On Mon, Jul 12, 2010 at 10:46:04AM +0200, Jürgen Spitzmüller wrote: Peter Kuemmel wrote: It's a bug in the STL implementation of msvc10: http://connect.microsoft.com/VisualStudio/feedback/details/572376/msvc1 0-c-std-numpunct-has-a-hardcoded-dllimport-in-definition We already

Re: LyX 1.6.7

Enrico Forestieri wrote: Joost, can you please try the new tarballs at ftp://ftp.devel.lyx.org/pub/lyx/stable/lyx-1.6.7.tar.gz ftp://ftp.devel.lyx.org/pub/lyx/stable/lyx-1.6.7.tar.bz2 ? The file src/support/numpunct_lyx_char_type.h is missing from the tarball. It was

Re: #6805: Cannot convert file importing from RTF, but works on the command line

Stephan Witt wrote: Yes, but tex2lyx fails when run from LyX as converter. The output of this operation I'm looking for. E. g. with adding a -v to the converter config line or something similar. But possibly there is some output already and it is lost somehow... I see in the

Re: [patch] support for the DIN ISO C paper format series

Uwe Stöhr wrote: The new geometry version now also allows to use DIN-ISO C paper sizes for documents. The attached patch implements them for LyX. This will be a fileformat change. i miss FORMAT entry and version should incerease too. pavel

Re: LyX 1.6.7

Jürgen Spitzmüller wrote: Enrico Forestieri wrote: Joost, can you please try the new tarballs at ftp://ftp.devel.lyx.org/pub/lyx/stable/lyx-1.6.7.tar.gz ftp://ftp.devel.lyx.org/pub/lyx/stable/lyx-1.6.7.tar.bz2 ? The file src/support/numpunct_lyx_char_type.h is

Re: #6805: Cannot convert file importing from RTF, but works on the command line

Am 12.07.2010 um 13:43 schrieb Pavel Sanda: Stephan Witt wrote: Yes, but tex2lyx fails when run from LyX as converter. The output of this operation I'm looking for. E. g. with adding a -v to the converter config line or something similar. But possibly there is some output already and it is

Re: r34742 - lyx-devel/trunk/src/support/mythes

Joost Verburg wrote: I was talking about the packaging. The source would be the SVN repository. Automatic zipping is a good idea! i've created standardsvn structure there, so put all the stuff you had in mind into svn://svn.lyx.org/lyx/dictionaries/trunk pavel

Re: RefStyle, Again

Jürgen Spitzmüller wrote: Richard Heck wrote: So I'm in favour to keep the prettyref option for now. This would probably make the change for everyone (except for the developers) a bit more smooth, and we can test how refstyle works out in real life before killing prettyref. +1 pavel

Re: r34873 - in lyx-devel/tags/lyx-1_6_7: . development development/scons src/support

Am Montag 12 Juli 2010 schrieb sp...@lyx.org: Log: This is LyX 1.6.7 (fourth attempt) Some cmake-files are missing in development/Makefile.am. Kornel Index: development/Makefile.am === --- development/Makefile.am

Re: r34873 - in lyx-devel/tags/lyx-1_6_7: . development development/scons src/support

Kornel Benko wrote: Some cmake-files are missing in development/Makefile.am. *Sigh* Put it in, please. Jürgen

Re: r34877 - lyx-devel/branches/BRANCH_1_6_X/development

kornel wrote: Author: kornel Date: Mon Jul 12 15:04:13 2010 New Revision: 34877 URL: http://www.lyx.org/trac/changeset/34877 Log: Add missing cmake-files New tarball is to be found at the usual location. Jürgen

Re: r34829 - in lyx-devel/branches/BRANCH_1_6_X: . lib/doc/fr

On 07/12/2010 06:20 AM, Jean-Marc LASGOUTTES wrote: Enrico Forestierifor...@lyx.org writes: Translators should be advised not to translate neither LYX_USERDIR_VER nor LYX_DIR_VER, as they will be replaced by the correct values at install time. Translating them, prevents this mechanism and

Re: Lyxserver - citation-insert

Petr Šimon wrote: Hello, I have a question about citation-insert, which I use from a Firefox extension Lyz, a plugin for Zotero. When I set the citation format to (Author, year) (using natbib and plainnat) and send citation-insert to lyxserver the citation is inserted as Author (year), i.e.

Re: r34860 - in lyx-devel/branches/BRANCH_1_6_X/development/cmake: . doc lyx2lyx man po src

Kornel Benko wrote: Am Sonntag 11 Juli 2010 schrieb kuem...@lyx.org: +message(STATUS Switch LYX_* variables by -DLYX_*=1 or 0:) Should the message not be rather +message(STATUS Switch LYX_* variables by -DLYX_*=ON or OFF:) ? Looks more consistent. Yes, but when using the command

Re: LyX 1.6.7

Verburg wrote: On 7/11/2010 5:44 PM, Uwe Stöhr wrote: Fine. I use MSVC 2008 and am therefore not affected by the MSVC problems. I've created up-to-date binaries of all the dependencies for MSVC 2010: ftp://ftp.devel.lyx.org/pub/contrib/windows/bin/

Re: r34829 - in lyx-devel/branches/BRANCH_1_6_X: . lib/doc/fr

Richard Heck rgh...@comcast.net writes: We could maybe extend InsetInfo to cover this in 2.0. Or is it already the case? What is it that we want? Tell the user what is the name of the environment variables that should be set to tell for ex. where is the user directory. This is an information

Re: r34860 - in lyx-devel/branches/BRANCH_1_6_X/development/cmake: . doc lyx2lyx man po src

Am Montag 12 Juli 2010 schrieb Peter Kümmel: ... Yes, but when using the command line typing 0 or 1 is simpler. Not nice, but ok ... And why do we need e.g. LYX_PYTHON_EXECUTABLE? This looks as if python (or perl) would belong to lyx. (For found libraries we don't have this too)

Dependency Problem?

Changing LaTeXUi.ui causes recompilation of GuiBranch.o and GuiIndices.o. Is that right? rh

Unavailable Classes

As shown below, our use of the term Unavailable to mark classes missing prerequisites can be confusing to people, and I'm sympathetic. These classes can be used, and marking them as unavailable makes it seem as if they can't be. I am also not sure that we should list all the unavailable

Re: r34860 - in lyx-devel/branches/BRANCH_1_6_X/development/cmake: . doc lyx2lyx man po src

Original-Nachricht Datum: Mon, 12 Jul 2010 17:43:28 +0200 Von: Kornel Benko kor...@lyx.org An: lyx-devel@lists.lyx.org Betreff: Re: r34860 - in lyx-devel/branches/BRANCH_1_6_X/development/cmake: . doc lyx2lyx man po src Am Montag 12 Juli 2010 schrieb Peter Kümmel: ...

Re: r34810 - lyx-devel/trunk/src

Am 12.07.2010 um 12:13 schrieb Jean-Marc LASGOUTTES: Stephan Witt st.w...@gmx.net writes: With some googling I've learned we're not alone. Perhaps the theory mentioned above doesn't hold for c++ code. That would be bad. I'll then forced to build with 10.5 SDK or maybe 10.4 and cannot use the

Copy and Paste in Multi-File Documents

Hello, I just noticed a weired copy and paste behavior when working in a multi-file document when copying a Section (including figure floats etc.) from one file to another file of the document (actually both files are child documents of the same master document). When copying all the formating

Re: Dependency Problem?

Op 12-7-2010 20:05, Richard Heck schreef: Changing LaTeXUi.ui causes recompilation of GuiBranch.o and GuiIndices.o. Is that right? rh Fixed in trunk at r34882. Vincent

Re: Dependency Problem?

On 07/12/2010 05:43 PM, Vincent van Ravesteijn wrote: Op 12-7-2010 20:05, Richard Heck schreef: Changing LaTeXUi.ui causes recompilation of GuiBranch.o and GuiIndices.o. Is that right? rh Fixed in trunk at r34882. Thanks. rh

Re: Copy and Paste in Multi-File Documents

On 07/12/2010 05:33 PM, Rainer Dorsch wrote: Hello, I just noticed a weired copy and paste behavior when working in a multi-file document when copying a Section (including figure floats etc.) from one file to another file of the document (actually both files are child documents of the same

Bug #3221: nameref support

The attached patch implements nameref support in cross-references. The only thing I'm not sure about, which Uwe mentioned in the bug, is the precise loading order of packages. If we're loading hyperref anyway, then there's no issue, since it loads nameref. But if we aren't, then maybe

Re: Bug #3221: nameref support

On 07/12/2010 06:00 PM, Richard Heck wrote: The attached patch implements nameref support in cross-references. The only thing I'm not sure about, which Uwe mentioned in the bug, is the precise loading order of packages. If we're loading hyperref anyway, then there's no issue, since it loads

Re: r34877 - lyx-devel/branches/BRANCH_1_6_X/development

On 7/12/2010 9:17 AM, Jürgen Spitzmüller wrote: New tarball is to be found at the usual location. CMake still doesn't work. I'm getting a lot of errors. Trying SCons now. Joost

Re: r34810 - lyx-devel/trunk/src

On Mon, Jul 12, 2010 at 4:48 PM, Stephan Witt st.w...@gmx.net wrote: Am 12.07.2010 um 12:13 schrieb Jean-Marc LASGOUTTES: Stephan Witt st.w...@gmx.net writes: With some googling I've learned we're not alone. Perhaps the theory mentioned above doesn't hold for c++ code. That would be bad. I'll

Re: [patch] support for the DIN ISO C paper format series

i miss FORMAT entry and version should incerease too. I don't increase the fileformat in these patches to be able to apply the patch and test it without having conflicts with other patches you might have in your tree. As no one is opposed to this patch and as it is straight forward, I have

Re: r34877 - lyx-devel/branches/BRANCH_1_6_X/development

On 7/12/2010 8:47 PM, Joost Verburg wrote: Trying SCons now. Also doesn't work. src\frontends\qt4\GuiCommandBuffer.cpp(319) : error C2668: 'lyx::copy_if' : ambiguous call to overloaded function Joost

Re: r34866 - lyx-devel/branches/BRANCH_1_6_X/development

Uwe, is it really necessary to rename this file at every release? No. I'll rename it for the next version. I have to fix the Makefile at every release at make dist step; this is quite annoying. I wasn't aware that you also take care about the Windows installer files. sorry and regards Uwe

Re: LyX 1.6.7

With the latest updates in trunk it's now possible to run LyX by just clicking lyx.exe, without the need for a launcher or any registry keys or environment variables. Very nice! Can you please tell me how to compile LyX to achieve this? I'm still stuck with your new compilation option and

Bug #3221: nameref support

The only thing I'm not sure about, which Uwe mentioned in the bug, is the precise loading order of packages. This doesn't seem to be an issue with the new nameref version because the former conflicts with memoir and varioref are resolved. I did some test and your implementation works fine

Re: LyX 1.6.7

On 7/12/2010 9:35 PM, Uwe Stöhr wrote: Very nice! Can you please tell me how to compile LyX to achieve this? I'm still stuck with your new compilation option and don't know where to specify it. Use CMake in Trunk and set LYX_NOCONSOLE. I've created up-to-date binaries of all the

Re: Bug #3221: nameref support

There is another issue: The text on page is not yet translated to the document language. One manually has to add this preamble code: \renewcommand*\Nameref[1]{`\nameref{#1}' auf Seite~\pageref{#1}} auf Seite is hereby the German translation of on page. As this is no solution for us I propose

Re: Bug #3221: nameref support

On 07/12/2010 10:04 PM, Uwe Stöhr wrote: The only thing I'm not sure about, which Uwe mentioned in the bug, is the precise loading order of packages. This doesn't seem to be an issue with the new nameref version because the former conflicts with memoir and varioref are resolved. OK, good.

Re: Bug #3221: nameref support

On 07/12/2010 10:51 PM, Uwe Stöhr wrote: There is another issue: The text on page is not yet translated to the document language. One manually has to add this preamble code: \renewcommand*\Nameref[1]{`\nameref{#1}' auf Seite~\pageref{#1}} auf Seite is hereby the German translation of on page.

Re: RefStyle, Again

Richard Heck wrote: > I'm really unsure now how to proceed. So comments welcome. I'm unsure as well. We should get rid of prettyref eventually, because of its shortcomings (especially i18n). On the other hand, it just works for people who currently use it, and the risk of breaking working

Re: r34866 - lyx-devel/branches/BRANCH_1_6_X/development

spitz wrote: > Author: spitz > Date: Mon Jul 12 10:17:13 2010 > New Revision: 34866 > URL: http://www.lyx.org/trac/changeset/34866 > > Log: > * Makefile.am: fix file name. Uwe, is it really necessary to rename this file at every release? I have to fix the Makefile at every release at make dist

branch still frozen

Please no commits to branch whatsoever without discussion on this list. Jürgen

Re: LyX 1.6.7

Peter Kuemmel wrote: > It's a bug in the STL implementation of msvc10: > > http://connect.microsoft.com/VisualStudio/feedback/details/572376/msvc1 > 0-c-std-numpunct-has-a-hardcoded-dllimport-in-definition > > We already had a workaround in trunk, which is now also in branch, > so now I have

Re: r34810 - lyx-devel/trunk/src

Stephan Witt writes: > With some googling I've learned we're not alone. Perhaps the theory > mentioned above doesn't hold for c++ code. That would be bad. I'll > then forced to build with 10.5 SDK or maybe 10.4 and cannot use the > new 10.6 features. When compiling with 10.5 SDK

Re: r34829 - in lyx-devel/branches/BRANCH_1_6_X: . lib/doc/fr

Enrico Forestieri writes: > Translators should be advised not to translate neither LYX_USERDIR_VER > nor LYX_DIR_VER, as they will be replaced by the correct values at > install time. Translating them, prevents this mechanism and they can > have wrong values if one forgets to

Re: LyX 1.6.7

On Mon, Jul 12, 2010 at 10:46:04AM +0200, Jürgen Spitzmüller wrote: > Peter Kuemmel wrote: > > It's a bug in the STL implementation of msvc10: > > > > http://connect.microsoft.com/VisualStudio/feedback/details/572376/msvc1 > > 0-c-std-numpunct-has-a-hardcoded-dllimport-in-definition > > > >

Re: LyX 1.6.7

Enrico Forestieri wrote: > > Joost, can you please try the new tarballs at > > > > > > ftp://ftp.devel.lyx.org/pub/lyx/stable/lyx-1.6.7.tar.gz > > ftp://ftp.devel.lyx.org/pub/lyx/stable/lyx-1.6.7.tar.bz2 ? > > The file src/support/numpunct_lyx_char_type.h is missing from the >

Re: #6805: "Cannot convert file" importing from RTF, but works on the command line

Stephan Witt wrote: > > Yes, but tex2lyx fails when run from LyX as converter. The output of this > > operation I'm looking for. > > E. g. with adding a -v to the converter config line or something similar. > > But possibly there is some output already and it is lost somehow... > > I see in the

Re: [patch] support for the DIN ISO C paper format series

Uwe Stöhr wrote: > The new geometry version now also allows to use DIN-ISO C paper sizes for > documents. The attached patch implements them for LyX. This will be a > fileformat change. i miss FORMAT entry and version should incerease too. pavel

Re: LyX 1.6.7

Jürgen Spitzmüller wrote: > Enrico Forestieri wrote: > > > Joost, can you please try the new tarballs at > > > > > > > > > ftp://ftp.devel.lyx.org/pub/lyx/stable/lyx-1.6.7.tar.gz > > > ftp://ftp.devel.lyx.org/pub/lyx/stable/lyx-1.6.7.tar.bz2 ? > > > > The file

Re: #6805: "Cannot convert file" importing from RTF, but works on the command line

Am 12.07.2010 um 13:43 schrieb Pavel Sanda: > Stephan Witt wrote: >>> Yes, but tex2lyx fails when run from LyX as converter. The output of this >>> operation I'm looking for. >>> E. g. with adding a -v to the converter config line or something similar. >>> But possibly there is some output

Re: r34742 - lyx-devel/trunk/src/support/mythes

Joost Verburg wrote: > I was talking about the packaging. The source would be the SVN repository. > Automatic zipping is a good idea! i've created standardsvn structure there, so put all the stuff you had in mind into svn://svn.lyx.org/lyx/dictionaries/trunk pavel

Re: RefStyle, Again

Jürgen Spitzmüller wrote: > Richard Heck wrote: > So I'm in favour to keep the prettyref option for now. This would probably > make the change for everyone (except for the developers) a bit more smooth, > and we can test how refstyle works out in real life before killing prettyref. +1 pavel

Re: r34873 - in lyx-devel/tags/lyx-1_6_7: . development development/scons src/support

Am Montag 12 Juli 2010 schrieb sp...@lyx.org: > Log: > This is LyX 1.6.7 (fourth attempt) Some cmake-files are missing in development/Makefile.am. Kornel Index: development/Makefile.am === --- development/Makefile.am

Re: r34873 - in lyx-devel/tags/lyx-1_6_7: . development development/scons src/support

Kornel Benko wrote: > Some cmake-files are missing in development/Makefile.am. *Sigh* Put it in, please. Jürgen

Re: r34877 - lyx-devel/branches/BRANCH_1_6_X/development

kornel wrote: > Author: kornel > Date: Mon Jul 12 15:04:13 2010 > New Revision: 34877 > URL: http://www.lyx.org/trac/changeset/34877 > > Log: > Add missing cmake-files New tarball is to be found at the usual location. Jürgen

Re: r34829 - in lyx-devel/branches/BRANCH_1_6_X: . lib/doc/fr

On 07/12/2010 06:20 AM, Jean-Marc LASGOUTTES wrote: Enrico Forestieri writes: Translators should be advised not to translate neither LYX_USERDIR_VER nor LYX_DIR_VER, as they will be replaced by the correct values at install time. Translating them, prevents this mechanism

Re: Lyxserver - citation-insert

Petr Šimon wrote: > Hello, > I have a question about citation-insert, which I use from a Firefox > extension Lyz, a plugin for Zotero. > When I set the citation format to (Author, year) (using natbib and > plainnat) and send citation-insert to lyxserver the citation is inserted as > Author

Re: r34860 - in lyx-devel/branches/BRANCH_1_6_X/development/cmake: . doc lyx2lyx man po src

Kornel Benko wrote: > Am Sonntag 11 Juli 2010 schrieb kuem...@lyx.org: >> +message(STATUS "Switch LYX_* variables by -DLYX_*=1 or 0:") > > Should the message not be rather > +message(STATUS "Switch LYX_* variables by -DLYX_*=ON or OFF:") > ? > Looks more consistent. Yes, but when using the

Re: LyX 1.6.7

Verburg wrote: > On 7/11/2010 5:44 PM, Uwe Stöhr wrote: >> Fine. I use MSVC 2008 and am therefore not affected by the MSVC problems. > > I've created up-to-date binaries of all the dependencies for MSVC 2010: > ftp://ftp.devel.lyx.org/pub/contrib/windows/bin/ >

Re: r34829 - in lyx-devel/branches/BRANCH_1_6_X: . lib/doc/fr

Richard Heck writes: >> We could maybe extend InsetInfo to cover this in 2.0. Or is it already >> the case? > What is it that we want? Tell the user what is the name of the environment variables that should be set to tell for ex. where is the user directory. This is an

Re: r34860 - in lyx-devel/branches/BRANCH_1_6_X/development/cmake: . doc lyx2lyx man po src

Am Montag 12 Juli 2010 schrieb Peter Kümmel: ... > Yes, but when using the command line typing 0 or 1 is simpler. Not nice, but ok ... > > And why do we need e.g. LYX_PYTHON_EXECUTABLE? This looks as if python > > (or perl) would belong to lyx. (For found libraries we don't have this > > too) >

Dependency Problem?

Changing LaTeXUi.ui causes recompilation of GuiBranch.o and GuiIndices.o. Is that right? rh

"Unavailable" Classes

As shown below, our use of the term "Unavailable" to mark classes missing prerequisites can be confusing to people, and I'm sympathetic. These classes can be used, and marking them as "unavailable" makes it seem as if they can't be. I am also not sure that we should list all the

Re: r34860 - in lyx-devel/branches/BRANCH_1_6_X/development/cmake: . doc lyx2lyx man po src

Original-Nachricht > Datum: Mon, 12 Jul 2010 17:43:28 +0200 > Von: Kornel Benko > An: lyx-devel@lists.lyx.org > Betreff: Re: r34860 - in lyx-devel/branches/BRANCH_1_6_X/development/cmake: . > doc lyx2lyx man po src > Am Montag 12 Juli 2010 schrieb Peter Kümmel:

Re: r34810 - lyx-devel/trunk/src

Am 12.07.2010 um 12:13 schrieb Jean-Marc LASGOUTTES: > Stephan Witt writes: >> With some googling I've learned we're not alone. Perhaps the theory >> mentioned above doesn't hold for c++ code. That would be bad. I'll >> then forced to build with 10.5 SDK or maybe 10.4 and cannot

Copy and Paste in Multi-File Documents

Hello, I just noticed a weired copy and paste behavior when working in a multi-file document when copying a Section (including figure floats etc.) from one file to another file of the document (actually both files are child documents of the same master document). When copying all the formating

Re: Dependency Problem?

Op 12-7-2010 20:05, Richard Heck schreef: Changing LaTeXUi.ui causes recompilation of GuiBranch.o and GuiIndices.o. Is that right? rh Fixed in trunk at r34882. Vincent

Re: Dependency Problem?

On 07/12/2010 05:43 PM, Vincent van Ravesteijn wrote: Op 12-7-2010 20:05, Richard Heck schreef: Changing LaTeXUi.ui causes recompilation of GuiBranch.o and GuiIndices.o. Is that right? rh Fixed in trunk at r34882. Thanks. rh

Re: Copy and Paste in Multi-File Documents

On 07/12/2010 05:33 PM, Rainer Dorsch wrote: Hello, I just noticed a weired copy and paste behavior when working in a multi-file document when copying a Section (including figure floats etc.) from one file to another file of the document (actually both files are child documents of the same

Bug #3221: nameref support

The attached patch implements nameref support in cross-references. The only thing I'm not sure about, which Uwe mentioned in the bug, is the precise loading order of packages. If we're loading hyperref anyway, then there's no issue, since it loads nameref. But if we aren't, then maybe

Re: Bug #3221: nameref support

On 07/12/2010 06:00 PM, Richard Heck wrote: The attached patch implements nameref support in cross-references. The only thing I'm not sure about, which Uwe mentioned in the bug, is the precise loading order of packages. If we're loading hyperref anyway, then there's no issue, since it loads

Re: r34877 - lyx-devel/branches/BRANCH_1_6_X/development

On 7/12/2010 9:17 AM, Jürgen Spitzmüller wrote: New tarball is to be found at the usual location. CMake still doesn't work. I'm getting a lot of errors. Trying SCons now. Joost

Re: r34810 - lyx-devel/trunk/src

On Mon, Jul 12, 2010 at 4:48 PM, Stephan Witt wrote: > Am 12.07.2010 um 12:13 schrieb Jean-Marc LASGOUTTES: > >> Stephan Witt writes: >>> With some googling I've learned we're not alone. Perhaps the theory >>> mentioned above doesn't hold for c++ code. That

Re: [patch] support for the DIN ISO C paper format series

> i miss FORMAT entry and version should incerease too. I don't increase the fileformat in these patches to be able to apply the patch and test it without having conflicts with other patches you might have in your tree. As no one is opposed to this patch and as it is straight forward, I have

Re: r34877 - lyx-devel/branches/BRANCH_1_6_X/development

On 7/12/2010 8:47 PM, Joost Verburg wrote: Trying SCons now. Also doesn't work. src\frontends\qt4\GuiCommandBuffer.cpp(319) : error C2668: 'lyx::copy_if' : ambiguous call to overloaded function Joost

Re: r34866 - lyx-devel/branches/BRANCH_1_6_X/development

> Uwe, is it really necessary to rename this file at every release? No. I'll rename it for the next version. > I have to fix the Makefile at every release at make dist step; this is quite annoying. I wasn't aware that you also take care about the Windows installer files. sorry and regards

Re: LyX 1.6.7

> With the latest updates in trunk it's now possible to run LyX by just clicking lyx.exe, > without the need for a launcher or any registry keys or environment variables. Very nice! Can you please tell me how to compile LyX to achieve this? I'm still stuck with your new compilation option and

Bug #3221: nameref support

> The only thing I'm not sure about, which Uwe mentioned in the bug, is the precise loading order > of packages. This doesn't seem to be an issue with the new nameref version because the former conflicts with memoir and varioref are resolved. I did some test and your implementation works fine

Re: LyX 1.6.7

On 7/12/2010 9:35 PM, Uwe Stöhr wrote: Very nice! Can you please tell me how to compile LyX to achieve this? I'm still stuck with your new compilation option and don't know where to specify it. Use CMake in Trunk and set LYX_NOCONSOLE. > I've created up-to-date binaries of all the

Re: Bug #3221: nameref support

There is another issue: The text "on page" is not yet translated to the document language. One manually has to add this preamble code: \renewcommand*\Nameref[1]{`\nameref{#1}' auf Seite~\pageref{#1}} "auf Seite" is hereby the German translation of "on page". As this is no solution for us I

Re: Bug #3221: nameref support

On 07/12/2010 10:04 PM, Uwe Stöhr wrote: > The only thing I'm not sure about, which Uwe mentioned in the bug, is the precise loading order of packages. This doesn't seem to be an issue with the new nameref version because the former conflicts with memoir and varioref are resolved. OK,

Re: Bug #3221: nameref support

On 07/12/2010 10:51 PM, Uwe Stöhr wrote: There is another issue: The text "on page" is not yet translated to the document language. One manually has to add this preamble code: \renewcommand*\Nameref[1]{`\nameref{#1}' auf Seite~\pageref{#1}} "auf Seite" is hereby the German translation of "on