Re: RefStyle, Again

[Jürgen Spitzmüller]

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 documents (or at least: 
the need to rewrite style files and such) is high.

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.

 Richard

Jürgen

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

[Jürgen Spitzmüller]

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; this is quite annoying.

Please consider to call this lyx_logo_vert.bmp once and for all.

Thanks,
Jürgen

 Modified:
lyx-devel/branches/BRANCH_1_6_X/development/Makefile.am
 
 Modified: lyx-devel/branches/BRANCH_1_6_X/development/Makefile.am
 ===
 === --- lyx-devel/branches/BRANCH_1_6_X/development/Makefile.am   Mon Jul 
 12
 07:17:40 2010 (r34865) +++
 lyx-devel/branches/BRANCH_1_6_X/development/Makefile.am   Mon Jul 12
 10:17:13 2010 (r34866) @@ -91,7 +91,7 @@
  Win32/packaging/AltInstaller/icons/lyx_32x32.ico \
  Win32/packaging/AltInstaller/icons/lyx_doc.svg \
  Win32/packaging/AltInstaller/icons/lyx_logo_hi.bmp \
 -Win32/packaging/AltInstaller/icons/lyx_logo_vert166.bmp \
 +Win32/packaging/AltInstaller/icons/lyx_logo_vert167.bmp \
  Win32/packaging/AltInstaller/informations/InstallerStructure.odg \
  Win32/packaging/AltInstaller/informations/InstallerStructure.pdf \
  Win32/packaging/AltInstaller/informations/ISO_3166.html \

branch still frozen

[Jürgen Spitzmüller]

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

Jürgen

Re: LyX 1.6.7

[Jürgen Spitzmüller]

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 problems with msvc10 any more.

OK, thanks.

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 ?

Jürgen

Re: r34810 - lyx-devel/trunk/src

[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
 new 10.6 features. When compiling with 10.5 SDK I cannot check Tiger
 support - I don't have it.

Hmm, too bad. I am surprised though that there is not a simple
explanation somewhere.

Anyway, I prefer your new code to the old one. I did not try it out yet
though.

JMarc

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

[Jean-Marc LASGOUTTES]

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 them.

We could maybe extend InsetInfo to cover this in 2.0. Or is it already
the case?

JMarc

Re: LyX 1.6.7

[Enrico Forestieri]

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 had a workaround in trunk, which is now also in branch,
  so now I have no problems with msvc10 any more.
 
 OK, thanks.
 
 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 not added to src/support/Makefile.am at r34858.

-- 
Enrico

Re: LyX 1.6.7

[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 src/support/numpunct_lyx_char_type.h is missing from the
 tarball. It was not added to src/support/Makefile.am at r34858.

OK, thanks. Next try:

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

Jürgen

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

[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 lost somehow...
 
 I see in the constructor SystemcallPrivate::SystemcallPrivate (SystemCall.cpp)
 the error output of the child process is collected only if it's going to an 
 terminal.
 I think it would be better to collect it unconditionally to show it in the 
 message window.
 What do others think?

whats the point of collecting it if we are not going to show it?
pavel

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

[Pavel Sanda]

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

[Pavel Sanda]

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 missing from the
  tarball. It was not added to src/support/Makefile.am at r34858.
 
 OK, thanks. Next try:
 
 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

builds fine on gentoo.
pavel

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

[Stephan Witt]

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 lost somehow...
 
 I see in the constructor SystemcallPrivate::SystemcallPrivate 
 (SystemCall.cpp)
 the error output of the child process is collected only if it's going to an 
 terminal.
 I think it would be better to collect it unconditionally to show it in the 
 message window.
 What do others think?
 
 whats the point of collecting it if we are not going to show it?

The point is that you can read it when looking for it in the message window.
That's currently not possible, the error messages are lost.

Here on Mac if I start LyX the stdin, stdout and stderr are redirected on 
startup.

If I remove the os::is_terminal(os::STDERR) test the output becomes visible.

Another story is to show the errors in the alert popup. This can be improved 
too.

Stephan

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

[Pavel Sanda]

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

[Pavel Sanda]

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

[Kornel Benko]

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	(Revision 34874)
+++ development/Makefile.am	(Arbeitskopie)
@@ -149,57 +149,57 @@
 scons/scons_manifest.py \
 scons/SConstruct \
 scons/scons_utils.py \
-cmake/build.bat \
-cmake/build-debug.bat \
-cmake/CMakeLists.txt \
-cmake/configCompiler.h.cmake \
-cmake/configCompiler.h.msvc \
-cmake/config.cpp.cmake \
-cmake/config.h.cmake \
-cmake/ConfigureChecks.cmake \
-cmake/Install.cmake \
-cmake/LyX_description.txt \
-cmake/LyX_license.txt \
-cmake/LyX_summary.txt \
-cmake/pcheaders.h \
-cmake/PyCompile.cmake \
-cmake/boost/CMakeLists.txt \
-cmake/boost/libs/CMakeLists.txt \
-cmake/boost/libs/regex/CMakeLists.txt \
-cmake/boost/libs/signals/CMakeLists.txt \
-cmake/doc/CMakeLists.txt \
-cmake/doc/ReplaceValues.pl \
-cmake/intl/CMakeLists.txt \
-cmake/intl/libgnuintl.h \
-cmake/lyx2lyx/CMakeLists.txt \
-cmake/man/CMakeLists.txt \
-cmake/modules/FindAiksaurusLIB.cmake \
-cmake/modules/FindASPELL.cmake \
-cmake/modules/FindGNUWIN32.cmake \
-cmake/modules/FindICONV.cmake \
-cmake/modules/FindLibintl.cmake \
-cmake/modules/FindLyXGettext.cmake \
-cmake/modules/FindMyThesLIB.cmake \
-cmake/modules/FindQt4.cmake \
-cmake/modules/FindZLIB.cmake \
-cmake/modules/LyXMacros.cmake \
-cmake/modules/LyXPaths.cmake \
-cmake/modules/LyXuic.cmake \
-cmake/modules/MacroBoolTo01.cmake \
-cmake/modules/PCHSupport_26.cmake \
-cmake/modules/ProjectSourceGroup.cmake \
-cmake/po/CMakeLists.txt \
-cmake/scripts/CMakeLists.txt \
-cmake/src/CMakeLists.txt \
-cmake/src/dummy.cpp \
-cmake/src/client/CMakeLists.txt \
-cmake/src/frontends/CMakeLists.txt \
-cmake/src/frontends/qt4/CMakeLists.txt \
-cmake/src/graphics/CMakeLists.txt \
-cmake/src/insets/CMakeLists.txt \
-cmake/src/mathed/CMakeLists.txt \
-cmake/src/support/CMakeLists.txt \
-cmake/src/tex2lyx/CMakeLists.txt
-
-# cmake file list generated and sorted by 'ls -Ra'
+cmake/CMakeLists.txt /
+cmake/ConfigureChecks.cmake /
+cmake/Install.cmake /
+cmake/LyX_description.txt /
+cmake/LyX_license.txt /
+cmake/LyX_summary.txt /
+cmake/PyCompile.cmake /
+cmake/build-debug.bat /
+cmake/build.bat /
+cmake/config.cpp.cmake /
+cmake/config.h.cmake /
+cmake/configCompiler.h.cmake /
+cmake/configCompiler.h.msvc /
+cmake/lyx.rc /
+cmake/pcheaders.h /
+cmake/boost/CMakeLists.txt /
+cmake/doc/CMakeLists.txt /
+cmake/doc/ReplaceValues.pl /
+cmake/intl/CMakeLists.txt /
+cmake/intl/libgnuintl.h /
+cmake/lyx2lyx/CMakeLists.txt /
+cmake/man/CMakeLists.txt /
+cmake/modules/FindASPELL.cmake /
+cmake/modules/FindAiksaurusLIB.cmake /
+cmake/modules/FindGNUWIN32.cmake /
+cmake/modules/FindICONV.cmake /
+cmake/modules/FindLibintl.cmake /
+cmake/modules/FindLyXGettext.cmake /
+cmake/modules/FindMyThesLIB.cmake /
+cmake/modules/FindQt4.cmake /
+cmake/modules/FindZLIB.cmake /
+cmake/modules/LyXMacros.cmake /
+cmake/modules/LyXPaths.cmake /
+cmake/modules/LyXuic.cmake /
+cmake/modules/MacroBoolTo01.cmake /
+cmake/modules/PCHSupport_26.cmake /
+cmake/modules/ProjectSourceGroup.cmake /
+cmake/po/CMakeLists.txt /
+cmake/po/cat.py /
+cmake/scripts/CMakeLists.txt /
+cmake/src/CMakeLists.txt /
+cmake/src/dummy.cpp /
+cmake/boost/libs/CMakeLists.txt /
+cmake/src/client/CMakeLists.txt /
+cmake/src/frontends/CMakeLists.txt /
+cmake/src/graphics/CMakeLists.txt /
+cmake/src/insets/CMakeLists.txt /
+cmake/src/mathed/CMakeLists.txt /
+cmake/src/support/CMakeLists.txt /
+cmake/src/tex2lyx/CMakeLists.txt /
+cmake/boost/libs/regex/CMakeLists.txt /
+cmake/boost/libs/signals/CMakeLists.txt /
+cmake/src/frontends/qt4/CMakeLists.txt
 


signature.asc
Description: This is a digitally signed message part.

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

[Jürgen Spitzmüller]

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

[Jürgen Spitzmüller]

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

[Richard Heck]

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 they can
have wrong values if one forgets to update them.
 

We could maybe extend InsetInfo to cover this in 2.0. Or is it already
the case?

   

What is it that we want?

rh

Re: Lyxserver - citation-insert

[Pavel Sanda]

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. \citet. It works as expected from the mini-buffer, i.e.
 inserting (Author, year), \citep.
 Am I missing something or is that a Lyx bug?

what steps should i do to reproduce? minibufer and direct lyxserver 
comunnication
seems to be identical here (and should be).

pavel

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

[Peter Kümmel]

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 line typing 0 or 1 is simpler.

 
 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)
   Kornel

The idea was to cleanup the variable list in cmake-gui.
Found libraries always have their own scope and _ is
not a scope. We set this two variables in our scripts
so wy not prefix them with LYX_?

Peter

Re: LyX 1.6.7

[Peter Kümmel]

 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/
 ftp://ftp.devel.lyx.org/pub/contrib/windows/branch16/
 This includes gettext 0.18 and iconv 1.13.1.
 Perhaps you could use these as well when you upgrade to 2010?
 
 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. So creating a new installer for 2.0 should be 
 much more simple! We should talk about this sometime.
 

Very good!

What was the plan for 2.0?

Peter

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

[Jean-Marc LASGOUTTES]

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 that we had to update after each major release,
and personally I am not sure that the machinery is worth keeping. Other
parts are done transparently through autoconf, but the documentation
cannot be updated like that.

JMarc

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

[Kornel Benko]

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)
  
  Kornel
 
 The idea was to cleanup the variable list in cmake-gui.

But this two are not yet found in the gui ...

Instead there are:
GETTEXT_*_EXECUTABLE (MSGFMT, MSGMERGE, MSGUNIQ,XGETTEXT)
_PYTHON_EXECUTABE
PYTHON_EXECUTABLE
_PERL_EXECUTABLE
QT_*_EXECUTABLE (MOC, QMAKE, RCC, UIC3, UIC)

 Found libraries always have their own scope and _ is
 not a scope. We set this two variables in our scripts
 so wy not prefix them with LYX_?
 
 Peter

Kornel


signature.asc
Description: This is a digitally signed message part.

Dependency Problem?

[Richard Heck]

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


rh

Unavailable Classes

[Richard Heck]

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 classes separately at the end. That makes them harder to 
find, in a way.


One idea is to mark such classes with an asterisk, as in the attached 
patch and screenshot. Comments? Other ideas?


Richard





one change that
LyX developers might consider is to issue a warning message and make
the document class available to the user even if the classes in square
brackets are not installed.

I thought we did that already...


The problem here may be what you see in the dropdown box, e.g.:
Unavailable: article (REVTeX)
That makes it look as if you can't use it, because it is 
Unavailable. But I'm not sure what a better term would be. There 
are improvements in 2.0, too. If you select such a class, then LyX 
will tell you precisely what prerequisites are not satisfied.


Maybe limited availability or even lacks some packages would be 
more on point than Unavailable. What threw me was the fact that the 
unavailable classes are listed separately. Personally, I'd prefer 
colors or font shapes and weights: green (bold) = ready to go, yellow 
(plain text) = lacking some packages, and red (italic) = cannot process.




attachment: lyx.png

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

[Peter Kuemmel]

 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:
 ...
  Yes, but when using the command line typing 0 or 1 is simpler.
 
 Not nice, but ok ...

We simply add both comments.

 
   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)
   
 Kornel
  
  The idea was to cleanup the variable list in cmake-gui.

Too be more precise I wanna remove the Ungrouped Entries group.

 
 But this two are not yet found in the gui ...
 
 Instead there are:
 GETTEXT_*_EXECUTABLE (MSGFMT, MSGMERGE, MSGUNIQ,XGETTEXT)
 _PYTHON_EXECUTABE

Have you removed the cache/cleaned the build dir before running cmake again?

 PYTHON_EXECUTABLE
 _PERL_EXECUTABLE
 QT_*_EXECUTABLE (MOC, QMAKE, RCC, UIC3, UIC)
 

With attached patch there are no ungrouped entries any more an
Linux.

Peter

-- 
GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl.  
Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl
Index: PyCompile.cmake
===
--- PyCompile.cmake	(Revision 34881)
+++ PyCompile.cmake	(Arbeitskopie)
@@ -9,14 +9,14 @@
 #		#include(../PyCompile)
 project(${_project})
 
-include(FindPythonInterp)
+FIND_PROGRAM(LYX_PYTHON_EXECUTABLE python)
 
 file(GLOB _py_files ${TOP_SRC_DIR}/lib/${_project}/*.py)
 
 set(py_compile ${TOP_SRC_DIR}/config/py-compile)
 
 set(_generated)
-set(ENV{PYTHON} ${PYTHON_EXECUTABLE})
+set(ENV{PYTHON} ${LYX_PYTHON_EXECUTABLE})
 
 foreach(_orig_py ${_py_files})
   get_filename_component(_base_we_py ${_orig_py} NAME_WE)
Index: modules/FindLibintl.cmake
===
--- modules/FindLibintl.cmake	(Revision 34881)
+++ modules/FindLibintl.cmake	(Arbeitskopie)
@@ -40,7 +40,6 @@
 
 endif(LIBINTL_INCLUDE_DIR)
 
-#include(FindPackageHandleStandardArgs)
-#find_package_handle_standard_args(Libintl  DEFAULT_MSG  LIBINTL_INCLUDE_DIR  LIBINTL_LIB_FOUND)
+set(LIBINTL_LIBRARIES ${LIBINTL_LIBRARIES} CACHE STRING linintl libs FORCE)
 
 mark_as_advanced(LIBINTL_INCLUDE_DIR  LIBINTL_LIBRARIES  LIBINTL_LIBC_HAS_DGETTEXT  LIBINTL_LIB_FOUND)

Re: r34810 - lyx-devel/trunk/src

[Stephan Witt]

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
 new 10.6 features. When compiling with 10.5 SDK I cannot check Tiger
 support - I don't have it.
 
 Hmm, too bad. I am surprised though that there is not a simple
 explanation somewhere.

I've searched another evening and couldn't find a solution or explanation.
I'll give up for now. :(

Regarding the Tiger support: the distribution candidate .dmg is now 39 MB big.
If someone can test if the 10.5 SDK build with 10.4 deployment target is working
on Tiger I'll happily upload it for the test! Is anyone able to access a Tiger 
system?

 Anyway, I prefer your new code to the old one. I did not try it out yet
 though.

Thanks.

Stephan

Copy and Paste in Multi-File Documents

[Rainer Dorsch]

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 information was 
lost, even the Section numbering was hardcoded (and wrong) after pasting.

Then I did the same within the same document. Worked flawless. Then I tried to 
paste it again to the other document, this time it worked (!). I can imagine 
situations where either behavior makes sense. Can I deterministically choose 
between them?

Also in the navigator I cannot move a section from one file to another, but I 
can move it within a file. Is it worth to open a bug report for that?

Thanks,
Rainer


-- 
Rainer Dorsch
Lärchenstr. 6
D-72135 Dettenhausen
07157-734133
email: rdor...@web.de
jabber: rdor...@jabber.org
GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F  8F59 E3A8 C538 7519 141E
Full GPG key: http://pgp.mit.edu/


signature.asc
Description: This is a digitally signed message part.

Re: Dependency Problem?

[Vincent van Ravesteijn]

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?

[Richard Heck]

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

[Richard Heck]

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 master document). When copying all the formating information was
lost, even the Section numbering was hardcoded (and wrong) after pasting.

Then I did the same within the same document. Worked flawless. Then I tried to
paste it again to the other document, this time it worked (!). I can imagine
situations where either behavior makes sense. Can I deterministically choose
between them?

   
Can you reproduce the unexpected behavior reliably? If so, please give 
us a recipe. That's not at all what is intended, I don't think.



Also in the navigator I cannot move a section from one file to another, but I
can move it within a file. Is it worth to open a bug report for that?

   

Yes. I'm not sure how easy that will be to fix.

rh

Bug #3221: nameref support

[Richard Heck]

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 nameref should be loaded after babel. Any views?


rh

Index: lib/lyx2lyx/lyx_2_0.py
===
--- lib/lyx2lyx/lyx_2_0.py	(revision 34853)
+++ lib/lyx2lyx/lyx_2_0.py	(working copy)
@@ -1931,6 +1931,42 @@
   del document.body[i:j + 1]
 
 
+def revert_nameref(document):
+   Convert namerefs to regular references 
+  # We cannot really revert these properly, so we will
+  # revert them to commands we understand.
+  cmds = [[Nameref, vref], [nameref, ref]]
+  for cmd in cmds:
+i = 0
+oldcmd = LatexCommand  + cmd[0]
+newcmd = LatexCommand  + cmd[1]
+while 1:
+  i = find_token(document.body, oldcmd, i)
+  if i == -1:
+break
+  # Make sure it is actually in an inset!
+  # We could just check document.lines[i-1], but that relies
+  # upon something that might easily change.
+  # We'll look back a few lines.
+  j = i - 10
+  if j  0:
+j = 0
+  j = find_token(document.body, \\begin_inset CommandInset ref, j)
+  if j == -1 or j  i:
+i += 1
+continue
+  k = find_end_of_inset(document.body, i)
+  if k == -1:
+document.warning(Can't find end of inset at line  + j + !!)
+i += 1
+continue
+  if k  i:
+i += 1
+continue
+  document.body[i] = newcmd
+  i += 1
+
+
 ##
 # Conversion hub
 #
@@ -1984,10 +2020,12 @@
[391, []],
[392, [convert_beamer_args]],
[393, [convert_optarg]],
-   [394, []]
+   [394, []],
+   [395, []]
   ]
 
-revert =  [[393, [revert_makebox]],
+revert =  [[394, [revert_nameref]],
+   [393, [revert_makebox]],
[392, [revert_argument]],
[391, [revert_beamer_args]],
[390, [revert_align_decimal, revert_IEEEtran]],
Index: src/Buffer.cpp
===
--- src/Buffer.cpp	(revision 34853)
+++ src/Buffer.cpp	(working copy)
@@ -126,7 +126,7 @@
 
 // Do not remove the comment below, so we get merge conflict in
 // independent branches. Instead add your own.
-int const LYX_FORMAT = 394; // uwestoehr: support for \makebox
+int const LYX_FORMAT = 395; // rgh: nameref
 
 typedef mapstring, bool DepClean;
 typedef mapdocstring, pairInsetLabel const *, Buffer::References  RefCache;
Index: src/BufferParams.cpp
===
--- src/BufferParams.cpp	(revision 34881)
+++ src/BufferParams.cpp	(working copy)
@@ -1732,7 +1732,9 @@
 		texrow.newlines(lines);
 		// set back for the rest
 		lyxpreamble.clear();
-	}
+	} else if (features.isRequired(nameref))
+		// hyperref loads this automatically
+		lyxpreamble += \\usepackage{nameref}\n;
 
 	// Will be surrounded by \makeatletter and \makeatother when not empty
 	docstring atlyxpreamble;
Index: src/frontends/qt4/ui/RefUi.ui
===
--- src/frontends/qt4/ui/RefUi.ui	(revision 34853)
+++ src/frontends/qt4/ui/RefUi.ui	(working copy)
@@ -1,105 +1,103 @@
-ui version=4.0 
+ui version=4.0
  classRefUi/class
- widget class=QDialog name=RefUi 
-  property name=geometry 
+ widget class=QDialog name=RefUi
+  property name=geometry
rect
 x0/x
 y0/y
-width386/width
+width435/width
 height443/height
/rect
   /property
-  property name=windowTitle 
+  property name=windowTitle
string/
   /property
-  property name=sizeGripEnabled 
+  property name=sizeGripEnabled
booltrue/bool
   /property
-  layout class=QGridLayout 
-   property name=margin 
+  layout class=QGridLayout
+   property name=margin
 number9/number
/property
-   property name=spacing 
+   property name=spacing
 number6/number
/property
-   item row=2 column=0 colspan=3 
-layout class=QHBoxLayout 
- property name=margin 
+   item row=2 column=0 colspan=3
+layout class=QHBoxLayout
+ property name=spacing
+  number6/number
+ /property
+ property name=margin
   number0/number
  /property
- property name=spacing 
-  number6/number
- /property
  item
-  widget class=QLabel name=findKeysLA 
-   property name=text 
+  widget class=QLabel name=findKeysLA
+   property name=text
 stringFilamp;ter:/string
/property
-   property name=alignment 
+   property name=alignment
 setQt::AlignLeading|Qt::AlignLeft|Qt::AlignVCenter/set
/property
-   property name=buddy 
+   property name=buddy
 cstringfindLE/cstring
/property
   /widget
  /item
  item
-  widget class=QLineEdit name=findLE 

Re: Bug #3221: nameref support

[Richard Heck]

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 nameref. But if we aren't, then 
maybe nameref should be loaded after babel. Any views?


One other thing. I propose to revert \nameref to \ref and \Nameref to 
\vref. I don't see any way to revert them to anything better without a 
lot of effort, and even then we couldn't do it in a generally reliable 
fashion without access to layout information, which we don't have in 
lyx2lyx.


Richard

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

[Joost Verburg]

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

[BH]

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
 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 cannot check Tiger
 support - I don't have it.

 Hmm, too bad. I am surprised though that there is not a simple
 explanation somewhere.

 I've searched another evening and couldn't find a solution or explanation.
 I'll give up for now. :(

 Regarding the Tiger support: the distribution candidate .dmg is now 39 MB big.
 If someone can test if the 10.5 SDK build with 10.4 deployment target is 
 working
 on Tiger I'll happily upload it for the test! Is anyone able to access a 
 Tiger system?

I don't have access to 10.4 anymore. Perhaps you should ask for a
volunteer on the user's list.

BH

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

[Uwe Stöhr]

 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 put it 
in.

regards Uwe

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

[Joost Verburg]

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 Stöhr]

 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

[Uwe Stöhr]

 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 don't know where to specify it.


 I've created up-to-date binaries of all the dependencies for MSVC 2010

Do they also work when using MSVC 2008?

The Ghostscript package is incomplete since the lib folder of the Ghostscript installation is 
missing. Without these files we cannot provide a full featured Ghostscript.


thanks and regards
Uwe

Bug #3221: nameref support

[Uwe Stöhr]

 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 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 button is not activated although you just have made a change.

Besides this, the 2 new styles don't appear in the reference context menu while 
all other styles do.

 One other thing. I propose to revert \nameref to \ref and \Nameref to \vref.
 I don't see any way to revert them to anything better without a lot of 
effort, and even then we
 couldn't do it in a generally reliable fashion without access to layout 
information, which we
 don't have in lyx2lyx.

I don't understand. Why is it not possible to revert them to ERT as I did e.g. for \makebox and flex 
insets?


---

As you are currently working on the reference code, can you please have a look 
at this bug:
http://www.lyx.org/trac/ticket/4595

regards Uwe

Re: LyX 1.6.7

[Joost Verburg]

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 dependencies for MSVC 2010

Do they also work when using MSVC 2008?


They should work, but you'll have to include the MSVC 2010 runtime. 
Unlike MSVC 2008 no manifest is required for that. Just put the DLL in 
the directory.



The Ghostscript package is incomplete since the lib folder of the
Ghostscript installation is missing. Without these files we cannot
provide a full featured Ghostscript.


All that is packaged inside Ghostscript! This improves performance and 
makes it easier to maintain.


Joost

Re: Bug #3221: nameref support

[Uwe Stöhr]

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 this code instead:

\...@ifundefined{vref}{\usepackage{varioref}}{}
\AtBeginDocument{
 \renewcommand*{\Nameref}[1]
   {\nameref{#1}~\reftextfaraway{#1}}
}


regards Uwe

Re: Bug #3221: nameref support

[Richard Heck]

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.

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 button is not activated although you just have made 
a change.


This appears to be the intended behavior, set by the disconnectOnApply() 
function in GuiRef.h. It was introduced at r2786, apparently.


Besides this, the 2 new styles don't appear in the reference context 
menu while all other styles do.



I'll fix that.

 One other thing. I propose to revert \nameref to \ref and \Nameref 
to \vref.
 I don't see any way to revert them to anything better without a lot 
of effort, and even then we
 couldn't do it in a generally reliable fashion without access to 
layout information, which we

 don't have in lyx2lyx.

I don't understand. Why is it not possible to revert them to ERT as I 
did e.g. for \makebox and flex insets?


It's a different problem. \nameref{mysec} prints the content of the 
\section command to which mysec is attached---or whatever sectioning 
command was active then, if one was. It would be a pain to try to figure 
out which section that was supposed to be, and it is impossible, in the 
general case, if we don't know what the sectioning commands are---which 
we don't if we don't have layout information. And then, even if we did 
know, we'd have to hardcode the name.


Richard

Re: Bug #3221: nameref support

[Richard Heck]

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.

This looks like a bug of sorts in nameref.sty. Shouldn't we instead try 
to get them to fix it? That's what I've usually been told when I run 
across this sort of thing.


Richard

Re: RefStyle, Again

[Jürgen Spitzmüller]

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 documents (or at least: 
the need to rewrite style files and such) is high.

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.

> Richard

Jürgen

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

[Jürgen Spitzmüller]

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; this is quite annoying.

Please consider to call this lyx_logo_vert.bmp once and for all.

Thanks,
Jürgen

> Modified:
>lyx-devel/branches/BRANCH_1_6_X/development/Makefile.am
> 
> Modified: lyx-devel/branches/BRANCH_1_6_X/development/Makefile.am
> ===
> === --- lyx-devel/branches/BRANCH_1_6_X/development/Makefile.am   Mon Jul 
> 12
> 07:17:40 2010 (r34865) +++
> lyx-devel/branches/BRANCH_1_6_X/development/Makefile.am   Mon Jul 12
> 10:17:13 2010 (r34866) @@ -91,7 +91,7 @@
>  Win32/packaging/AltInstaller/icons/lyx_32x32.ico \
>  Win32/packaging/AltInstaller/icons/lyx_doc.svg \
>  Win32/packaging/AltInstaller/icons/lyx_logo_hi.bmp \
> -Win32/packaging/AltInstaller/icons/lyx_logo_vert166.bmp \
> +Win32/packaging/AltInstaller/icons/lyx_logo_vert167.bmp \
>  Win32/packaging/AltInstaller/informations/InstallerStructure.odg \
>  Win32/packaging/AltInstaller/informations/InstallerStructure.pdf \
>  Win32/packaging/AltInstaller/informations/ISO_3166.html \

branch still frozen

[Jürgen Spitzmüller]

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

Jürgen

Re: LyX 1.6.7

[Jürgen Spitzmüller]

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 problems with msvc10 any more.

OK, thanks.

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 ?

Jürgen

Re: r34810 - lyx-devel/trunk/src

[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 use the
> new 10.6 features. When compiling with 10.5 SDK I cannot check Tiger
> support - I don't have it.

Hmm, too bad. I am surprised though that there is not a simple
explanation somewhere.

Anyway, I prefer your new code to the old one. I did not try it out yet
though.

JMarc

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

[Jean-Marc LASGOUTTES]

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 update them.

We could maybe extend InsetInfo to cover this in 2.0. Or is it already
the case?

JMarc

Re: LyX 1.6.7

[Enrico Forestieri]

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 had a workaround in trunk, which is now also in branch,
> > so now I have no problems with msvc10 any more.
> 
> OK, thanks.
> 
> 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 not added to src/support/Makefile.am at r34858.

-- 
Enrico

Re: LyX 1.6.7

[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 src/support/numpunct_lyx_char_type.h is missing from the
> tarball. It was not added to src/support/Makefile.am at r34858.

OK, thanks. Next try:

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

Jürgen

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

[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 lost somehow...
> 
> I see in the constructor SystemcallPrivate::SystemcallPrivate (SystemCall.cpp)
> the error output of the child process is collected only if it's going to an 
> terminal.
> I think it would be better to collect it unconditionally to show it in the 
> message window.
> What do others think?

whats the point of collecting it if we are not going to show it?
pavel

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

[Pavel Sanda]

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

[Pavel Sanda]

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 missing from the
> > tarball. It was not added to src/support/Makefile.am at r34858.
> 
> OK, thanks. Next try:
> 
> 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

builds fine on gentoo.
pavel

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

[Stephan Witt]

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 lost somehow...
>> 
>> I see in the constructor SystemcallPrivate::SystemcallPrivate 
>> (SystemCall.cpp)
>> the error output of the child process is collected only if it's going to an 
>> terminal.
>> I think it would be better to collect it unconditionally to show it in the 
>> message window.
>> What do others think?
> 
> whats the point of collecting it if we are not going to show it?

The point is that you can read it when looking for it in the message window.
That's currently not possible, the error messages are lost.

Here on Mac if I start LyX the stdin, stdout and stderr are redirected on 
startup.

If I remove the os::is_terminal(os::STDERR) test the output becomes visible.

Another story is to show the errors in the alert popup. This can be improved 
too.

Stephan

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

[Pavel Sanda]

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

[Pavel Sanda]

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

[Kornel Benko]

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	(Revision 34874)
+++ development/Makefile.am	(Arbeitskopie)
@@ -149,57 +149,57 @@
 scons/scons_manifest.py \
 scons/SConstruct \
 scons/scons_utils.py \
-cmake/build.bat \
-cmake/build-debug.bat \
-cmake/CMakeLists.txt \
-cmake/configCompiler.h.cmake \
-cmake/configCompiler.h.msvc \
-cmake/config.cpp.cmake \
-cmake/config.h.cmake \
-cmake/ConfigureChecks.cmake \
-cmake/Install.cmake \
-cmake/LyX_description.txt \
-cmake/LyX_license.txt \
-cmake/LyX_summary.txt \
-cmake/pcheaders.h \
-cmake/PyCompile.cmake \
-cmake/boost/CMakeLists.txt \
-cmake/boost/libs/CMakeLists.txt \
-cmake/boost/libs/regex/CMakeLists.txt \
-cmake/boost/libs/signals/CMakeLists.txt \
-cmake/doc/CMakeLists.txt \
-cmake/doc/ReplaceValues.pl \
-cmake/intl/CMakeLists.txt \
-cmake/intl/libgnuintl.h \
-cmake/lyx2lyx/CMakeLists.txt \
-cmake/man/CMakeLists.txt \
-cmake/modules/FindAiksaurusLIB.cmake \
-cmake/modules/FindASPELL.cmake \
-cmake/modules/FindGNUWIN32.cmake \
-cmake/modules/FindICONV.cmake \
-cmake/modules/FindLibintl.cmake \
-cmake/modules/FindLyXGettext.cmake \
-cmake/modules/FindMyThesLIB.cmake \
-cmake/modules/FindQt4.cmake \
-cmake/modules/FindZLIB.cmake \
-cmake/modules/LyXMacros.cmake \
-cmake/modules/LyXPaths.cmake \
-cmake/modules/LyXuic.cmake \
-cmake/modules/MacroBoolTo01.cmake \
-cmake/modules/PCHSupport_26.cmake \
-cmake/modules/ProjectSourceGroup.cmake \
-cmake/po/CMakeLists.txt \
-cmake/scripts/CMakeLists.txt \
-cmake/src/CMakeLists.txt \
-cmake/src/dummy.cpp \
-cmake/src/client/CMakeLists.txt \
-cmake/src/frontends/CMakeLists.txt \
-cmake/src/frontends/qt4/CMakeLists.txt \
-cmake/src/graphics/CMakeLists.txt \
-cmake/src/insets/CMakeLists.txt \
-cmake/src/mathed/CMakeLists.txt \
-cmake/src/support/CMakeLists.txt \
-cmake/src/tex2lyx/CMakeLists.txt
-
-# cmake file list generated and sorted by 'ls -Ra'
+cmake/CMakeLists.txt /
+cmake/ConfigureChecks.cmake /
+cmake/Install.cmake /
+cmake/LyX_description.txt /
+cmake/LyX_license.txt /
+cmake/LyX_summary.txt /
+cmake/PyCompile.cmake /
+cmake/build-debug.bat /
+cmake/build.bat /
+cmake/config.cpp.cmake /
+cmake/config.h.cmake /
+cmake/configCompiler.h.cmake /
+cmake/configCompiler.h.msvc /
+cmake/lyx.rc /
+cmake/pcheaders.h /
+cmake/boost/CMakeLists.txt /
+cmake/doc/CMakeLists.txt /
+cmake/doc/ReplaceValues.pl /
+cmake/intl/CMakeLists.txt /
+cmake/intl/libgnuintl.h /
+cmake/lyx2lyx/CMakeLists.txt /
+cmake/man/CMakeLists.txt /
+cmake/modules/FindASPELL.cmake /
+cmake/modules/FindAiksaurusLIB.cmake /
+cmake/modules/FindGNUWIN32.cmake /
+cmake/modules/FindICONV.cmake /
+cmake/modules/FindLibintl.cmake /
+cmake/modules/FindLyXGettext.cmake /
+cmake/modules/FindMyThesLIB.cmake /
+cmake/modules/FindQt4.cmake /
+cmake/modules/FindZLIB.cmake /
+cmake/modules/LyXMacros.cmake /
+cmake/modules/LyXPaths.cmake /
+cmake/modules/LyXuic.cmake /
+cmake/modules/MacroBoolTo01.cmake /
+cmake/modules/PCHSupport_26.cmake /
+cmake/modules/ProjectSourceGroup.cmake /
+cmake/po/CMakeLists.txt /
+cmake/po/cat.py /
+cmake/scripts/CMakeLists.txt /
+cmake/src/CMakeLists.txt /
+cmake/src/dummy.cpp /
+cmake/boost/libs/CMakeLists.txt /
+cmake/src/client/CMakeLists.txt /
+cmake/src/frontends/CMakeLists.txt /
+cmake/src/graphics/CMakeLists.txt /
+cmake/src/insets/CMakeLists.txt /
+cmake/src/mathed/CMakeLists.txt /
+cmake/src/support/CMakeLists.txt /
+cmake/src/tex2lyx/CMakeLists.txt /
+cmake/boost/libs/regex/CMakeLists.txt /
+cmake/boost/libs/signals/CMakeLists.txt /
+cmake/src/frontends/qt4/CMakeLists.txt
 


signature.asc
Description: This is a digitally signed message part.

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

[Jürgen Spitzmüller]

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

[Jürgen Spitzmüller]

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

[Richard Heck]

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 and they can
have wrong values if one forgets to update them.
 

We could maybe extend InsetInfo to cover this in 2.0. Or is it already
the case?

   

What is it that we want?

rh

Re: Lyxserver - citation-insert

[Pavel Sanda]

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. \citet. It works as expected from the mini-buffer, i.e.
> inserting (Author, year), \citep.
> Am I missing something or is that a Lyx bug?

what steps should i do to reproduce? minibufer and direct lyxserver 
comunnication
seems to be identical here (and should be).

pavel

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

[Peter Kümmel]

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 line typing 0 or 1 is simpler.

> 
> 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)
>   Kornel

The idea was to cleanup the variable list in cmake-gui.
Found libraries always have their own scope and _ is
not a scope. We set this two variables in our scripts
so wy not prefix them with LYX_?

Peter

Re: LyX 1.6.7

[Peter Kümmel]

 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/
> ftp://ftp.devel.lyx.org/pub/contrib/windows/branch16/
> This includes gettext 0.18 and iconv 1.13.1.
> Perhaps you could use these as well when you upgrade to 2010?
> 
> 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. So creating a new installer for 2.0 should be 
> much more simple! We should talk about this sometime.
> 

Very good!

What was the plan for 2.0?

Peter

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

[Jean-Marc LASGOUTTES]

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 information that we had to update after each major release,
and personally I am not sure that the machinery is worth keeping. Other
parts are done transparently through autoconf, but the documentation
cannot be updated like that.

JMarc

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

[Kornel Benko]

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)
> > 
> > Kornel
> 
> The idea was to cleanup the variable list in cmake-gui.

But this two are not yet found in the gui ...

Instead there are:
GETTEXT_*_EXECUTABLE (MSGFMT, MSGMERGE, MSGUNIQ,XGETTEXT)
_PYTHON_EXECUTABE
PYTHON_EXECUTABLE
_PERL_EXECUTABLE
QT_*_EXECUTABLE (MOC, QMAKE, RCC, UIC3, UIC)

> Found libraries always have their own scope and _ is
> not a scope. We set this two variables in our scripts
> so wy not prefix them with LYX_?
> 
> Peter

Kornel


signature.asc
Description: This is a digitally signed message part.

Dependency Problem?

[Richard Heck]

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


rh

"Unavailable" Classes

[Richard Heck]

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" classes separately at the end. That makes them harder to 
find, in a way.


One idea is to mark such classes with an asterisk, as in the attached 
patch and screenshot. Comments? Other ideas?


Richard





one change that
LyX developers might consider is to issue a warning message and make
the document class available to the user even if the classes in square
brackets are not installed.

I thought we did that already...


The problem here may be what you see in the dropdown box, e.g.:
Unavailable: article (REVTeX)
That makes it look as if you can't use it, because it is 
"Unavailable". But I'm not sure what a better term would be. There 
are improvements in 2.0, too. If you select such a class, then LyX 
will tell you precisely what prerequisites are not satisfied.


Maybe "limited availability" or even "lacks some packages" would be 
more on point than "Unavailable". What threw me was the fact that the 
unavailable classes are listed separately. Personally, I'd prefer 
colors or font shapes and weights: green (bold) = ready to go, yellow 
(plain text) = lacking some packages, and red (italic) = cannot process.




<>

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

[Peter Kuemmel]

 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:
> ...
> > Yes, but when using the command line typing 0 or 1 is simpler.
> 
> Not nice, but ok ...

We simply add both comments.

> 
> > > 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)
> > > 
> > >   Kornel
> > 
> > The idea was to cleanup the variable list in cmake-gui.

Too be more precise I wanna remove the "Ungrouped Entries" group.

> 
> But this two are not yet found in the gui ...
> 
> Instead there are:
> GETTEXT_*_EXECUTABLE (MSGFMT, MSGMERGE, MSGUNIQ,XGETTEXT)
> _PYTHON_EXECUTABE

Have you removed the cache/cleaned the build dir before running cmake again?

> PYTHON_EXECUTABLE
> _PERL_EXECUTABLE
> QT_*_EXECUTABLE (MOC, QMAKE, RCC, UIC3, UIC)
> 

With attached patch there are no ungrouped entries any more an
Linux.

Peter

-- 
GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl.  
Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl
Index: PyCompile.cmake
===
--- PyCompile.cmake	(Revision 34881)
+++ PyCompile.cmake	(Arbeitskopie)
@@ -9,14 +9,14 @@
 #		#include(../PyCompile)
 project(${_project})
 
-include(FindPythonInterp)
+FIND_PROGRAM(LYX_PYTHON_EXECUTABLE python)
 
 file(GLOB _py_files ${TOP_SRC_DIR}/lib/${_project}/*.py)
 
 set(py_compile ${TOP_SRC_DIR}/config/py-compile)
 
 set(_generated)
-set(ENV{PYTHON} ${PYTHON_EXECUTABLE})
+set(ENV{PYTHON} ${LYX_PYTHON_EXECUTABLE})
 
 foreach(_orig_py ${_py_files})
   get_filename_component(_base_we_py ${_orig_py} NAME_WE)
Index: modules/FindLibintl.cmake
===
--- modules/FindLibintl.cmake	(Revision 34881)
+++ modules/FindLibintl.cmake	(Arbeitskopie)
@@ -40,7 +40,6 @@
 
 endif(LIBINTL_INCLUDE_DIR)
 
-#include(FindPackageHandleStandardArgs)
-#find_package_handle_standard_args(Libintl  DEFAULT_MSG  LIBINTL_INCLUDE_DIR  LIBINTL_LIB_FOUND)
+set(LIBINTL_LIBRARIES ${LIBINTL_LIBRARIES} CACHE STRING "linintl libs" FORCE)
 
 mark_as_advanced(LIBINTL_INCLUDE_DIR  LIBINTL_LIBRARIES  LIBINTL_LIBC_HAS_DGETTEXT  LIBINTL_LIB_FOUND)

Re: r34810 - lyx-devel/trunk/src

[Stephan Witt]

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 use the
>> new 10.6 features. When compiling with 10.5 SDK I cannot check Tiger
>> support - I don't have it.
> 
> Hmm, too bad. I am surprised though that there is not a simple
> explanation somewhere.

I've searched another evening and couldn't find a solution or explanation.
I'll give up for now. :(

Regarding the Tiger support: the distribution candidate .dmg is now 39 MB big.
If someone can test if the 10.5 SDK build with 10.4 deployment target is working
on Tiger I'll happily upload it for the test! Is anyone able to access a Tiger 
system?

> Anyway, I prefer your new code to the old one. I did not try it out yet
> though.

Thanks.

Stephan

Copy and Paste in Multi-File Documents

[Rainer Dorsch]

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 information was 
lost, even the Section numbering was "hardcoded" (and wrong) after pasting.

Then I did the same within the same document. Worked flawless. Then I tried to 
paste it again to the other document, this time it worked (!). I can imagine 
situations where either behavior makes sense. Can I deterministically choose 
between them?

Also in the navigator I cannot move a section from one file to another, but I 
can move it within a file. Is it worth to open a bug report for that?

Thanks,
Rainer


-- 
Rainer Dorsch
Lärchenstr. 6
D-72135 Dettenhausen
07157-734133
email: rdor...@web.de
jabber: rdor...@jabber.org
GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F  8F59 E3A8 C538 7519 141E
Full GPG key: http://pgp.mit.edu/


signature.asc
Description: This is a digitally signed message part.

Re: Dependency Problem?

[Vincent van Ravesteijn]

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?

[Richard Heck]

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

[Richard Heck]

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 master document). When copying all the formating information was
lost, even the Section numbering was "hardcoded" (and wrong) after pasting.

Then I did the same within the same document. Worked flawless. Then I tried to
paste it again to the other document, this time it worked (!). I can imagine
situations where either behavior makes sense. Can I deterministically choose
between them?

   
Can you reproduce the unexpected behavior reliably? If so, please give 
us a recipe. That's not at all what is intended, I don't think.



Also in the navigator I cannot move a section from one file to another, but I
can move it within a file. Is it worth to open a bug report for that?

   

Yes. I'm not sure how easy that will be to fix.

rh

Bug #3221: nameref support

[Richard Heck]

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 nameref should be loaded after babel. Any views?


rh

Index: lib/lyx2lyx/lyx_2_0.py
===
--- lib/lyx2lyx/lyx_2_0.py	(revision 34853)
+++ lib/lyx2lyx/lyx_2_0.py	(working copy)
@@ -1931,6 +1931,42 @@
   del document.body[i:j + 1]
 
 
+def revert_nameref(document):
+  " Convert namerefs to regular references "
+  # We cannot really revert these properly, so we will
+  # revert them to commands we understand.
+  cmds = [["Nameref", "vref"], ["nameref", "ref"]]
+  for cmd in cmds:
+i = 0
+oldcmd = "LatexCommand " + cmd[0]
+newcmd = "LatexCommand " + cmd[1]
+while 1:
+  i = find_token(document.body, oldcmd, i)
+  if i == -1:
+break
+  # Make sure it is actually in an inset!
+  # We could just check document.lines[i-1], but that relies
+  # upon something that might easily change.
+  # We'll look back a few lines.
+  j = i - 10
+  if j < 0:
+j = 0
+  j = find_token(document.body, "\\begin_inset CommandInset ref", j)
+  if j == -1 or j > i:
+i += 1
+continue
+  k = find_end_of_inset(document.body, i)
+  if k == -1:
+document.warning("Can't find end of inset at line " + j + "!!")
+i += 1
+continue
+  if k < i:
+i += 1
+continue
+  document.body[i] = newcmd
+  i += 1
+
+
 ##
 # Conversion hub
 #
@@ -1984,10 +2020,12 @@
[391, []],
[392, [convert_beamer_args]],
[393, [convert_optarg]],
-   [394, []]
+   [394, []],
+   [395, []]
   ]
 
-revert =  [[393, [revert_makebox]],
+revert =  [[394, [revert_nameref]],
+   [393, [revert_makebox]],
[392, [revert_argument]],
[391, [revert_beamer_args]],
[390, [revert_align_decimal, revert_IEEEtran]],
Index: src/Buffer.cpp
===
--- src/Buffer.cpp	(revision 34853)
+++ src/Buffer.cpp	(working copy)
@@ -126,7 +126,7 @@
 
 // Do not remove the comment below, so we get merge conflict in
 // independent branches. Instead add your own.
-int const LYX_FORMAT = 394; // uwestoehr: support for \makebox
+int const LYX_FORMAT = 395; // rgh: nameref
 
 typedef map DepClean;
 typedef map RefCache;
Index: src/BufferParams.cpp
===
--- src/BufferParams.cpp	(revision 34881)
+++ src/BufferParams.cpp	(working copy)
@@ -1732,7 +1732,9 @@
 		texrow.newlines(lines);
 		// set back for the rest
 		lyxpreamble.clear();
-	}
+	} else if (features.isRequired("nameref"))
+		// hyperref loads this automatically
+		lyxpreamble += "\\usepackage{nameref}\n";
 
 	// Will be surrounded by \makeatletter and \makeatother when not empty
 	docstring atlyxpreamble;
Index: src/frontends/qt4/ui/RefUi.ui
===
--- src/frontends/qt4/ui/RefUi.ui	(revision 34853)
+++ src/frontends/qt4/ui/RefUi.ui	(working copy)
@@ -1,105 +1,103 @@
-
+
  RefUi
- 
-  
+ 
+  

 0
 0
-386
+435
 443

   
-  
+  

   
-  
+  
true
   
-  
-   
+  
+   
 9

-   
+   
 6

-   
-
- 
+   
+
+ 
+  6
+ 
+ 
   0
  
- 
-  6
- 
  
-  
-   
+  
+   
 Filter:

-   
+   
 Qt::AlignLeading|Qt::AlignLeft|Qt::AlignVCenter

-   
+   
 findLE

   
  
  
-  
-   
+  
+   
 Enter string to filter the label list

-   
+   
 

   
  
  
-  
-   
+  
+   
 Filter case-sensitively

-   
+   
 Case-sensitive

   
  
 

-   
-
- 
+   
+
+ 
+  6
+ 
+ 
   0
  
- 
-  6
- 
  
-  
-   
-
- 3
- 0
+  
+   
+
  0
  0
 

-   
+   
 Update the label list

-   
+   
 Update

   
  
  
   
-   
+   
 Qt::Horizontal

-   
+   
 QSizePolicy::Expanding

-   
+   
 
  31
  30
@@ -108,88 +106,88 @@
   
  
  
-  
-   
+  
+   
 OK

-   
+   
 true

-   
+   
 true

   
  
  
-  
-   
+  
+   
 Apply

-   
+   
 

Re: Bug #3221: nameref support

[Richard Heck]

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 nameref. But if we aren't, then 
maybe nameref should be loaded after babel. Any views?


One other thing. I propose to revert \nameref to \ref and \Nameref to 
\vref. I don't see any way to revert them to anything better without a 
lot of effort, and even then we couldn't do it in a generally reliable 
fashion without access to layout information, which we don't have in 
lyx2lyx.


Richard

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

[Joost Verburg]

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

[BH]

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 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 cannot check Tiger
>>> support - I don't have it.
>>
>> Hmm, too bad. I am surprised though that there is not a simple
>> explanation somewhere.
>
> I've searched another evening and couldn't find a solution or explanation.
> I'll give up for now. :(
>
> Regarding the Tiger support: the distribution candidate .dmg is now 39 MB big.
> If someone can test if the 10.5 SDK build with 10.4 deployment target is 
> working
> on Tiger I'll happily upload it for the test! Is anyone able to access a 
> Tiger system?

I don't have access to 10.4 anymore. Perhaps you should ask for a
volunteer on the user's list.

BH

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

[Uwe Stöhr]

> 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 put it 
in.

regards Uwe

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

[Joost Verburg]

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 Stöhr]

> 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

[Uwe Stöhr]

> 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 don't know where to specify it.


> I've created up-to-date binaries of all the dependencies for MSVC 2010

Do they also work when using MSVC 2008?

The Ghostscript package is incomplete since the "lib" folder of the Ghostscript installation is 
missing. Without these files we cannot provide a full featured Ghostscript.


thanks and regards
Uwe

Bug #3221: nameref support

[Uwe Stöhr]

> 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 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 button is not activated although you just have made a change.

Besides this, the 2 new styles don't appear in the reference context menu while 
all other styles do.

> One other thing. I propose to revert \nameref to \ref and \Nameref to \vref.
> I don't see any way to revert them to anything better without a lot of 
effort, and even then we
> couldn't do it in a generally reliable fashion without access to layout 
information, which we
> don't have in lyx2lyx.

I don't understand. Why is it not possible to revert them to ERT as I did e.g. for \makebox and flex 
insets?


---

As you are currently working on the reference code, can you please have a look 
at this bug:
http://www.lyx.org/trac/ticket/4595

regards Uwe

Re: LyX 1.6.7

[Joost Verburg]

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 dependencies for MSVC 2010

Do they also work when using MSVC 2008?


They should work, but you'll have to include the MSVC 2010 runtime. 
Unlike MSVC 2008 no manifest is required for that. Just put the DLL in 
the directory.



The Ghostscript package is incomplete since the "lib" folder of the
Ghostscript installation is missing. Without these files we cannot
provide a full featured Ghostscript.


All that is packaged inside Ghostscript! This improves performance and 
makes it easier to maintain.


Joost

Re: Bug #3221: nameref support

[Uwe Stöhr]

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 this code instead:

\...@ifundefined{vref}{\usepackage{varioref}}{}
\AtBeginDocument{
 \renewcommand*{\Nameref}[1]
   {\nameref{#1}~\reftextfaraway{#1}}
}


regards Uwe

Re: Bug #3221: nameref support

[Richard Heck]

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.

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 button is not activated although you just have made 
a change.


This appears to be the intended behavior, set by the disconnectOnApply() 
function in GuiRef.h. It was introduced at r2786, apparently.


Besides this, the 2 new styles don't appear in the reference context 
menu while all other styles do.



I'll fix that.

> One other thing. I propose to revert \nameref to \ref and \Nameref 
to \vref.
> I don't see any way to revert them to anything better without a lot 
of effort, and even then we
> couldn't do it in a generally reliable fashion without access to 
layout information, which we

> don't have in lyx2lyx.

I don't understand. Why is it not possible to revert them to ERT as I 
did e.g. for \makebox and flex insets?


It's a different problem. \nameref{mysec} prints the content of the 
\section command to which mysec is attached---or whatever sectioning 
command was active then, if one was. It would be a pain to try to figure 
out which section that was supposed to be, and it is impossible, in the 
general case, if we don't know what the sectioning commands are---which 
we don't if we don't have layout information. And then, even if we did 
know, we'd have to hardcode the name.


Richard

Re: Bug #3221: nameref support

[Richard Heck]

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".

This looks like a bug of sorts in nameref.sty. Shouldn't we instead try 
to get them to fix it? That's what I've usually been told when I run 
across this sort of thing.


Richard