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

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 And this is only with msvc10? How about using the previous version once more? Jürgen

Re: Unavailable Classes

Richard Heck wrote: One idea is to mark such classes with an asterisk, as in the attached patch and screenshot. Comments? Other ideas? I think we had an asterisk at first and then changed it to the current text, because people found the asterisk not informative enough. If you go for he

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

Joost Verburg wrote: 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 I've now problems here with this file. 'lyx::copy_if' in line 316 of

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

Peter Kümmel wrote: But there are other ones: the po file geneartion does not work, haven't we replaced the perl scripts? I'm looking at this, but I'm no python scriper. here the error: Traceback (most recent call last): File C:/work/sandbox/lyx/lyx-1.6.7/po/lyx_pot.py, line 352, in

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

Peter Kümmel wrote: Peter Kümmel wrote: But there are other ones: the po file geneartion does not work, haven't we replaced the perl scripts? I'm looking at this, but I'm no python scriper. here the error: Traceback (most recent call last): File

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

Peter Kümmel wrote: Peter Kümmel wrote: Peter Kümmel wrote: But there are other ones: the po file geneartion does not work, haven't we replaced the perl scripts? I'm looking at this, but I'm no python scriper. here the error: Traceback (most recent call last): File

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

Am Dienstag 13 Juli 2010 schrieb Peter Kümmel: Peter Kümmel wrote: Peter Kümmel wrote: Peter Kümmel wrote: But there are other ones: the po file geneartion does not work, haven't we replaced the perl scripts? I'm looking at this, but I'm no python scriper. here the error:

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

Kornel Benko wrote: Am Dienstag 13 Juli 2010 schrieb Peter Kümmel: Peter Kümmel wrote: Peter Kümmel wrote: Peter Kümmel wrote: But there are other ones: the po file geneartion does not work, haven't we replaced the perl scripts? I'm looking at this, but I'm no python scriper. here the

Re: LyX 1.6.7

Joost Verburg wrote: 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. Wouldn't it be better to disable

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

Peter Kümmel wrote: For this release I wouldn't touch it, it's not really a show stopper, and most people on windows download the binaries. But we could fix it for future releases, and I could remember we already fixed a python script so we can feed it with a file which lists all the files.

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

Jürgen Spitzmüller wrote: Kornel Benko wrote: Some cmake-files are missing in development/Makefile.am. *Sigh* Sorry Jürgen, but Joost is switching to cmake for this release and and we must iron out all shortcoming. And my fault was to build a checkout of branch, not your tarballs. But now

Re: r34885 - in lyx-devel/branches/BRANCH_1_6_X/development/cmake: . src src/client src/frontends/qt4

kuemmel wrote: Author: kuemmel Date: Tue Jul 13 11:04:17 2010 New Revision: 34885 URL: http://www.lyx.org/trac/changeset/34885 Log: cmake: also build the tarball with its additional files Peter, http://marc.info/?l=lyx-develm=127892390317798w=2 Jürgen

Re: r34885 - in lyx-devel/branches/BRANCH_1_6_X/development/cmake: . src src/client src/frontends/qt4

Jürgen Spitzmüller wrote: kuemmel wrote: Author: kuemmel Date: Tue Jul 13 11:04:17 2010 New Revision: 34885 URL: http://www.lyx.org/trac/changeset/34885 Log: cmake: also build the tarball with its additional files Peter, http://marc.info/?l=lyx-develm=127892390317798w=2 You wanna

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

Peter Kümmel wrote: but Joost is switching to cmake for this release and and we must iron out all shortcoming. Right. Nevertheless I prefer you post patches to the list first at this stage of the release. We are in a freeze, after all. And my fault was to build a checkout of branch, not your

Re: r34885 - in lyx-devel/branches/BRANCH_1_6_X/development/cmake: . src src/client src/frontends/qt4

Peter Kümmel wrote: You wanna discuss CMake related changes with me? I want to know what happens at this stage before commits are made. It is hard to plan a release if I don't know what's going on behind the curtains. I suppose no commits to branch whatsoever should be a sufficiently clear

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

Jürgen Spitzmüller wrote: I also saw a not deployed cygwin file: development/cygwin/lyxrc.dist This is not my doing. I guess we just release all *.cpp's. Anyway, nothing to touch now. I miss interpreted my diff, this file is released but not checked in, so no problem here. Peter

Re: r34885 - in lyx-devel/branches/BRANCH_1_6_X/development/cmake: . src src/client src/frontends/qt4

Jürgen Spitzmüller wrote: Peter Kümmel wrote: You wanna discuss CMake related changes with me? I want to know what happens at this stage before commits are made. It is hard to plan a release if I don't know what's going on behind the curtains. I suppose no commits to branch whatsoever

Re: r34885 - in lyx-devel/branches/BRANCH_1_6_X/development/cmake: . src src/client src/frontends/qt4

Peter Kümmel wrote: OK, we are in a freeze, but the changes were essential, and you would have agreed for sure. Yes, I would have. But this is not the point. Jürgen

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

Jürgen Spitzmüller wrote: But now it compiles and installs with your patched lyx tarballs (already checked in) on msvc10. But the final word has Joost. So you're done? Then I set up a hopefully final tarball later today (and let Joost test it once more). I switch to Linux now, and test

Re: LyX 1.6.7

Am 12.07.2010 um 13:27 schrieb Jürgen Spitzmüller: 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: LyX 1.6.7

Stephan Witt wrote: In case it is of interest... These files (as of 12.07.2010,13:17) are ok on mac too. Built successfully with autotools. Thanks. Jürgen

Re: Bug #3221: nameref support

Am 13.07.2010 05:13, schrieb Richard Heck: I did some test and your implementation works fine for me except of these: 1. insert a reference, select the style Textual reference and press APPLY (don't close the dialog) 2. change the style to e.g. Textual reference plus page Result: the apply

Re: Bug #3221: nameref support

Am 13.07.2010 05:23, schrieb Richard Heck: 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

Re: Bug #3221: nameref support

Am 13.07.2010 13:59, schrieb Uwe Stöhr: We can easily convert this to: \begin_inset ERT status collapsed \begin_layout Plain Layout \backslash vref{ \end_layout \end_inset sec:dsf \begin_inset ERT status collapsed \begin_layout Plain Layout } \end_layout \end_inset Sorry, I meant to convert

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

Peter Kümmel wrote: Jürgen Spitzmüller wrote: But now it compiles and installs with your patched lyx tarballs (already checked in) on msvc10. But the final word has Joost. So you're done? Then I set up a hopefully final tarball later today (and let Joost test it once more). I switch to

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

Peter Kümmel wrote: I switch to Linux now, and test there the patched tarball. I give you a Ok later, or ask for checkins ;) The files or ok on linux. OK, thanks for testing. Joost, I've uploaded new tarballs. Awaiting your feedback. Jürgen

Re: Unavailable Classes

Why not simply: 'missing latex classes' or 'missing dependencies'? Liviu On 7/13/10, Jürgen Spitzmüller sp...@lyx.org wrote: Richard Heck wrote: One idea is to mark such classes with an asterisk, as in the attached patch and screenshot. Comments? Other ideas? I think we had an asterisk at

Re: Unavailable Classes

Liviu Andronic wrote: Why not simply: 'missing latex classes' because there's also DocBook and it could also be missing style files. or 'missing dependencies'? this is a bit vague, IMHO. Jürgen

Re: Bug #3221: nameref support

On 07/13/2010 08:11 AM, Uwe Stöhr wrote: Am 13.07.2010 13:59, schrieb Uwe Stöhr: We can easily convert this to: \begin_inset ERT status collapsed \begin_layout Plain Layout \backslash vref{ \end_layout \end_inset sec:dsf \begin_inset ERT status collapsed \begin_layout Plain Layout }

Re: Bug #3221: nameref support

On 07/13/2010 08:06 AM, Uwe Stöhr wrote: Am 13.07.2010 05:23, schrieb Richard Heck: 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

Re: Unavailable Classes

On 07/13/2010 09:41 AM, Jürgen Spitzmüller wrote: Liviu Andronic wrote: Why not simply: 'missing latex classes' because there's also DocBook and it could also be missing style files. or 'missing dependencies'? this is a bit vague, IMHO. The other thing is that there

Re: Unavailable Classes

On 07/13/2010 02:08 AM, Jürgen Spitzmüller wrote: Richard Heck wrote: One idea is to mark such classes with an asterisk, as in the attached patch and screenshot. Comments? Other ideas? I think we had an asterisk at first and then changed it to the current text, because people found

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

On 7/13/2010 2:43 AM, Peter Kümmel wrote: somehow it eats the dot before '.inc' Not just the dot. It's eating other characters here somewhere else in the string. Joost

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

Jürgen Spitzmüller wrote: Peter Kümmel wrote: I switch to Linux now, and test there the patched tarball. I give you a Ok later, or ask for checkins ;) The files or ok on linux. OK, thanks for testing. Joost, I've uploaded new tarballs. Awaiting your feedback. Just to be sure I tested

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

On 7/13/2010 10:25 AM, Joost Verburg wrote: On 7/13/2010 2:43 AM, Peter Kümmel wrote: somehow it eats the dot before '.inc' Not just the dot. It's eating other characters here somewhere else in the string. For example here: Jost/LyX/lyx-1.6.7/lib/layouts/theorems-starred-equivalents.inc ^

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

Joost Verburg wrote: On 7/13/2010 2:43 AM, Peter Kümmel wrote: somehow it eats the dot before '.inc' Not just the dot. It's eating other characters here somewhere else in the string. I've moved the sources to c:\s\lyx-1.6.7 and the build to c:\b then the command line was short enough.

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

On 7/13/2010 2:31 AM, Peter Kümmel wrote: 'lyx::copy_if' in line 316 of GuiCommandBuffer.cpp is not part of the tarballs. Seems you've somehow used trunk code. I'm using the tarball, but somehow the line number if off here. I get a lot of other errors as well, such as:

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

Joost Verburg wrote: On 7/13/2010 2:31 AM, Peter Kümmel wrote: 'lyx::copy_if' in line 316 of GuiCommandBuffer.cpp is not part of the tarballs. Seems you've somehow used trunk code. I'm using the tarball, but somehow the line number if off here. I get a lot of other errors as well, such as:

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

On 7/13/2010 10:44 AM, Peter Kümmel wrote: Do you use the merged build? I've not tested it for several weeks. Yes, LYX_MERGE_FILES is enabled in CMake. I will disable it and try again. Joost

Re: Bug #3221: nameref support

Am 13.07.2010 15:47, schrieb Richard Heck: Again, this isn't the issue. What I do has the same effect, No, it has not, the suer gets a number instead of the name of the reference. is simpler, and doesn't use ERT: I just convert the command from \nameref to \ref or \Nameref to \vref. The

Re: Bug #3221: nameref support

Am 13.07.2010 15:50, schrieb Richard Heck: There's no lyx2lyx issue, There is, see my previous mail! OK, I'll change the lyx2lyx routine so that the result gives the same output for the user. and the translation issue can be addressed independently. You're welcome to add your code if you

Re: Bug #3221: nameref support

Uwe Stöhr wrote: is simpler, and doesn't use ERT: I just convert the command from \nameref to \ref or \Nameref to \vref. The point is that this does not produce the same output as \nameref does and there is no reasonable way to do this. But this is the reason why this is no option. lyx2lyx

How to remove a learned word from personal dictionary

Now, I've added the native spell checker interface for mac os x, I find it strange to support only adding words in LyX. It seems like the spell checker infrastructure doesn't support removing of words from personal dictionary. But this is possible with aspell at least, AFAICS. The cool feature

Re: Bug #3221: nameref support

Uwe Stöhr wrote: Sorry, but I have the feeling that you are a bit lazy with your patch. If we are not able to translate the reference text, the new feature turns into a bug as it then only works for English documents. I therefore wanted to solve this issue before applying. Could you

Branch regression?

hi, some of my script do not work anymore due to the fact that lyx silently fails to overwrite exported files. i vaguely remember introducing -f switch to enforce overwriting, which must be related. in particular commands like: lyx file.lyx -e dvi won't rewrite main file, which shouldn't be...

Re: Branch regression?

Pavel Sanda wrote: hi, some of my script do not work anymore due to the fact that lyx silently fails to overwrite exported files. i vaguely remember introducing -f switch to enforce overwriting, which must be related. in particular commands like: lyx file.lyx -e dvi won't rewrite main

Re: Bug #3221: nameref support

On 07/13/2010 12:13 PM, Pavel Sanda wrote: disclaimer first - i know nothing about the subtleties of varisous XXXref commands... anyway tend to agree here with Richard to consider this as nameref bug. if nameref devs do not plan to fix/advance their work its question whether our dependency on

Re: Branch regression?

On Tue, Jul 13, 2010 at 07:39:16PM +0200, Pavel Sanda wrote: Pavel Sanda wrote: hi, some of my script do not work anymore due to the fact that lyx silently fails to overwrite exported files. i vaguely remember introducing -f switch to enforce overwriting, which must be related.

Re: Branch regression?

Enrico Forestieri wrote: this is a showstoppper for anybody using lyx in scripts. Come on, simply add -f if you don't care overwriting existing files. The way it worked before r34533 was fundamentally wrong. well, changing the semantics of commandline switches is a nightmare. just imagine

Re: Bug #3221: nameref support

On 07/13/2010 11:30 AM, Uwe Stöhr wrote: Am 13.07.2010 15:47, schrieb Richard Heck: Again, this isn't the issue. What I do has the same effect, No, it has not, the suer gets a number instead of the name of the reference. Sorry, I missed the difference between your first proposal and your

Re: Branch regression?

On Tue, Jul 13, 2010 at 10:54:07PM +0200, Pavel Sanda wrote: Enrico Forestieri wrote: this is a showstoppper for anybody using lyx in scripts. Come on, simply add -f if you don't care overwriting existing files. The way it worked before r34533 was fundamentally wrong. well, changing

Re: LyX 1.6.7

On 7/13/2010 4:22 AM, Peter Kümmel wrote: Wouldn't it be better to disable LYX_INSTALL by default and to enable all deploy releant options if LYX_INSTALL is set: aspell, nls, no console, more? I'm always annoyed about all the translations and lyx file processing projects which I really do not

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

On 7/13/2010 10:44 AM, Peter Kümmel wrote: Do you use the merged build? I've not tested it for several weeks. OK so I got it to compile by: * Disabling merged build * Moving my files to C:\ to shorten the path I think this should definitely be fixed for 1.6.8 but maybe we can go ahead now

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

On 7/13/2010 6:12 PM, Joost Verburg wrote: I think this should definitely be fixed for 1.6.8 but maybe we can go ahead now with 1.6.7. Just discovered another issue. The user directory suffix for the 1.6 series has always been 16 (directory called lyx16), while CMake sets it to 1.6

Re: Branch regression?

On Tue, Jul 13, 2010 at 07:01:04PM +0200, Pavel Sanda wrote: hi, some of my script do not work anymore due to the fact that lyx silently fails to overwrite exported files. This is rather a trunk regression, as in branch you get notified when the file is not overwritten. -- Enrico

Re: Branch regression?

Enrico Forestieri wrote: Funny that you mention that: host1 tail --version tail (GNU coreutils) 5.97 ... host1 tail +20 foo [commands succeeds, showing last lines of foo starting from line 20] host2 tail --version tail (GNU coreutils) 8.5 ... host2 tail +20 foo tail: cannot open

Re: Branch regression?

Enrico Forestieri wrote: some of my script do not work anymore due to the fact that lyx silently fails to overwrite exported files. This is rather a trunk regression, as in branch you get notified when the file is not overwritten. which is not of much help in batch mode pavel

Re: Branch regression?

On Wed, Jul 14, 2010 at 01:10:18AM +0200, Pavel Sanda wrote: core of my complaint was that changing semantics of traditional switch is pita and will be hardly changed by disputing nitpicks of selected examples inside coreutils. Core of my answer was that switches of commands can be changed

Re: Branch regression?

On Wed, Jul 14, 2010 at 01:15:52AM +0200, Pavel Sanda wrote: Enrico Forestieri wrote: some of my script do not work anymore due to the fact that lyx silently fails to overwrite exported files. This is rather a trunk regression, as in branch you get notified when the file is not

Re: Branch regression?

Enrico Forestieri wrote: could you elaborate why strong disagreement? another utils i'm currently using around lyx work also like that - pdflatex rewrites ouput, dvips too. you are strongly disagree with their doing also? its really no fun to scan all the scripts in various projects

Re: Branch regression?

Pavel Sanda wrote: i still maintain that the backward compatibility will cause less user's frustration for this particular switch (ie default RC setting would need to be set on main file overwrite) than new gun-discharged-course but i let the responsibility on Juergen or anybody else who want

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

Joost Verburg wrote: Just discovered another issue. The user directory suffix for the 1.6 series has always been 16 (directory called lyx16), while CMake sets it to 1.6 (directory called LyX1.6). There should be an option to change this otherwise user preferences will not be preserved.

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

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 And this is only with msvc10? How about using the previous version once more? Jürgen

Re: "Unavailable" Classes

Richard Heck wrote: > One idea is to mark such classes with an asterisk, as in the attached > patch and screenshot. Comments? Other ideas? I think we had an asterisk at first and then changed it to the current text, because people found the asterisk not informative enough. If you go for he

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

Joost Verburg wrote: > 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 > I've now problems here with this file. 'lyx::copy_if' in

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

Peter Kümmel wrote: > But there are other ones: the po file geneartion does not > work, haven't we replaced the perl scripts? > > I'm looking at this, but I'm no python scriper. here the error: Traceback (most recent call last): File "C:/work/sandbox/lyx/lyx-1.6.7/po/lyx_pot.py", line 352,

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

Peter Kümmel wrote: > Peter Kümmel wrote: >> But there are other ones: the po file geneartion does not >> work, haven't we replaced the perl scripts? >> >> I'm looking at this, but I'm no python scriper. > > here the error: > Traceback (most recent call last): > File

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

Peter Kümmel wrote: > Peter Kümmel wrote: >> Peter Kümmel wrote: >>> But there are other ones: the po file geneartion does not >>> work, haven't we replaced the perl scripts? >>> >>> I'm looking at this, but I'm no python scriper. >> here the error: >> Traceback (most recent call last): >>

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

Am Dienstag 13 Juli 2010 schrieb Peter Kümmel: > Peter Kümmel wrote: > > Peter Kümmel wrote: > >> Peter Kümmel wrote: > >>> But there are other ones: the po file geneartion does not > >>> work, haven't we replaced the perl scripts? > >>> > >>> I'm looking at this, but I'm no python scriper. > >>

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

Kornel Benko wrote: > Am Dienstag 13 Juli 2010 schrieb Peter Kümmel: >> Peter Kümmel wrote: >>> Peter Kümmel wrote: Peter Kümmel wrote: > But there are other ones: the po file geneartion does not > work, haven't we replaced the perl scripts? > > I'm looking at this, but I'm no

Re: LyX 1.6.7

Joost Verburg wrote: > 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. Wouldn't it be better

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

Peter Kümmel wrote: > For this release I wouldn't touch it, it's not really a show stopper, and > most people on windows download the binaries. > But we could fix it for future releases, and I could remember we already > fixed a python script so we can feed it with a file which lists all the >

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

Jürgen Spitzmüller wrote: > Kornel Benko wrote: >> Some cmake-files are missing in development/Makefile.am. > > *Sigh* Sorry Jürgen, but Joost is switching to cmake for this release and and we must iron out all shortcoming. And my fault was to build a checkout of branch, not your tarballs.

Re: r34885 - in lyx-devel/branches/BRANCH_1_6_X/development/cmake: . src src/client src/frontends/qt4

kuemmel wrote: > Author: kuemmel > Date: Tue Jul 13 11:04:17 2010 > New Revision: 34885 > URL: http://www.lyx.org/trac/changeset/34885 > > Log: > cmake: also build the tarball with its additional files Peter, http://marc.info/?l=lyx-devel=127892390317798=2 Jürgen

Re: r34885 - in lyx-devel/branches/BRANCH_1_6_X/development/cmake: . src src/client src/frontends/qt4

Jürgen Spitzmüller wrote: > kuemmel wrote: >> Author: kuemmel >> Date: Tue Jul 13 11:04:17 2010 >> New Revision: 34885 >> URL: http://www.lyx.org/trac/changeset/34885 >> >> Log: >> cmake: also build the tarball with its additional files > > Peter, > http://marc.info/?l=lyx-devel=127892390317798=2

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

Peter Kümmel wrote: > but Joost is switching to cmake for this release and and > we must iron out all shortcoming. Right. Nevertheless I prefer you post patches to the list first at this stage of the release. We are in a freeze, after all. > And my fault was to build a checkout of branch, not

Re: r34885 - in lyx-devel/branches/BRANCH_1_6_X/development/cmake: . src src/client src/frontends/qt4

Peter Kümmel wrote: > You wanna discuss CMake related changes with me? I want to know what happens at this stage before commits are made. It is hard to plan a release if I don't know what's going on behind the curtains. I suppose "no commits to branch whatsoever" should be a sufficiently clear

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

Jürgen Spitzmüller wrote: >> I also saw a not deployed cygwin file: >> development/cygwin/lyxrc.dist > > This is not my doing. I guess we just release all *.cpp's. Anyway, nothing to > touch now. I miss interpreted my diff, this file is released but not checked in, so no problem here. Peter

Re: r34885 - in lyx-devel/branches/BRANCH_1_6_X/development/cmake: . src src/client src/frontends/qt4

Jürgen Spitzmüller wrote: > Peter Kümmel wrote: >> You wanna discuss CMake related changes with me? > > I want to know what happens at this stage before commits are made. It is hard > to plan a release if I don't know what's going on behind the curtains. > > I suppose "no commits to branch

Re: r34885 - in lyx-devel/branches/BRANCH_1_6_X/development/cmake: . src src/client src/frontends/qt4

Peter Kümmel wrote: > OK, we are in a freeze, but the changes were essential, and you would have > agreed for sure. Yes, I would have. But this is not the point. Jürgen

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

Jürgen Spitzmüller wrote: >> But now it compiles and installs with your patched lyx tarballs >> (already checked in) on msvc10. But the final word has Joost. > > So you're done? Then I set up a hopefully final tarball later today (and let > Joost test it once more). I switch to Linux now, and

Re: LyX 1.6.7

Am 12.07.2010 um 13:27 schrieb Jürgen Spitzmüller: > 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: LyX 1.6.7

Stephan Witt wrote: > In case it is of interest... > > These files (as of 12.07.2010,13:17) are ok on mac too. > Built successfully with autotools. Thanks. Jürgen

Re: Bug #3221: nameref support

Am 13.07.2010 05:13, schrieb Richard Heck: I did some test and your implementation works fine for me except of these: 1. insert a reference, select the style "Textual reference" and press APPLY (don't close the dialog) 2. change the style to e.g. "Textual reference plus " Result: the apply

Re: Bug #3221: nameref support

Am 13.07.2010 05:23, schrieb Richard Heck: 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

Re: Bug #3221: nameref support

Am 13.07.2010 13:59, schrieb Uwe Stöhr: We can easily convert this to: \begin_inset ERT status collapsed \begin_layout Plain Layout \backslash vref{ \end_layout \end_inset sec:dsf \begin_inset ERT status collapsed \begin_layout Plain Layout } \end_layout \end_inset Sorry, I meant to convert

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

Peter Kümmel wrote: > Jürgen Spitzmüller wrote: > >>> But now it compiles and installs with your patched lyx tarballs >>> (already checked in) on msvc10. But the final word has Joost. >> So you're done? Then I set up a hopefully final tarball later today (and let >> Joost test it once more). >

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

Peter Kümmel wrote: > > I switch to Linux now, and test there the patched tarball. I give you a > > Ok later, or ask for checkins ;) > > > > > > The files or ok on linux. OK, thanks for testing. Joost, I've uploaded new tarballs. Awaiting your feedback. Jürgen

Re: "Unavailable" Classes

Why not simply: 'missing latex classes' or 'missing dependencies'? Liviu On 7/13/10, Jürgen Spitzmüller wrote: > Richard Heck wrote: >> One idea is to mark such classes with an asterisk, as in the attached >> patch and screenshot. Comments? Other ideas? > > I think we had an

Re: "Unavailable" Classes

Liviu Andronic wrote: > Why not simply: 'missing latex classes' because there's also DocBook and it could also be missing style files. > or 'missing dependencies'? this is a bit vague, IMHO. Jürgen

Re: Bug #3221: nameref support

On 07/13/2010 08:11 AM, Uwe Stöhr wrote: Am 13.07.2010 13:59, schrieb Uwe Stöhr: We can easily convert this to: \begin_inset ERT status collapsed \begin_layout Plain Layout \backslash vref{ \end_layout \end_inset sec:dsf \begin_inset ERT status collapsed \begin_layout Plain Layout }

Re: Bug #3221: nameref support

On 07/13/2010 08:06 AM, Uwe Stöhr wrote: Am 13.07.2010 05:23, schrieb Richard Heck: 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

Re: "Unavailable" Classes

On 07/13/2010 09:41 AM, Jürgen Spitzmüller wrote: Liviu Andronic wrote: Why not simply: 'missing latex classes' because there's also DocBook and it could also be missing style files. or 'missing dependencies'? this is a bit vague, IMHO. The other thing is that there

Re: "Unavailable" Classes

On 07/13/2010 02:08 AM, Jürgen Spitzmüller wrote: Richard Heck wrote: One idea is to mark such classes with an asterisk, as in the attached patch and screenshot. Comments? Other ideas? I think we had an asterisk at first and then changed it to the current text, because people found

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

On 7/13/2010 2:43 AM, Peter Kümmel wrote: somehow it eats the dot before '.inc' Not just the dot. It's eating other characters here somewhere else in the string. Joost

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

Jürgen Spitzmüller wrote: > Peter Kümmel wrote: >>> I switch to Linux now, and test there the patched tarball. I give you a >>> Ok later, or ask for checkins ;) >>> >>> >> The files or ok on linux. > > OK, thanks for testing. > > Joost, I've uploaded new tarballs. Awaiting your feedback. Just

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

On 7/13/2010 10:25 AM, Joost Verburg wrote: On 7/13/2010 2:43 AM, Peter Kümmel wrote: somehow it eats the dot before '.inc' Not just the dot. It's eating other characters here somewhere else in the string. For example here: Jost/LyX/lyx-1.6.7/lib/layouts/theorems-starred-equivalents.inc ^

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

Joost Verburg wrote: > On 7/13/2010 2:43 AM, Peter Kümmel wrote: >> somehow it eats the dot before '.inc' > > Not just the dot. It's eating other characters here somewhere else in > the string. > I've moved the sources to c:\s\lyx-1.6.7 and the build to c:\b then the command line was short

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

On 7/13/2010 2:31 AM, Peter Kümmel wrote: 'lyx::copy_if' in line 316 of GuiCommandBuffer.cpp is not part of the tarballs. Seems you've somehow used trunk code. I'm using the tarball, but somehow the line number if off here. I get a lot of other errors as well, such as:

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

Joost Verburg wrote: > On 7/13/2010 2:31 AM, Peter Kümmel wrote: >> 'lyx::copy_if' in line 316 of GuiCommandBuffer.cpp is not >> part of the tarballs. Seems you've somehow used trunk code. > > I'm using the tarball, but somehow the line number if off here. > I get a lot of other errors as well,

  1   2   >