Re: r37353 - lyx-devel/trunk/lib/lyx2lyx

2011-02-10 Thread Jean-Marc Lasgouttes 

Le 28/01/11 20:48, rgh...@lyx.org a écrit :

Author: rgheck
Date: Fri Jan 28 20:48:03 2011
New Revision: 37353
URL: http://www.lyx.org/trac/changeset/37353

Log:
Fix lyx2lyx problem with sweave files and ParBreakIsNewline.


Richard,

I was about to revert the workaround in sweave.lyx example file and I 
find that it does not work after all. Did you try the file


http://www.lyx.org/trac/export/37219/lyx-devel/trunk/lib/examples/sweave.lyx
?

I find that the R chunks do not get centered at all...

JMarc

Re: r37580 - lyx-devel/trunk/development/cmake

2011-02-10 Thread Pavel Sanda 
kor...@lyx.org wrote:
 Author: kornel
 Date: Thu Feb 10 07:16:12 2011
 New Revision: 37580
 URL: http://www.lyx.org/trac/changeset/37580
 
 Log:
 Define LYX_(MAJOR|MINOR)_VERSION also for cmake build
 
 Modified:
lyx-devel/trunk/development/cmake/config.h.cmake
 
 Modified: lyx-devel/trunk/development/cmake/config.h.cmake
 ==
 --- lyx-devel/trunk/development/cmake/config.h.cmake  Wed Feb  9 23:19:14 
 2011(r37579)
 +++ lyx-devel/trunk/development/cmake/config.h.cmake  Thu Feb 10 07:16:12 
 2011(r37580)
 @@ -32,6 +32,8 @@
  #cmakedefine VERSION_INFO ${VERSION_INFO}
  #cmakedefine LYX_DIR_VER ${LYX_DIR_VER}
  #cmakedefine LYX_USERDIR_VER ${LYX_USERDIR_VER}
 +#define LYX_MAJOR_VERSION ${LYX_MAJOR_VERSION}
 +#define LYX_MINOR_VERSION ${LYX_MINOR_VERSION}

huh, this didn't come to my mind. now i think scons will suffer from the same 
problem.
please is there anybody around using scons to test?

pavel

hebrew support in lyx 2.0?

2011-02-10 Thread Richman Reuven 
hi, i can't seem to find any info on possible changes of hebrew support
in the new version (2.0), was there something supposed to happen? (i'd
gladly test it if i knew what to look for)

thanks,
reuven r.

Re: hebrew support in lyx 2.0?

2011-02-10 Thread Pavel Sanda 
Richman Reuven wrote:
 hi, i can't seem to find any info on possible changes of hebrew support
 in the new version (2.0), was there something supposed to happen? (i'd
 gladly test it if i knew what to look for)

the thing which could be good to test is that all hebrew stuff you used in 1.6
still works in 2.0. no new particular hebrew features were done, but some
additions like xetex support might have some impact.

pavel

Re: Cjk Lyx 1.4

2011-02-10 Thread Jürgen Spitzmüller 
Jürgen Spitzmüller wrote:
  Send exported file to command
 
 A bit verbose for a label, but OK, we have enough space here.

I've committed this now.

Jesper, does your plan to implement export menu disabling still stand? 

Jürgen

Re: [patch] Controlling newlines on export

2011-02-10 Thread Enrico Forestieri 
On Thu, Feb 10, 2011 at 01:58:07AM +0100, Enrico Forestieri wrote:
 
 I have a working patch (see attached). It integrates texrow with
 otexstream and the line counting is thus automatic. I tested it
 quite thoroughly, and it seems to be better than what we have now,
 in the sense that it seems to be more accurate both for forward/reverse
 search and error positioning. For example, I added in ERT \foo to the
 right of the figure in Sec. 4.6.1.4 of the user guide and tried to
 preview the document. Without the attached patch, the section title
 (Wrap Floats) was highlighted, whereas with the patch the ERT was opened
 and exactly \foo was highlighted. Cool!

Given that the patch is quite strightforward, is more accurate in
the line counting task, does not introduce regressions, and can be
seen as the completion of previous work, I am going to commit it.

-- 
Enrico

Re: [patch] Controlling newlines on export

2011-02-10 Thread Pavel Sanda 
Enrico Forestieri wrote:
 Given that the patch is quite strightforward, is more accurate in
 the line counting task, does not introduce regressions, and can be
 seen as the completion of previous work, I am going to commit it.

Enrico, could you have possibly look on bug #7186 when you are after
forw/rev search now? thats much worse issue and i have really no time
on it

pavel

Re: [patch] Controlling newlines on export

2011-02-10 Thread Enrico Forestieri 
On Thu, Feb 10, 2011 at 10:02:18PM +0100, Pavel Sanda wrote:
 
 Enrico, could you have possibly look on bug #7186 when you are after
 forw/rev search now? thats much worse issue and i have really no time
 on it

It's not any better here, but I'll try to have a look.

-- 
Enrico

Re: hebrew support in lyx 2.0?

2011-02-10 Thread Vincent van Ravesteijn 
On Thu, Feb 10, 2011 at 1:49 PM, Richman Reuven
richman.reu...@gmail.com wrote:
 hi, i can't seem to find any info on possible changes of hebrew support
 in the new version (2.0), was there something supposed to happen? (i'd
 gladly test it if i knew what to look for)



If you like to bughunt: http://www.lyx.org/trac/ticket/7097.

Vincent

Re: r37353 - lyx-devel/trunk/lib/lyx2lyx

2011-02-10 Thread Richard Heck 

On 02/10/2011 06:03 AM, Jean-Marc Lasgouttes wrote:

Le 28/01/11 20:48, rgh...@lyx.org a écrit :

Author: rgheck
Date: Fri Jan 28 20:48:03 2011
New Revision: 37353
URL: http://www.lyx.org/trac/changeset/37353

Log:
Fix lyx2lyx problem with sweave files and ParBreakIsNewline.


Richard,

I was about to revert the workaround in sweave.lyx example file and I 
find that it does not work after all. Did you try the file


http://www.lyx.org/trac/export/37219/lyx-devel/trunk/lib/examples/sweave.lyx 


?

I find that the R chunks do not get centered at all...

This is weird. Try this. Open the file in LyX. Now center things 
manually and save. Close and reopen. Not centered!! So it's not a 
lyx2lyx problem (you can look in the converted file and see all the 
centering stuff) but something that's happening somewhere else. Is it 
because this is within a figure?


Richard

Re: r37364 - lyx-devel/trunk/development/autotests

2011-02-10 Thread Tommaso Cucinotta 

Il 09/02/2011 09:52, Enrico Forestieri ha scritto:

On Tue, Feb 08, 2011 at 10:53:34PM +0100, Pavel Sanda wrote:

having cs_CZ locales setup on system level sometimes locales does not work
either when make install is not done or something like that... i'm not able to
give exact recipy and frankly even wont to touch it :)

If you run lyx in place (without installing it) and want cs translations,
do the following:

$ cdlyx-top-srcdir
$ mkdir -p locale/cs/LC_MESSAGES
$ ln -s ../../../po/cs.gmo locale/cs/LC_MESSAGES/lyxsuffix.mo

Thanks. I added a variant of this trick in r37589, that makes the
autotests work also when there is no LyX installed at all on the system.
I didn't apply thesuffix  part, as I never configured with
--with-version-suffix. Where is such suffix is stored, in a Makefile var ?


T.

Re: r37591 - in lyx-devel/trunk/src: . mathed

2011-02-10 Thread Pavel Sanda 
kuem...@lyx.org wrote:
 Author: kuemmel
 Date: Thu Feb 10 23:57:41 2011
 New Revision: 37591
 URL: http://www.lyx.org/trac/changeset/37591
 
 Log:
 compile.
 
 Modified: lyx-devel/trunk/src/version.cpp
 ==
 --- lyx-devel/trunk/src/version.cpp   Thu Feb 10 23:44:59 2011(r37590)
 +++ lyx-devel/trunk/src/version.cpp   Thu Feb 10 23:57:41 2011(r37591)
 @@ -14,8 +14,8 @@
  ///
  char const * lyx_version = PACKAGE_VERSION;
  ///
 -int lyx_version_major = LYX_MAJOR_VERSION;
 -int lyx_version_minor = LYX_MINOR_VERSION;
 +const int lyx_version_major = LYX_MAJOR_VERSION;
 +const int lyx_version_minor = LYX_MINOR_VERSION;

it was no oversight i didn't put const there, since my linker chokes on it.
what was your error?
liblyxcore.a(Buffer.o): In function 
`lyx::Buffer::write(std::basic_ostreamchar, std::char_traitschar ) const':
Buffer.cpp:(.text+0x16ee): undefined reference to `lyx_version_major'
Buffer.cpp:(.text+0x171c): undefined reference to `lyx_version_minor'
collect2: ld returned 1 exit status

maybe we need to kill const.

pavel

Re: r37364 - lyx-devel/trunk/development/autotests

2011-02-10 Thread Enrico Forestieri 
On Thu, Feb 10, 2011 at 11:44:13PM +0100, Tommaso Cucinotta wrote:
 Il 09/02/2011 09:52, Enrico Forestieri ha scritto:
 On Tue, Feb 08, 2011 at 10:53:34PM +0100, Pavel Sanda wrote:
 having cs_CZ locales setup on system level sometimes locales does not work
 either when make install is not done or something like that... i'm not able 
 to
 give exact recipy and frankly even wont to touch it :)
 If you run lyx in place (without installing it) and want cs translations,
 do the following:
 
 $ cdlyx-top-srcdir
 $ mkdir -p locale/cs/LC_MESSAGES
 $ ln -s ../../../po/cs.gmo locale/cs/LC_MESSAGES/lyxsuffix.mo
 Thanks. I added a variant of this trick in r37589, that makes the
 autotests work also when there is no LyX installed at all on the system.
 I didn't apply thesuffix  part, as I never configured with
 --with-version-suffix. Where is such suffix is stored, in a Makefile var ?

You can find it in config.h:

/* Program version suffix */
#define PROGRAM_SUFFIX -2.0


but you can also directly use PACKAGE.mo, again getting PACKAGE from
config.h:

/* Name of package */
#define PACKAGE lyx-2.0


as it already contains the suffix, if specified.

-- 
Enrico

Re: r37353 - lyx-devel/trunk/lib/lyx2lyx

2011-02-10 Thread Richard Heck 

On 02/10/2011 05:32 PM, Richard Heck wrote:

On 02/10/2011 06:03 AM, Jean-Marc Lasgouttes wrote:

Le 28/01/11 20:48, rgh...@lyx.org a écrit :

Author: rgheck
Date: Fri Jan 28 20:48:03 2011
New Revision: 37353
URL: http://www.lyx.org/trac/changeset/37353

Log:
Fix lyx2lyx problem with sweave files and ParBreakIsNewline.


Richard,

I was about to revert the workaround in sweave.lyx example file and I 
find that it does not work after all. Did you try the file


http://www.lyx.org/trac/export/37219/lyx-devel/trunk/lib/examples/sweave.lyx 


?

I find that the R chunks do not get centered at all...

This is weird. Try this. Open the file in LyX. Now center things 
manually and save. Close and reopen. Not centered!! So it's not a 
lyx2lyx problem (you can look in the converted file and see all the 
centering stuff) but something that's happening somewhere else. Is it 
because this is within a figure?



The params are being read correctly. The problem is here:

void InsetText::fixParagraphsFont()
{
  Font font(inherit_font, buffer().params().language);
  font.setLanguage(latex_language);
  ParagraphList::iterator par = paragraphs().begin();
  ParagraphList::iterator const end = paragraphs().end();
  while (par != end) {
if (par-isPassThru()) {
  par-resetFonts(font);
  par-params().clear();
}
++par;
  }
}

This gets called at the end of InsetText::read(), and because we are 
PassThru, all the params get reset to their defaults. Hence, no centering.


Richard

Re: r37591 - in lyx-devel/trunk/src: . mathed

2011-02-10 Thread Enrico Forestieri 
On Fri, Feb 11, 2011 at 12:06:00AM +0100, Pavel Sanda wrote:
 kuem...@lyx.org wrote:
  Author: kuemmel
  Date: Thu Feb 10 23:57:41 2011
  New Revision: 37591
  URL: http://www.lyx.org/trac/changeset/37591
  
  Log:
  compile.
  
  Modified: lyx-devel/trunk/src/version.cpp
  ==
  --- lyx-devel/trunk/src/version.cpp Thu Feb 10 23:44:59 2011(r37590)
  +++ lyx-devel/trunk/src/version.cpp Thu Feb 10 23:57:41 2011(r37591)
  @@ -14,8 +14,8 @@
   ///
   char const * lyx_version = PACKAGE_VERSION;
   ///
  -int lyx_version_major = LYX_MAJOR_VERSION;
  -int lyx_version_minor = LYX_MINOR_VERSION;
  +const int lyx_version_major = LYX_MAJOR_VERSION;
  +const int lyx_version_minor = LYX_MINOR_VERSION;
 
 it was no oversight i didn't put const there, since my linker chokes on it.
 what was your error?
 liblyxcore.a(Buffer.o): In function 
 `lyx::Buffer::write(std::basic_ostreamchar, std::char_traitschar ) 
 const':
 Buffer.cpp:(.text+0x16ee): undefined reference to `lyx_version_major'
 Buffer.cpp:(.text+0x171c): undefined reference to `lyx_version_minor'
 collect2: ld returned 1 exit status
 
 maybe we need to kill const.

No, const variables have internal linkage, so they will not be seen outside
their compile unit. Simply declare them as extern also in version.cpp.

-- 
Enrico

Re: r37591 - in lyx-devel/trunk/src: . mathed

2011-02-10 Thread Peter Kümmel 

On 11.02.2011 00:34, Enrico Forestieri wrote:

On Fri, Feb 11, 2011 at 12:06:00AM +0100, Pavel Sanda wrote:

kuem...@lyx.org wrote:

Author: kuemmel
Date: Thu Feb 10 23:57:41 2011
New Revision: 37591
URL: http://www.lyx.org/trac/changeset/37591

Log:
compile.

Modified: lyx-devel/trunk/src/version.cpp
==
--- lyx-devel/trunk/src/version.cpp Thu Feb 10 23:44:59 2011(r37590)
+++ lyx-devel/trunk/src/version.cpp Thu Feb 10 23:57:41 2011(r37591)
@@ -14,8 +14,8 @@
  ///
  char const * lyx_version = PACKAGE_VERSION;
  ///
-int lyx_version_major = LYX_MAJOR_VERSION;
-int lyx_version_minor = LYX_MINOR_VERSION;
+const int lyx_version_major = LYX_MAJOR_VERSION;
+const int lyx_version_minor = LYX_MINOR_VERSION;


it was no oversight i didn't put const there, since my linker chokes on it.
what was your error?
liblyxcore.a(Buffer.o): In function `lyx::Buffer::write(std::basic_ostreamchar, 
std::char_traitschar  ) const':
Buffer.cpp:(.text+0x16ee): undefined reference to `lyx_version_major'
Buffer.cpp:(.text+0x171c): undefined reference to `lyx_version_minor'
collect2: ld returned 1 exit status

maybe we need to kill const.


No, const variables have internal linkage, so they will not be seen outside
their compile unit. Simply declare them as extern also in version.cpp.



You mean declaring it in the header as extern const int i is the same as
.h:   const int i;
.cpp  static int i;

Seems I will never stop learning new C/C++ features ;)

Peter

client

2011-02-10 Thread Peter Kümmel 

Am I the only one where client does not build?

I have to move TexRow.cpp/.h to support to fix it.

Should I commit?

Peter
Index: development/scons/scons_manifest.py
===
--- development/scons/scons_manifest.py	(revision 37592)
+++ development/scons/scons_manifest.py	(working copy)
@@ -126,7 +126,6 @@
 sgml.h
 Spacing.h
 SpellChecker.h
-TexRow.h
 Text.h
 TextClass.h
 TextMetrics.h
@@ -222,7 +221,6 @@
 Session.cpp
 sgml.cpp
 Spacing.cpp
-TexRow.cpp
 Text.cpp
 Text2.cpp
 Text3.cpp
@@ -324,6 +322,7 @@
 Systemcall.h
 SystemcallPrivate.h
 textutils.h
+TexRow.h
 Timeout.h
 Translator.h
 types.h
@@ -357,6 +356,7 @@
 qstring_helpers.cpp
 socktools.cpp
 Systemcall.cpp
+TexRow.cpp
 Timeout.cpp
 unicode.cpp
 userinfo.cpp
Index: src/Buffer.cpp
===
--- src/Buffer.cpp	(revision 37592)
+++ src/Buffer.cpp	(working copy)
@@ -55,7 +55,6 @@
 #include PDFOptions.h
 #include SpellChecker.h
 #include sgml.h
-#include TexRow.h
 #include TexStream.h
 #include Text.h
 #include TextClass.h
@@ -102,6 +101,7 @@
 #include support/Systemcall.h
 #include support/textutils.h
 #include support/types.h
+#include support/TexRow.h
 
 #include support/bind.h
 #include support/shared_ptr.h
Index: src/buffer_funcs.cpp
===
--- src/buffer_funcs.cpp	(revision 37592)
+++ src/buffer_funcs.cpp	(working copy)
@@ -31,7 +31,6 @@
 #include ParagraphList.h
 #include ParagraphParameters.h
 #include ParIterator.h
-#include TexRow.h
 #include Text.h
 #include TocBackend.h
 
@@ -47,6 +46,7 @@
 #include support/gettext.h
 #include support/lstrings.h
 #include support/textutils.h
+#include support/TexRow.h
 
 using namespace std;
 using namespace lyx::support;
Index: src/BufferParams.cpp
===
--- src/BufferParams.cpp	(revision 37592)
+++ src/BufferParams.cpp	(working copy)
@@ -35,7 +35,6 @@
 #include LyXRC.h
 #include OutputParams.h
 #include Spacing.h
-#include TexRow.h
 #include VSpace.h
 #include PDFOptions.h
 
@@ -52,6 +51,7 @@
 #include support/Messages.h
 #include support/Translator.h
 #include support/lstrings.h
+#include support/TexRow.h
 
 #include algorithm
 #include sstream
Index: src/BufferView.cpp
===
--- src/BufferView.cpp	(revision 37592)
+++ src/BufferView.cpp	(working copy)
@@ -49,7 +49,6 @@
 #include Text.h
 #include TextClass.h
 #include TextMetrics.h
-#include TexRow.h
 #include TocBackend.h
 #include VSpace.h
 #include WordLangTuple.h
@@ -79,6 +78,7 @@
 #include support/lstrings.h
 #include support/Package.h
 #include support/types.h
+#include support/TexRow.h
 
 #include cerrno
 #include fstream
Index: src/frontends/qt4/GuiView.cpp
===
--- src/frontends/qt4/GuiView.cpp	(revision 37592)
+++ src/frontends/qt4/GuiView.cpp	(working copy)
@@ -58,7 +58,7 @@
 #include LyXVC.h
 #include Paragraph.h
 #include SpellChecker.h
-#include TexRow.h
+
 #include TextClass.h
 #include Text.h
 #include Toolbars.h
@@ -80,6 +80,7 @@
 #include support/Systemcall.h
 #include support/Timeout.h
 #include support/ProgressInterface.h
+#include support/TexRow.h
 
 #include QAction
 #include QApplication
Index: src/frontends/qt4/GuiViewSource.cpp
===
--- src/frontends/qt4/GuiViewSource.cpp	(revision 37592)
+++ src/frontends/qt4/GuiViewSource.cpp	(working copy)
@@ -22,12 +22,13 @@
 #include Cursor.h
 #include Format.h
 #include Paragraph.h
-#include TexRow.h
 
+
 #include support/debug.h
 #include support/lassert.h
 #include support/docstream.h
 #include support/gettext.h
+#include support/TexRow.h
 
 #include boost/crc.hpp
 
Index: src/graphics/PreviewLoader.cpp
===
--- src/graphics/PreviewLoader.cpp	(revision 37592)
+++ src/graphics/PreviewLoader.cpp	(working copy)
@@ -24,7 +24,6 @@
 #include LyXRC.h
 #include output.h
 #include OutputParams.h
-#include TexRow.h
 
 #include frontends/Application.h // hexName
 
@@ -36,6 +35,7 @@
 #include support/filetools.h
 #include support/ForkedCalls.h
 #include support/lstrings.h
+#include support/TexRow.h
 
 #include support/bind.h
 
Index: src/insets/InsetText.cpp
===
--- src/insets/InsetText.cpp	(revision 37592)
+++ src/insets/InsetText.cpp	(working copy)
@@ -45,7 +45,6 @@
 #include ParIterator.h
 #include Row.h
 #include sgml.h
-#include TexRow.h
 #include TextClass.h
 #include Text.h
 #include TextMetrics.h
@@ -57,7 +56,7 @@
 #include support/debug.h
 #include support/gettext.h
 #include support/lstrings.h
-
+#include support/TexRow.h
 #include

Re: client

2011-02-10 Thread Enrico Forestieri 
On Fri, Feb 11, 2011 at 12:54:02AM +0100, Peter Kümmel wrote:
 Am I the only one where client does not build?
 
 I have to move TexRow.cpp/.h to support to fix it.
 
 Should I commit?

It compiles and links fine here.

-- 
Enrico

Re: r37591 - in lyx-devel/trunk/src: . mathed

2011-02-10 Thread Enrico Forestieri 
On Fri, Feb 11, 2011 at 12:49:22AM +0100, Peter Kümmel wrote:
 On 11.02.2011 00:34, Enrico Forestieri wrote:
 No, const variables have internal linkage, so they will not be seen outside
 their compile unit. Simply declare them as extern also in version.cpp.
 
 
 You mean declaring it in the header as extern const int i is the same as
 .h:   const int i;
 .cpp  static int i;

No, I mean that if you want a global const variable with external linkage,
the correct C++ way of doing it is
.hextern const int i;
.cpp  extern const int i = value;

-- 
Enrico

Re: client

2011-02-10 Thread Enrico Forestieri 
On Fri, Feb 11, 2011 at 01:02:03AM +0100, Enrico Forestieri wrote:
 On Fri, Feb 11, 2011 at 12:54:02AM +0100, Peter Kümmel wrote:
  Am I the only one where client does not build?
  
  I have to move TexRow.cpp/.h to support to fix it.
  
  Should I commit?
 
 It compiles and links fine here.

I mean without this patch.

-- 
Enrico

Re: client

2011-02-10 Thread Pavel Sanda 
Enrico Forestieri wrote:
 On Fri, Feb 11, 2011 at 12:54:02AM +0100, Peter Kümmel wrote:
  Am I the only one where client does not build?
  
  I have to move TexRow.cpp/.h to support to fix it.
  
  Should I commit?
 
 It compiles and links fine here.

+1

isn't it rather cmake issue?
pavel

Re: client

2011-02-10 Thread Vincent van Ravesteijn 

 Op 11-2-2011 1:02, Enrico Forestieri schreef:

On Fri, Feb 11, 2011 at 12:54:02AM +0100, Peter Kümmel wrote:

Am I the only one where client does not build?

I have to move TexRow.cpp/.h to support to fix it.

Should I commit?

It compiles and links fine here.

No problem here either, but that might as well be because the client is 
not compiled on Windows anyway ;)


Vincent

Re: client

2011-02-10 Thread Peter Kümmel 

On 11.02.2011 01:05, Enrico Forestieri wrote:

On Fri, Feb 11, 2011 at 01:02:03AM +0100, Enrico Forestieri wrote:

On Fri, Feb 11, 2011 at 12:54:02AM +0100, Peter Kümmel wrote:

Am I the only one where client does not build?

I have to move TexRow.cpp/.h to support to fix it.

Should I commit?


It compiles and links fine here.


Indeed, also tried it with the auto tools.



I mean without this patch.

Re: client

2011-02-10 Thread Peter Kümmel 

On 11.02.2011 01:04, Pavel Sanda wrote:

Enrico Forestieri wrote:

On Fri, Feb 11, 2011 at 12:54:02AM +0100, Peter Kümmel wrote:

Am I the only one where client does not build?

I have to move TexRow.cpp/.h to support to fix it.

Should I commit?


It compiles and links fine here.


+1

isn't it rather cmake issue?


A LYX_MERGE_FILES issue.


pavel

Re: r37591 - in lyx-devel/trunk/src: . mathed

2011-02-10 Thread Peter Kümmel 

On 11.02.2011 00:34, Enrico Forestieri wrote:

On Fri, Feb 11, 2011 at 12:06:00AM +0100, Pavel Sanda wrote:

kuem...@lyx.org wrote:

Author: kuemmel
Date: Thu Feb 10 23:57:41 2011
New Revision: 37591
URL: http://www.lyx.org/trac/changeset/37591

Log:
compile.

Modified: lyx-devel/trunk/src/version.cpp
==
--- lyx-devel/trunk/src/version.cpp Thu Feb 10 23:44:59 2011(r37590)
+++ lyx-devel/trunk/src/version.cpp Thu Feb 10 23:57:41 2011(r37591)
@@ -14,8 +14,8 @@
  ///
  char const * lyx_version = PACKAGE_VERSION;
  ///
-int lyx_version_major = LYX_MAJOR_VERSION;
-int lyx_version_minor = LYX_MINOR_VERSION;
+const int lyx_version_major = LYX_MAJOR_VERSION;
+const int lyx_version_minor = LYX_MINOR_VERSION;


it was no oversight i didn't put const there, since my linker chokes on it.
what was your error?
liblyxcore.a(Buffer.o): In function `lyx::Buffer::write(std::basic_ostreamchar, 
std::char_traitschar  ) const':
Buffer.cpp:(.text+0x16ee): undefined reference to `lyx_version_major'
Buffer.cpp:(.text+0x171c): undefined reference to `lyx_version_minor'
collect2: ld returned 1 exit status

maybe we need to kill const.


No, const variables have internal linkage, so they will not be seen outside
their compile unit. Simply declare them as extern also in version.cpp.


Is there a reason not to use functions? ( int lyx_version_major(); )
Globals functions are evil. But global variables let hell look like a freezer.

Peter

Re: r37591 - in lyx-devel/trunk/src: . mathed

2011-02-10 Thread Vincent van Ravesteijn 

 Op 11-2-2011 2:00, Peter Kümmel schreef:

On 11.02.2011 00:34, Enrico Forestieri wrote:

On Fri, Feb 11, 2011 at 12:06:00AM +0100, Pavel Sanda wrote:

kuem...@lyx.org wrote:

Author: kuemmel
Date: Thu Feb 10 23:57:41 2011
New Revision: 37591
URL: http://www.lyx.org/trac/changeset/37591

Log:
compile.

Modified: lyx-devel/trunk/src/version.cpp
== 

--- lyx-devel/trunk/src/version.cppThu Feb 10 23:44:59 2011
(r37590)
+++ lyx-devel/trunk/src/version.cppThu Feb 10 23:57:41 2011
(r37591)

@@ -14,8 +14,8 @@
  ///
  char const * lyx_version = PACKAGE_VERSION;
  ///
-int lyx_version_major = LYX_MAJOR_VERSION;
-int lyx_version_minor = LYX_MINOR_VERSION;
+const int lyx_version_major = LYX_MAJOR_VERSION;
+const int lyx_version_minor = LYX_MINOR_VERSION;


it was no oversight i didn't put const there, since my linker chokes 
on it.

what was your error?
liblyxcore.a(Buffer.o): In function 
`lyx::Buffer::write(std::basic_ostreamchar, std::char_traitschar 
) const':

Buffer.cpp:(.text+0x16ee): undefined reference to `lyx_version_major'
Buffer.cpp:(.text+0x171c): undefined reference to `lyx_version_minor'
collect2: ld returned 1 exit status

maybe we need to kill const.


No, const variables have internal linkage, so they will not be seen 
outside

their compile unit. Simply declare them as extern also in version.cpp.


Is there a reason not to use functions? ( int lyx_version_major(); )
Globals functions are evil. But global variables let hell look like a 
freezer.


Peter
As long as variables are declared const, it's not a real problem I 
guess. Technically, if they are const, they are no variables anymore.


At least one knows immediately that the global variables are 
constants, otherwise we would have used functions for sure. And one 
never knows whether a function always returns  a constant or not. So, I 
feel like global functions are worse than const global variables, but 
better than non-const global variables.


Vincent

Re: r37594 - lyx-devel/trunk/src

2011-02-10 Thread Pavel Sanda 
for...@lyx.org wrote:
 Author: forenr
 Date: Fri Feb 11 01:46:49 2011
 New Revision: 37594
 URL: http://www.lyx.org/trac/changeset/37594
 
 Log:
 So, let's constify all globals in version.cpp...

and monolithic builds will go to hell now :)
pavel

Re: r37591 - in lyx-devel/trunk/src: . mathed

2011-02-10 Thread Peter Kümmel 



As long as variables are declared const, it's not a real problem I
guess. Technically, if they are const, they are no variables anymore.

At least one knows immediately that the global variables are
constants, otherwise we would have used functions for sure. And one
never knows whether a function always returns  a constant or not. So, I
feel like global functions are worse than const global variables, but
better than non-const global variables.

Vincent


Isn't there a GCC warning about const return values of functions?
Declaring return values as const makes not much sense:

extern const int lyx_version_major;
int i = lyx_version_major;
i++;

is also possible, as

int lyx_version_major();
int i = lyx_version_major();
i++;

So you could ignore the const of the return value because
it  will not influence the value which will be returned the
next time.

Seeing all the problems with extern  Co. I think a
macro is even bette
r than all the extern const.

Or couldn't we use a sruct?

struct LyxVersion {
  LyxVersion();
  int version;
  int major;
  int minor;
  int patch;
};

We are not forced to look like a C project.

Peter

Re: r37591 - in lyx-devel/trunk/src: . mathed

2011-02-10 Thread Pavel Sanda 
Peter Kümmel wrote:
 Seeing all the problems with extern  Co. I think a macro is even better than 
 all the extern const.

in that case we can directly use PACKAGE_VERSION etc given from environment...

pavel

Re: r37595 - lyx-devel/trunk/src

2011-02-10 Thread Pavel Sanda 
kuem...@lyx.org wrote:
 Author: kuemmel
 Date: Fri Feb 11 03:09:22 2011
 New Revision: 37595
 URL: http://www.lyx.org/trac/changeset/37595
 
 Log:
 seems the other have different compilers ;)

this works here in both normal and monolithic case. p

Re: r37595 - lyx-devel/trunk/src

2011-02-10 Thread Peter Kümmel 

On 11.02.2011 03:16, Pavel Sanda wrote:

kuem...@lyx.org wrote:

Author: kuemmel
Date: Fri Feb 11 03:09:22 2011
New Revision: 37595
URL: http://www.lyx.org/trac/changeset/37595

Log:
seems the other have different compilers ;)


this works here in both normal and monolithic case. p



Is there also a monolithic build with auto tools?

Peter

Re: r37353 - lyx-devel/trunk/lib/lyx2lyx

2011-02-10 Thread Jean-Marc Lasgouttes 

Le 28/01/11 20:48, rgh...@lyx.org a écrit :

Author: rgheck
Date: Fri Jan 28 20:48:03 2011
New Revision: 37353
URL: http://www.lyx.org/trac/changeset/37353

Log:
Fix lyx2lyx problem with sweave files and ParBreakIsNewline.


Richard,

I was about to revert the workaround in sweave.lyx example file and I 
find that it does not work after all. Did you try the file


http://www.lyx.org/trac/export/37219/lyx-devel/trunk/lib/examples/sweave.lyx
?

I find that the R chunks do not get centered at all...

JMarc

Re: r37580 - lyx-devel/trunk/development/cmake

2011-02-10 Thread Pavel Sanda 
kor...@lyx.org wrote:
> Author: kornel
> Date: Thu Feb 10 07:16:12 2011
> New Revision: 37580
> URL: http://www.lyx.org/trac/changeset/37580
> 
> Log:
> Define LYX_(MAJOR|MINOR)_VERSION also for cmake build
> 
> Modified:
>lyx-devel/trunk/development/cmake/config.h.cmake
> 
> Modified: lyx-devel/trunk/development/cmake/config.h.cmake
> ==
> --- lyx-devel/trunk/development/cmake/config.h.cmake  Wed Feb  9 23:19:14 
> 2011(r37579)
> +++ lyx-devel/trunk/development/cmake/config.h.cmake  Thu Feb 10 07:16:12 
> 2011(r37580)
> @@ -32,6 +32,8 @@
>  #cmakedefine VERSION_INFO "${VERSION_INFO}"
>  #cmakedefine LYX_DIR_VER "${LYX_DIR_VER}"
>  #cmakedefine LYX_USERDIR_VER "${LYX_USERDIR_VER}"
> +#define LYX_MAJOR_VERSION ${LYX_MAJOR_VERSION}
> +#define LYX_MINOR_VERSION ${LYX_MINOR_VERSION}

huh, this didn't come to my mind. now i think scons will suffer from the same 
problem.
please is there anybody around using scons to test?

pavel

hebrew support in lyx 2.0?

2011-02-10 Thread Richman Reuven 
hi, i can't seem to find any info on possible changes of hebrew support
in the new version (2.0), was there something supposed to happen? (i'd
gladly test it if i knew what to look for)

thanks,
reuven r.

Re: hebrew support in lyx 2.0?

2011-02-10 Thread Pavel Sanda 
Richman Reuven wrote:
> hi, i can't seem to find any info on possible changes of hebrew support
> in the new version (2.0), was there something supposed to happen? (i'd
> gladly test it if i knew what to look for)

the thing which could be good to test is that all hebrew stuff you used in 1.6
still works in 2.0. no new particular hebrew features were done, but some
additions like xetex support might have some impact.

pavel

Re: Cjk Lyx 1.4

2011-02-10 Thread Jürgen Spitzmüller 
Jürgen Spitzmüller wrote:
> > "Send exported file to command"
> 
> A bit verbose for a label, but OK, we have enough space here.

I've committed this now.

Jesper, does your plan to implement export menu disabling still stand? 

Jürgen

Re: [patch] Controlling newlines on export

2011-02-10 Thread Enrico Forestieri 
On Thu, Feb 10, 2011 at 01:58:07AM +0100, Enrico Forestieri wrote:
> 
> I have a working patch (see attached). It integrates texrow with
> otexstream and the line counting is thus automatic. I tested it
> quite thoroughly, and it seems to be better than what we have now,
> in the sense that it seems to be more accurate both for forward/reverse
> search and error positioning. For example, I added in ERT \foo to the
> right of the figure in Sec. 4.6.1.4 of the user guide and tried to
> preview the document. Without the attached patch, the section title
> (Wrap Floats) was highlighted, whereas with the patch the ERT was opened
> and exactly \foo was highlighted. Cool!

Given that the patch is quite strightforward, is more accurate in
the line counting task, does not introduce regressions, and can be
seen as the completion of previous work, I am going to commit it.

-- 
Enrico

Re: [patch] Controlling newlines on export

2011-02-10 Thread Pavel Sanda 
Enrico Forestieri wrote:
> Given that the patch is quite strightforward, is more accurate in
> the line counting task, does not introduce regressions, and can be
> seen as the completion of previous work, I am going to commit it.

Enrico, could you have possibly look on bug #7186 when you are after
forw/rev search now? thats much worse issue and i have really no time
on it

pavel

Re: [patch] Controlling newlines on export

2011-02-10 Thread Enrico Forestieri 
On Thu, Feb 10, 2011 at 10:02:18PM +0100, Pavel Sanda wrote:
> 
> Enrico, could you have possibly look on bug #7186 when you are after
> forw/rev search now? thats much worse issue and i have really no time
> on it

It's not any better here, but I'll try to have a look.

-- 
Enrico

Re: hebrew support in lyx 2.0?

2011-02-10 Thread Vincent van Ravesteijn 
On Thu, Feb 10, 2011 at 1:49 PM, Richman Reuven
 wrote:
> hi, i can't seem to find any info on possible changes of hebrew support
> in the new version (2.0), was there something supposed to happen? (i'd
> gladly test it if i knew what to look for)
>
>

If you like to bughunt: http://www.lyx.org/trac/ticket/7097.

Vincent

Re: r37353 - lyx-devel/trunk/lib/lyx2lyx

2011-02-10 Thread Richard Heck 

On 02/10/2011 06:03 AM, Jean-Marc Lasgouttes wrote:

Le 28/01/11 20:48, rgh...@lyx.org a écrit :

Author: rgheck
Date: Fri Jan 28 20:48:03 2011
New Revision: 37353
URL: http://www.lyx.org/trac/changeset/37353

Log:
Fix lyx2lyx problem with sweave files and ParBreakIsNewline.


Richard,

I was about to revert the workaround in sweave.lyx example file and I 
find that it does not work after all. Did you try the file


http://www.lyx.org/trac/export/37219/lyx-devel/trunk/lib/examples/sweave.lyx 


?

I find that the R chunks do not get centered at all...

This is weird. Try this. Open the file in LyX. Now center things 
manually and save. Close and reopen. Not centered!! So it's not a 
lyx2lyx problem (you can look in the converted file and see all the 
centering stuff) but something that's happening somewhere else. Is it 
because this is within a figure?


Richard

Re: r37364 - lyx-devel/trunk/development/autotests

2011-02-10 Thread Tommaso Cucinotta 

Il 09/02/2011 09:52, Enrico Forestieri ha scritto:

On Tue, Feb 08, 2011 at 10:53:34PM +0100, Pavel Sanda wrote:

having cs_CZ locales setup on system level sometimes locales does not work
either when make install is not done or something like that... i'm not able to
give exact recipy and frankly even wont to touch it :)

If you run lyx in place (without installing it) and want cs translations,
do the following:

$ cd
$ mkdir -p locale/cs/LC_MESSAGES
$ ln -s ../../../po/cs.gmo locale/cs/LC_MESSAGES/lyx.mo

Thanks. I added a variant of this trick in r37589, that makes the
autotests work also when there is no LyX installed at all on the system.
I didn't apply the  part, as I never configured with
--with-version-suffix. Where is such suffix is stored, in a Makefile var ?


T.

Re: r37591 - in lyx-devel/trunk/src: . mathed

2011-02-10 Thread Pavel Sanda 
kuem...@lyx.org wrote:
> Author: kuemmel
> Date: Thu Feb 10 23:57:41 2011
> New Revision: 37591
> URL: http://www.lyx.org/trac/changeset/37591
> 
> Log:
> compile.
> 
> Modified: lyx-devel/trunk/src/version.cpp
> ==
> --- lyx-devel/trunk/src/version.cpp   Thu Feb 10 23:44:59 2011(r37590)
> +++ lyx-devel/trunk/src/version.cpp   Thu Feb 10 23:57:41 2011(r37591)
> @@ -14,8 +14,8 @@
>  ///
>  char const * lyx_version = PACKAGE_VERSION;
>  ///
> -int lyx_version_major = LYX_MAJOR_VERSION;
> -int lyx_version_minor = LYX_MINOR_VERSION;
> +const int lyx_version_major = LYX_MAJOR_VERSION;
> +const int lyx_version_minor = LYX_MINOR_VERSION;

it was no oversight i didn't put const there, since my linker chokes on it.
what was your error?
liblyxcore.a(Buffer.o): In function 
`lyx::Buffer::write(std::basic_ostream&) const':
Buffer.cpp:(.text+0x16ee): undefined reference to `lyx_version_major'
Buffer.cpp:(.text+0x171c): undefined reference to `lyx_version_minor'
collect2: ld returned 1 exit status

maybe we need to kill const.

pavel

Re: r37364 - lyx-devel/trunk/development/autotests

2011-02-10 Thread Enrico Forestieri 
On Thu, Feb 10, 2011 at 11:44:13PM +0100, Tommaso Cucinotta wrote:
> Il 09/02/2011 09:52, Enrico Forestieri ha scritto:
> >On Tue, Feb 08, 2011 at 10:53:34PM +0100, Pavel Sanda wrote:
> >>having cs_CZ locales setup on system level sometimes locales does not work
> >>either when make install is not done or something like that... i'm not able 
> >>to
> >>give exact recipy and frankly even wont to touch it :)
> >If you run lyx in place (without installing it) and want cs translations,
> >do the following:
> >
> >$ cd
> >$ mkdir -p locale/cs/LC_MESSAGES
> >$ ln -s ../../../po/cs.gmo locale/cs/LC_MESSAGES/lyx.mo
> Thanks. I added a variant of this trick in r37589, that makes the
> autotests work also when there is no LyX installed at all on the system.
> I didn't apply the  part, as I never configured with
> --with-version-suffix. Where is such suffix is stored, in a Makefile var ?

You can find it in config.h:

/* Program version suffix */
#define PROGRAM_SUFFIX "-2.0"


but you can also directly use PACKAGE.mo, again getting PACKAGE from
config.h:

/* Name of package */
#define PACKAGE "lyx-2.0"


as it already contains the suffix, if specified.

-- 
Enrico

Re: r37353 - lyx-devel/trunk/lib/lyx2lyx

2011-02-10 Thread Richard Heck 

On 02/10/2011 05:32 PM, Richard Heck wrote:

On 02/10/2011 06:03 AM, Jean-Marc Lasgouttes wrote:

Le 28/01/11 20:48, rgh...@lyx.org a écrit :

Author: rgheck
Date: Fri Jan 28 20:48:03 2011
New Revision: 37353
URL: http://www.lyx.org/trac/changeset/37353

Log:
Fix lyx2lyx problem with sweave files and ParBreakIsNewline.


Richard,

I was about to revert the workaround in sweave.lyx example file and I 
find that it does not work after all. Did you try the file


http://www.lyx.org/trac/export/37219/lyx-devel/trunk/lib/examples/sweave.lyx 


?

I find that the R chunks do not get centered at all...

This is weird. Try this. Open the file in LyX. Now center things 
manually and save. Close and reopen. Not centered!! So it's not a 
lyx2lyx problem (you can look in the converted file and see all the 
centering stuff) but something that's happening somewhere else. Is it 
because this is within a figure?



The params are being read correctly. The problem is here:

void InsetText::fixParagraphsFont()
{
  Font font(inherit_font, buffer().params().language);
  font.setLanguage(latex_language);
  ParagraphList::iterator par = paragraphs().begin();
  ParagraphList::iterator const end = paragraphs().end();
  while (par != end) {
if (par->isPassThru()) {
  par->resetFonts(font);
  par->params().clear();
}
++par;
  }
}

This gets called at the end of InsetText::read(), and because we are 
PassThru, all the params get reset to their defaults. Hence, no centering.


Richard

Re: r37591 - in lyx-devel/trunk/src: . mathed

2011-02-10 Thread Enrico Forestieri 
On Fri, Feb 11, 2011 at 12:06:00AM +0100, Pavel Sanda wrote:
> kuem...@lyx.org wrote:
> > Author: kuemmel
> > Date: Thu Feb 10 23:57:41 2011
> > New Revision: 37591
> > URL: http://www.lyx.org/trac/changeset/37591
> > 
> > Log:
> > compile.
> > 
> > Modified: lyx-devel/trunk/src/version.cpp
> > ==
> > --- lyx-devel/trunk/src/version.cpp Thu Feb 10 23:44:59 2011(r37590)
> > +++ lyx-devel/trunk/src/version.cpp Thu Feb 10 23:57:41 2011(r37591)
> > @@ -14,8 +14,8 @@
> >  ///
> >  char const * lyx_version = PACKAGE_VERSION;
> >  ///
> > -int lyx_version_major = LYX_MAJOR_VERSION;
> > -int lyx_version_minor = LYX_MINOR_VERSION;
> > +const int lyx_version_major = LYX_MAJOR_VERSION;
> > +const int lyx_version_minor = LYX_MINOR_VERSION;
> 
> it was no oversight i didn't put const there, since my linker chokes on it.
> what was your error?
> liblyxcore.a(Buffer.o): In function 
> `lyx::Buffer::write(std::basic_ostream&) 
> const':
> Buffer.cpp:(.text+0x16ee): undefined reference to `lyx_version_major'
> Buffer.cpp:(.text+0x171c): undefined reference to `lyx_version_minor'
> collect2: ld returned 1 exit status
> 
> maybe we need to kill const.

No, const variables have internal linkage, so they will not be seen outside
their compile unit. Simply declare them as "extern" also in version.cpp.

-- 
Enrico

Re: r37591 - in lyx-devel/trunk/src: . mathed

2011-02-10 Thread Peter Kümmel 

On 11.02.2011 00:34, Enrico Forestieri wrote:

On Fri, Feb 11, 2011 at 12:06:00AM +0100, Pavel Sanda wrote:

kuem...@lyx.org wrote:

Author: kuemmel
Date: Thu Feb 10 23:57:41 2011
New Revision: 37591
URL: http://www.lyx.org/trac/changeset/37591

Log:
compile.

Modified: lyx-devel/trunk/src/version.cpp
==
--- lyx-devel/trunk/src/version.cpp Thu Feb 10 23:44:59 2011(r37590)
+++ lyx-devel/trunk/src/version.cpp Thu Feb 10 23:57:41 2011(r37591)
@@ -14,8 +14,8 @@
  ///
  char const * lyx_version = PACKAGE_VERSION;
  ///
-int lyx_version_major = LYX_MAJOR_VERSION;
-int lyx_version_minor = LYX_MINOR_VERSION;
+const int lyx_version_major = LYX_MAJOR_VERSION;
+const int lyx_version_minor = LYX_MINOR_VERSION;


it was no oversight i didn't put const there, since my linker chokes on it.
what was your error?
liblyxcore.a(Buffer.o): In function `lyx::Buffer::write(std::basic_ostream&) const':
Buffer.cpp:(.text+0x16ee): undefined reference to `lyx_version_major'
Buffer.cpp:(.text+0x171c): undefined reference to `lyx_version_minor'
collect2: ld returned 1 exit status

maybe we need to kill const.


No, const variables have internal linkage, so they will not be seen outside
their compile unit. Simply declare them as "extern" also in version.cpp.



You mean declaring it in the header as "extern const int i" is the same as
.h:   const int i;
.cpp  static int i;

Seems I will never stop learning new C/C++ "features" ;)

Peter

client

2011-02-10 Thread Peter Kümmel 

Am I the only one where client does not build?

I have to move TexRow.cpp/.h to support to fix it.

Should I commit?

Peter
Index: development/scons/scons_manifest.py
===
--- development/scons/scons_manifest.py	(revision 37592)
+++ development/scons/scons_manifest.py	(working copy)
@@ -126,7 +126,6 @@
 sgml.h
 Spacing.h
 SpellChecker.h
-TexRow.h
 Text.h
 TextClass.h
 TextMetrics.h
@@ -222,7 +221,6 @@
 Session.cpp
 sgml.cpp
 Spacing.cpp
-TexRow.cpp
 Text.cpp
 Text2.cpp
 Text3.cpp
@@ -324,6 +322,7 @@
 Systemcall.h
 SystemcallPrivate.h
 textutils.h
+TexRow.h
 Timeout.h
 Translator.h
 types.h
@@ -357,6 +356,7 @@
 qstring_helpers.cpp
 socktools.cpp
 Systemcall.cpp
+TexRow.cpp
 Timeout.cpp
 unicode.cpp
 userinfo.cpp
Index: src/Buffer.cpp
===
--- src/Buffer.cpp	(revision 37592)
+++ src/Buffer.cpp	(working copy)
@@ -55,7 +55,6 @@
 #include "PDFOptions.h"
 #include "SpellChecker.h"
 #include "sgml.h"
-#include "TexRow.h"
 #include "TexStream.h"
 #include "Text.h"
 #include "TextClass.h"
@@ -102,6 +101,7 @@
 #include "support/Systemcall.h"
 #include "support/textutils.h"
 #include "support/types.h"
+#include "support/TexRow.h"
 
 #include "support/bind.h"
 #include "support/shared_ptr.h"
Index: src/buffer_funcs.cpp
===
--- src/buffer_funcs.cpp	(revision 37592)
+++ src/buffer_funcs.cpp	(working copy)
@@ -31,7 +31,6 @@
 #include "ParagraphList.h"
 #include "ParagraphParameters.h"
 #include "ParIterator.h"
-#include "TexRow.h"
 #include "Text.h"
 #include "TocBackend.h"
 
@@ -47,6 +46,7 @@
 #include "support/gettext.h"
 #include "support/lstrings.h"
 #include "support/textutils.h"
+#include "support/TexRow.h"
 
 using namespace std;
 using namespace lyx::support;
Index: src/BufferParams.cpp
===
--- src/BufferParams.cpp	(revision 37592)
+++ src/BufferParams.cpp	(working copy)
@@ -35,7 +35,6 @@
 #include "LyXRC.h"
 #include "OutputParams.h"
 #include "Spacing.h"
-#include "TexRow.h"
 #include "VSpace.h"
 #include "PDFOptions.h"
 
@@ -52,6 +51,7 @@
 #include "support/Messages.h"
 #include "support/Translator.h"
 #include "support/lstrings.h"
+#include "support/TexRow.h"
 
 #include 
 #include 
Index: src/BufferView.cpp
===
--- src/BufferView.cpp	(revision 37592)
+++ src/BufferView.cpp	(working copy)
@@ -49,7 +49,6 @@
 #include "Text.h"
 #include "TextClass.h"
 #include "TextMetrics.h"
-#include "TexRow.h"
 #include "TocBackend.h"
 #include "VSpace.h"
 #include "WordLangTuple.h"
@@ -79,6 +78,7 @@
 #include "support/lstrings.h"
 #include "support/Package.h"
 #include "support/types.h"
+#include "support/TexRow.h"
 
 #include 
 #include 
Index: src/frontends/qt4/GuiView.cpp
===
--- src/frontends/qt4/GuiView.cpp	(revision 37592)
+++ src/frontends/qt4/GuiView.cpp	(working copy)
@@ -58,7 +58,7 @@
 #include "LyXVC.h"
 #include "Paragraph.h"
 #include "SpellChecker.h"
-#include "TexRow.h"
+
 #include "TextClass.h"
 #include "Text.h"
 #include "Toolbars.h"
@@ -80,6 +80,7 @@
 #include "support/Systemcall.h"
 #include "support/Timeout.h"
 #include "support/ProgressInterface.h"
+#include "support/TexRow.h"
 
 #include 
 #include 
Index: src/frontends/qt4/GuiViewSource.cpp
===
--- src/frontends/qt4/GuiViewSource.cpp	(revision 37592)
+++ src/frontends/qt4/GuiViewSource.cpp	(working copy)
@@ -22,12 +22,13 @@
 #include "Cursor.h"
 #include "Format.h"
 #include "Paragraph.h"
-#include "TexRow.h"
 
+
 #include "support/debug.h"
 #include "support/lassert.h"
 #include "support/docstream.h"
 #include "support/gettext.h"
+#include "support/TexRow.h"
 
 #include 
 
Index: src/graphics/PreviewLoader.cpp
===
--- src/graphics/PreviewLoader.cpp	(revision 37592)
+++ src/graphics/PreviewLoader.cpp	(working copy)
@@ -24,7 +24,6 @@
 #include "LyXRC.h"
 #include "output.h"
 #include "OutputParams.h"
-#include "TexRow.h"
 
 #include "frontends/Application.h" // hexName
 
@@ -36,6 +35,7 @@
 #include "support/filetools.h"
 #include "support/ForkedCalls.h"
 #include "support/lstrings.h"
+#include "support/TexRow.h"
 
 #include "support/bind.h"
 
Index: src/insets/InsetText.cpp
===
--- src/insets/InsetText.cpp	(revision 37592)
+++ src/insets/InsetText.cpp	(working copy)
@@ -45,7 +45,6 @@
 #include "ParIterator.h"
 #include "Row.h"
 #include "sgml.h"
-#include "TexRow.h"
 #include "TextClass.h"
 #include "Text.h"
 #include "TextMetrics.h"
@@ -57,7 +56,7 @@
 #include

Re: client

2011-02-10 Thread Enrico Forestieri 
On Fri, Feb 11, 2011 at 12:54:02AM +0100, Peter Kümmel wrote:
> Am I the only one where client does not build?
> 
> I have to move TexRow.cpp/.h to support to fix it.
> 
> Should I commit?

It compiles and links fine here.

-- 
Enrico

Re: r37591 - in lyx-devel/trunk/src: . mathed

2011-02-10 Thread Enrico Forestieri 
On Fri, Feb 11, 2011 at 12:49:22AM +0100, Peter Kümmel wrote:
> On 11.02.2011 00:34, Enrico Forestieri wrote:
> >No, const variables have internal linkage, so they will not be seen outside
> >their compile unit. Simply declare them as "extern" also in version.cpp.
> >
> 
> You mean declaring it in the header as "extern const int i" is the same as
> .h:   const int i;
> .cpp  static int i;

No, I mean that if you want a global const variable with external linkage,
the correct C++ way of doing it is
.hextern const int i;
.cpp  extern const int i = ;

-- 
Enrico

Re: client

2011-02-10 Thread Enrico Forestieri 
On Fri, Feb 11, 2011 at 01:02:03AM +0100, Enrico Forestieri wrote:
> On Fri, Feb 11, 2011 at 12:54:02AM +0100, Peter Kümmel wrote:
> > Am I the only one where client does not build?
> > 
> > I have to move TexRow.cpp/.h to support to fix it.
> > 
> > Should I commit?
> 
> It compiles and links fine here.

I mean without this patch.

-- 
Enrico

Re: client

2011-02-10 Thread Pavel Sanda 
Enrico Forestieri wrote:
> On Fri, Feb 11, 2011 at 12:54:02AM +0100, Peter Kümmel wrote:
> > Am I the only one where client does not build?
> > 
> > I have to move TexRow.cpp/.h to support to fix it.
> > 
> > Should I commit?
> 
> It compiles and links fine here.

+1

isn't it rather cmake issue?
pavel

Re: client

2011-02-10 Thread Vincent van Ravesteijn 

 Op 11-2-2011 1:02, Enrico Forestieri schreef:

On Fri, Feb 11, 2011 at 12:54:02AM +0100, Peter Kümmel wrote:

Am I the only one where client does not build?

I have to move TexRow.cpp/.h to support to fix it.

Should I commit?

It compiles and links fine here.

No problem here either, but that might as well be because the client is 
not compiled on Windows anyway ;)


Vincent

Re: client

2011-02-10 Thread Peter Kümmel 

On 11.02.2011 01:05, Enrico Forestieri wrote:

On Fri, Feb 11, 2011 at 01:02:03AM +0100, Enrico Forestieri wrote:

On Fri, Feb 11, 2011 at 12:54:02AM +0100, Peter Kümmel wrote:

Am I the only one where client does not build?

I have to move TexRow.cpp/.h to support to fix it.

Should I commit?


It compiles and links fine here.


Indeed, also tried it with the auto tools.



I mean without this patch.

Re: client

2011-02-10 Thread Peter Kümmel 

On 11.02.2011 01:04, Pavel Sanda wrote:

Enrico Forestieri wrote:

On Fri, Feb 11, 2011 at 12:54:02AM +0100, Peter Kümmel wrote:

Am I the only one where client does not build?

I have to move TexRow.cpp/.h to support to fix it.

Should I commit?


It compiles and links fine here.


+1

isn't it rather cmake issue?


A LYX_MERGE_FILES issue.


pavel

Re: r37591 - in lyx-devel/trunk/src: . mathed

2011-02-10 Thread Peter Kümmel 

On 11.02.2011 00:34, Enrico Forestieri wrote:

On Fri, Feb 11, 2011 at 12:06:00AM +0100, Pavel Sanda wrote:

kuem...@lyx.org wrote:

Author: kuemmel
Date: Thu Feb 10 23:57:41 2011
New Revision: 37591
URL: http://www.lyx.org/trac/changeset/37591

Log:
compile.

Modified: lyx-devel/trunk/src/version.cpp
==
--- lyx-devel/trunk/src/version.cpp Thu Feb 10 23:44:59 2011(r37590)
+++ lyx-devel/trunk/src/version.cpp Thu Feb 10 23:57:41 2011(r37591)
@@ -14,8 +14,8 @@
  ///
  char const * lyx_version = PACKAGE_VERSION;
  ///
-int lyx_version_major = LYX_MAJOR_VERSION;
-int lyx_version_minor = LYX_MINOR_VERSION;
+const int lyx_version_major = LYX_MAJOR_VERSION;
+const int lyx_version_minor = LYX_MINOR_VERSION;


it was no oversight i didn't put const there, since my linker chokes on it.
what was your error?
liblyxcore.a(Buffer.o): In function `lyx::Buffer::write(std::basic_ostream&) const':
Buffer.cpp:(.text+0x16ee): undefined reference to `lyx_version_major'
Buffer.cpp:(.text+0x171c): undefined reference to `lyx_version_minor'
collect2: ld returned 1 exit status

maybe we need to kill const.


No, const variables have internal linkage, so they will not be seen outside
their compile unit. Simply declare them as "extern" also in version.cpp.


Is there a reason not to use functions? ( int lyx_version_major(); )
Globals functions are evil. But global variables let hell look like a freezer.

Peter

Re: r37591 - in lyx-devel/trunk/src: . mathed

2011-02-10 Thread Vincent van Ravesteijn 

 Op 11-2-2011 2:00, Peter Kümmel schreef:

On 11.02.2011 00:34, Enrico Forestieri wrote:

On Fri, Feb 11, 2011 at 12:06:00AM +0100, Pavel Sanda wrote:

kuem...@lyx.org wrote:

Author: kuemmel
Date: Thu Feb 10 23:57:41 2011
New Revision: 37591
URL: http://www.lyx.org/trac/changeset/37591

Log:
compile.

Modified: lyx-devel/trunk/src/version.cpp
== 

--- lyx-devel/trunk/src/version.cppThu Feb 10 23:44:59 2011
(r37590)
+++ lyx-devel/trunk/src/version.cppThu Feb 10 23:57:41 2011
(r37591)

@@ -14,8 +14,8 @@
  ///
  char const * lyx_version = PACKAGE_VERSION;
  ///
-int lyx_version_major = LYX_MAJOR_VERSION;
-int lyx_version_minor = LYX_MINOR_VERSION;
+const int lyx_version_major = LYX_MAJOR_VERSION;
+const int lyx_version_minor = LYX_MINOR_VERSION;


it was no oversight i didn't put const there, since my linker chokes 
on it.

what was your error?
liblyxcore.a(Buffer.o): In function 
`lyx::Buffer::write(std::basic_ostream&) const':

Buffer.cpp:(.text+0x16ee): undefined reference to `lyx_version_major'
Buffer.cpp:(.text+0x171c): undefined reference to `lyx_version_minor'
collect2: ld returned 1 exit status

maybe we need to kill const.


No, const variables have internal linkage, so they will not be seen 
outside

their compile unit. Simply declare them as "extern" also in version.cpp.


Is there a reason not to use functions? ( int lyx_version_major(); )
Globals functions are evil. But global variables let hell look like a 
freezer.


Peter
As long as variables are declared const, it's not a real problem I 
guess. Technically, if they are const, they are no variables anymore.


At least one knows immediately that the global "variables" are 
constants, otherwise we would have used functions for sure. And one 
never knows whether a function always returns  a constant or not. So, I 
feel like global functions are worse than const global variables, but 
better than non-const global variables.


Vincent

Re: r37594 - lyx-devel/trunk/src

2011-02-10 Thread Pavel Sanda 
for...@lyx.org wrote:
> Author: forenr
> Date: Fri Feb 11 01:46:49 2011
> New Revision: 37594
> URL: http://www.lyx.org/trac/changeset/37594
> 
> Log:
> So, let's constify all globals in version.cpp...

and monolithic builds will go to hell now :)
pavel

Re: r37591 - in lyx-devel/trunk/src: . mathed

2011-02-10 Thread Peter Kümmel 



As long as variables are declared const, it's not a real problem I
guess. Technically, if they are const, they are no variables anymore.

At least one knows immediately that the global "variables" are
constants, otherwise we would have used functions for sure. And one
never knows whether a function always returns  a constant or not. So, I
feel like global functions are worse than const global variables, but
better than non-const global variables.

Vincent


Isn't there a GCC warning about const return values of functions?
Declaring return values as const makes not much sense:

extern const int lyx_version_major;
int i = lyx_version_major;
i++;

is also possible, as

int lyx_version_major();
int i = lyx_version_major();
i++;

So you could ignore the const of the return value because
it  will not influence the value which will be returned the
next time.

Seeing all the problems with extern & Co. I think a
macro is even bette
r than all the "extern const".

Or couldn't we use a sruct?

struct LyxVersion {
  LyxVersion();
  int version;
  int major;
  int minor;
  int patch;
};

We are not forced to look like a C project.

Peter

Re: r37591 - in lyx-devel/trunk/src: . mathed

2011-02-10 Thread Pavel Sanda 
Peter Kümmel wrote:
> Seeing all the problems with extern & Co. I think a macro is even better than 
> all the "extern const".

in that case we can directly use PACKAGE_VERSION etc given from environment...

pavel

Re: r37595 - lyx-devel/trunk/src

2011-02-10 Thread Pavel Sanda 
kuem...@lyx.org wrote:
> Author: kuemmel
> Date: Fri Feb 11 03:09:22 2011
> New Revision: 37595
> URL: http://www.lyx.org/trac/changeset/37595
> 
> Log:
> seems the other have different compilers ;)

this works here in both normal and monolithic case. p

Re: r37595 - lyx-devel/trunk/src

2011-02-10 Thread Peter Kümmel 

On 11.02.2011 03:16, Pavel Sanda wrote:

kuem...@lyx.org wrote:

Author: kuemmel
Date: Fri Feb 11 03:09:22 2011
New Revision: 37595
URL: http://www.lyx.org/trac/changeset/37595

Log:
seems the other have different compilers ;)


this works here in both normal and monolithic case. p



Is there also a monolithic build with auto tools?

Peter