Peter Kümmel wrote:
> Peter Kümmel wrote:
>> But there are other ones: the po file geneartion does not
>> work, haven't we replaced the perl scripts?
>>
>> I'm looking at this, but I'm no python scriper.
>
> here the error:
> Traceback (most recent call last):
> File "C:/work/sandbox/lyx/lyx
Peter Kümmel wrote:
> But there are other ones: the po file geneartion does not
> work, haven't we replaced the perl scripts?
>
> I'm looking at this, but I'm no python scriper.
here the error:
Traceback (most recent call last):
File "C:/work/sandbox/lyx/lyx-1.6.7/po/lyx_pot.py", line 352,
Joost Verburg wrote:
> On 7/12/2010 8:47 PM, Joost Verburg wrote:
>> Trying SCons now.
>
> Also doesn't work.
>
> src\frontends\qt4\GuiCommandBuffer.cpp(319) : error C2668:
> 'lyx::copy_if' : ambiguous call to overloaded function
>
I've now problems here with this file.
'lyx::copy_if' in line
Richard Heck wrote:
> One idea is to mark such classes with an asterisk, as in the attached
> patch and screenshot. Comments? Other ideas?
I think we had an asterisk at first and then changed it to the current text,
because people found the asterisk not informative enough.
If you go for he aste
Joost Verburg wrote:
> > Trying SCons now.
>
> Also doesn't work.
>
> src\frontends\qt4\GuiCommandBuffer.cpp(319) : error C2668:
> 'lyx::copy_if' : ambiguous call to overloaded function
And this is only with msvc10? How about using the previous version once more?
Jürgen
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 p
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.
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 pro
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 dependenc
> 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 f
> 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
> 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
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
> 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 p
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 b
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
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 n
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
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 maste
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
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
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
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
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, b
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"
Changing LaTeXUi.ui causes recompilation of GuiBranch.o and
GuiIndices.o. Is that right?
rh
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)
> >
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 t
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/contri
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
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),
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 w
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
Kornel Benko wrote:
> Some cmake-files are missing in development/Makefile.am.
*Sigh*
Put it in, please.
Jürgen
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 (Revisi
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
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
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 alread
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
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
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 c
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
> tar
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
> >
> >
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 coul
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 Tig
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
Please no commits to branch whatsoever without discussion on this list.
Jürgen
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 s
48 matches
Mail list logo
