On Fri, May 06, 2011 at 06:07:13PM -0400, Richard Heck wrote:
> Anyway, I'd very much value your opinion on the patch itself. I do not
> know the math code well.
I think you are right and your patch does what is needed to avoid the bug.
I don't know the macro code well enough to say whether there
On 05/06/2011 05:34 PM, Enrico Forestieri wrote:
> On Fri, May 06, 2011 at 08:20:31AM -0400, Richard Heck wrote:
>
>> The reason this is not a problem in the UI is that the metrics
>> calculation does recurse this way. This helps to hide the bug when
>> EXPORT_IN_THREAD is disabled and is why I tho
Le 06/05/2011 21:18, Guenter Milde a écrit :
I am sure Qt gives us this information. We should react to OS-level
language change. This is probably trivial.
There are some tricky points: the OS typically switches keyboard
layout, but the mapping of keyboard-layout to intended document
language i
On Fri, May 06, 2011 at 08:20:31AM -0400, Richard Heck wrote:
> The reason this is not a problem in the UI is that the metrics
> calculation does recurse this way. This helps to hide the bug when
> EXPORT_IN_THREAD is disabled and is why I thought this worked.
One can play with words, but... this
Le 06/05/2011 21:18, Kornel a écrit :
> +#cmakedefine LYX_EXTERNAL_LIBINTL 1
> for my enlightment, what does this do?
Defines the macro LYX_EXTERNAL_LIBINTL according to the cmake value
${LYX_EXTERNAL_LIBINTL}
This means
if ${LYX_EXTERNAL_LIBINTL}
==> #define LYX_EXTERNAL_LIBINTL 1
else
On Fri, May 6, 2011 at 9:57 PM, Neal Becker wrote:
> No File > Import > Gnumeric here (fedora 14 lyx-2.0.0-0.21.rc3.fc14.x86_64)
>
> What am I missing?
>
Maybe Gnumeric. And perhaps LyX 2.0.
Liviu
On Fri, May 6, 2011 at 9:11 PM, Gerhardus Geldenhuis
wrote:
> Hi
> I just wanted to write a quick thank you to all of the developers for
> getting Lyx where it is. I recently made the decision to ditch word
> in favor of Lyx as I am starting to write more serious scientific documents
> and I have
Liviu Andronic wrote:
> On Wed, May 4, 2011 at 11:01 AM, Andrew Parsloe wrote:
>> The current lack of even a basic 'active' table in LyX, where you can sum a
>> column of figures for instance,
>>
> This is not accurate. In 2.0 you can:
> File > Import > Table (CSV)
> File > Import > xls
> File >
On Wed, May 4, 2011 at 10:48 PM, Rob Oakes wrote:
> But, in LyX's defense, it's a very complicated book and the export time is
> pretty comparable to what I'd get in InDesign or Scribus. LyX is far
> superior, though, because this book would be prohibitively difficult in
> either program. (Prob
On Fri, May 06, 2011 at 07:33:35PM +, Guenter Milde wrote:
> On 2011-05-06, venom00 wrote:
> >> >> Lua
> >> >>+ small and fast,
> >> >>+ used in LuaTeX, so it will become more common and known in the
> >> >> TeX community,
> >> >>+ a Lua interpreter can be embedded in LyX with
On 2011-05-06, venom00 wrote:
>> >> Lua
>> >>+ small and fast,
>> >>+ used in LuaTeX, so it will become more common and known in the
>> >> TeX community,
>> >>+ a Lua interpreter can be embedded in LyX with minimal
>> impact on
>> >> the binary size.
>> > Wasn't there anothe
Am Freitag, 6. Mai 2011 schrieb Jean-Marc Lasgouttes:
> Le 06/05/2011 18:29, Kornel a écrit :
> > Thanks Jean-Marc. Will check now, if the defines in config.h.cmake don't
> > break
> > Lyx behaves ok ...
> >
> > Ataching the patch.
>
> Go ahead if it works.
>
> Small nit:
>
> +#cmakedefine LY
On 2011-05-06, Jean-Marc Lasgouttes wrote:
> Le 06/05/11 17:23, Richman Reuven a écrit :
>> * recognizing the os-es language change, i'm not sure how it works for
>> other languages but a common solution for english/hebrew switching is
>> using f12, i always wonder why? ^_^*
> I am sure Qt gives u
Hi
I just wanted to write a quick thank you to all of the developers for
getting Lyx where it is. I recently made the decision to ditch word
in favor of Lyx as I am starting to write more serious scientific documents
and I have not looked back. Lyx is awesome and although the learning curve
is stee
Am 06.05.2011 um 20:04 schrieb Jean-Marc Lasgouttes:
> Le 06/05/2011 18:29, Kornel a écrit :
>> Thanks Jean-Marc. Will check now, if the defines in config.h.cmake don't
>> break
>> Lyx behaves ok ...
>>
>> Ataching the patch.
>
> Go ahead if it works.
I tried it and it compiles and LyX starts.
Le 06/05/2011 18:29, Kornel a écrit :
Thanks Jean-Marc. Will check now, if the defines in config.h.cmake don't
break
Lyx behaves ok ...
Ataching the patch.
Go ahead if it works.
Small nit:
+#cmakedefine LYX_EXTERNAL_LIBINTL 1
for my enlightment, what does this do?
+#if !defined(LYX_EXTERN
Am Freitag, 6. Mai 2011 schrieb Jean-Marc Lasgouttes:
> Le 06/05/11 17:50, Kornel a écrit :
> > But it is your work. It would be disingenuous.
> >
> > I will prepare a patch, but you should commit.
>
> Seriously, it is more important for me to have all the cmake code
> passing through your hands.
Le 06/05/11 17:50, Kornel a écrit :
But it is your work. It would be disingenuous.
I will prepare a patch, but you should commit.
Seriously, it is more important for me to have all the cmake code
passing through your hands.
JMarc
Am Freitag, 6. Mai 2011 schrieb Jean-Marc Lasgouttes:
> Le 05/05/11 17:19, Kornel a écrit :
> > You did. Sorry. Compiling now.
> >
> > Ok, two glitches ...
>
> Feel free to commit it once/if you are satisfied by it.
>
> JMarc
But it is your work. It would be disingenuous.
I will prepare a p
Le 06/05/11 17:23, Richman Reuven a écrit :
* recognizing the os-es language change, i'm not sure how it works for
other languages but a common solution for english/hebrew switching is
using f12, i always wonder why? ^_^*
I am sure Qt gives us this information. We should react to OS-level
lang
On Wed, 2011-05-04 at 00:50 +0200, Vincent van Ravesteijn wrote:
> Hi everyone,
>
> As a typical start of a new release cycle I want to poll
> - what features are a must in the next release;
> - what work do you think you will be doing;
> - what do you hope to see somebody else to do (please ke
On 05/06/2011 10:46 AM, Jean-Marc Lasgouttes wrote:
Le 05/05/11 11:21, Guenter Milde a écrit :
When compiling with XeTeX, use a two-step approach:
1. generate XDV (extended DVI) output rather than PDF
(xelatex -no-pdf) until there is no need to re-run.
2. convert the XDV file to PDF (xdvip
Le 05/05/11 11:21, Guenter Milde a écrit :
When compiling with XeTeX, use a two-step approach:
1. generate XDV (extended DVI) output rather than PDF
(xelatex -no-pdf) until there is no need to re-run.
2. convert the XDV file to PDF (xdvipdfmx)
This way, the XDV->PDF conversion will not be
- Original Message -
> From: Tommaso Cucinotta
> More concretely, for collaboration purposes I would propose to add a
> relatively
> simple missing feature, which is a good history browser.
> For example, it could be docked panel that shows up on the left, where you
> can
> see all th
Le 05/05/11 17:19, Kornel a écrit :
You did. Sorry. Compiling now.
Ok, two glitches ...
Feel free to commit it once/if you are satisfied by it.
JMarc
- Original Message -
> From: Tommaso Cucinotta
> So, why having a git-based file format ?
I was under the impressions that the point of a taped or zip format was that
all relevant files bibliography, graphics, and lyx file would be committed/
pushed at once via the LyX interface. Mayb
BH wrote:
> I've put LyX-1.6.10-Mac-Universal.dmg here:
>
> https://edisk.fandm.edu/bennett.helm/lyx/LyX-1.6.10-Mac-Universal.dmg
Got it!
> Thanks, Jürgen, for all your hard work.
Thanks to you!
Jürgen
On Fri, May 6, 2011 at 4:30 AM, Jürgen Spitzmüller wrote:
> I've uploaded the tarballs here:
>
> ftp://ftp.devel.lyx.org/pub/lyx/stable/lyx-1.6.10.tar.bz2
> ftp://ftp.devel.lyx.org/pub/lyx/stable/lyx-1.6.10.tar.gz
>
> Please test. I will wait with the announcement for the 2.0 announcement and
> fo
Il 06/05/2011 14:50, Tommaso Cucinotta ha scritto:
So, why having a git-based file format ?
More concretely, for collaboration purposes I would propose to add a
relatively simple missing feature, which is a good history browser.
For example, it could be docked panel that shows up on the left,
Il 06/05/2011 12:12, Sam Lewis ha scritto:
- Original Message -
From: Abdelrazak Younes
But my vision is going much farther than just a file to be interchanged. At the
end, we could very well work from within LyX without sending anything, LyX would
take care of cloning, pushing and pull
The attached patch addresses a bug that surfaced first with XHTML
export, but I suspect there are other versions of the bug.
Open the test file attached. Note that the macro \testt is defined in
terms of \test. View XHTML. Then we generate an image for the first
formula. The reason is that export
- Original Message -
> From: Abdelrazak Younes
> But my vision is going much farther than just a file to be interchanged. At
> the
> end, we could very well work from within LyX without sending anything, LyX
> would
> take care of cloning, pushing and pulling, etc. People would then b
> >> Lua
> >>+ small and fast,
> >>+ used in LuaTeX, so it will become more common and known in the
> >> TeX community,
> >>+ a Lua interpreter can be embedded in LyX with minimal
> impact on
> >> the binary size.
>
> > Wasn't there another thread with the result that LyX is
Kornel wrote:
> Nonetheless I don't like messed source, but I like at the same time
> to have remerged files which I can edit. They are there witch correct marked
> source lines.
> I use this info to resolve the meaning of some strings.
>
> And comparing some po-files (de sk cz pl) is easier, sin
Abdelrazak Younes wrote:
> On 06/05/2011 12:15, Jean-Marc Lasgouttes wrote:
>> Le 06/05/2011 12:10, Jean-Marc Lasgouttes a écrit :
>>> PS: I am not specially trying to kill cmake, but presenting it as a
>>> solution to all problems is not helpful.
>>
>> To be more precise: I am against saying "let'
Le 06/05/2011 11:58, Abdelrazak Younes a écrit :
So much for cmake native support.
Xcode is using gcc AFAIK...
CMake can generate either XCode project or plain Makefile. Both are
native to Mac AFAIK.
QtCreator on Mac is native. It use the Makefile generator of CMake.
Make that "so much for a
On 2011-05-05, Peter Kümmel wrote:
> On 05.05.2011 10:28, Guenter Milde wrote:
>> As language I'd use one of:
>> Lua
>>+ small and fast,
>>+ used in LuaTeX, so it will become more common and known in the
>> TeX community,
>>+ a Lua interpreter can be embedded in LyX with minimal
Am 06.05.2011 um 12:18 schrieb Abdelrazak Younes:
> On 06/05/2011 12:15, Jean-Marc Lasgouttes wrote:
>> Le 06/05/2011 12:10, Jean-Marc Lasgouttes a écrit :
>>> PS: I am not specially trying to kill cmake, but presenting it as a
>>> solution to all problems is not helpful.
>>
>> To be more precise
Am 06.05.2011 um 10:30 schrieb Jürgen Spitzmüller:
> I've uploaded the tarballs here:
>
> ftp://ftp.devel.lyx.org/pub/lyx/stable/lyx-1.6.10.tar.bz2
> ftp://ftp.devel.lyx.org/pub/lyx/stable/lyx-1.6.10.tar.gz
>
> Please test. I will wait with the announcement for the 2.0 announcement and
> for bi
> I tried XCode a bit and, for LyX, I think QtCreator is much
> much better,
> that's all. For Mac specific development XCode is probably better.
The same with Visual Studio under Windows.
venom00
On 06/05/2011 12:15, Jean-Marc Lasgouttes wrote:
Le 06/05/2011 12:10, Jean-Marc Lasgouttes a écrit :
PS: I am not specially trying to kill cmake, but presenting it as a
solution to all problems is not helpful.
To be more precise: I am against saying "let's drop autotools cmake is
so much bett
On 06/05/2011 12:10, Jean-Marc Lasgouttes wrote:
Le 06/05/2011 11:58, Abdelrazak Younes a écrit :
So much for cmake native support.
Xcode is using gcc AFAIK...
CMake can generate either XCode project or plain Makefile. Both are
native to Mac AFAIK.
QtCreator on Mac is native. It use the Makefi
Le 06/05/2011 12:10, Jean-Marc Lasgouttes a écrit :
PS: I am not specially trying to kill cmake, but presenting it as a
solution to all problems is not helpful.
To be more precise: I am against saying "let's drop autotools cmake is
so much better". Now, if we manage to give cmake the polish it
Am Freitag, 6. Mai 2011 schrieb Jean-Marc Lasgouttes:
> 4/ on Friday, I can blame whoever I want!
>
> JMarc
I forgot ...
Kornel
signature.asc
Description: This is a digitally signed message part.
On 06/05/2011 11:09, Jean-Marc Lasgouttes wrote:
Le 06/05/2011 10:36, Abdelrazak Younes a écrit :
The solution would be to create the XCode project with the -sysdir
arguments at first.
Then the copy wouldn't be necessary. Or any other idea would be fine.
Unfortunately cmake recreates the XCode p
Le 06/05/2011 11:20, Kornel a écrit :
> >> Unfortunately cmake recreates the XCode projects from scratch every
> >> time, AFAIK.
> > Then use QtCreator ;-)
> So much for cmake native support.
Sorry Jean-Marc,
to run lyx in place was done in source code for autotools only. Please
don't
Am 06.05.2011 um 11:21 schrieb Kornel:
> Am Freitag, 6. Mai 2011 schrieb Jean-Marc Lasgouttes:
> > Le 06/05/2011 08:24, Stephan Witt a écrit :
> > >> * Run in place, without using LYX_DIR_20x
> > >>
> > > copy the resources (bind/ ui/ layouts/ dicts/ thes/ ...) to the build
> > > stage (?
Am Freitag, 6. Mai 2011 schrieb Jean-Marc Lasgouttes:
> Le 06/05/2011 08:24, Stephan Witt a écrit :
> >> * Run in place, without using LYX_DIR_20x
> >>
> > copy the resources (bind/ ui/ layouts/ dicts/ thes/ ...) to the build
> > stage (?) This is what I do: copy them from an autotools ins
Am Freitag, 6. Mai 2011 schrieb Jean-Marc Lasgouttes:
> Le 06/05/2011 10:36, Abdelrazak Younes a écrit :
> >> The solution would be to create the XCode project with the -sysdir
> >> arguments at first.
> >> Then the copy wouldn't be necessary. Or any other idea would be fine.
> >> Unfortunately cma
Le 06/05/2011 10:36, Abdelrazak Younes a écrit :
The solution would be to create the XCode project with the -sysdir
arguments at first.
Then the copy wouldn't be necessary. Or any other idea would be fine.
Unfortunately cmake recreates the XCode projects from scratch every
time, AFAIK.
Then use
Pavel Sanda wrote:
> Peter Kümmel wrote:
> > Features
> > * I would like to see a BUILD_TYPE flag like in autotools, with automatic
> > selection from lyx version
> > * Disbale merging selectively
> > * Bundles for Mac OSX
>
> check that .tar.gz and .xz are identical to those from autotools
i
Peter Kümmel wrote:
> Features
> * I would like to see a BUILD_TYPE flag like in autotools, with automatic
> selection from lyx version
> * Disbale merging selectively
> * Bundles for Mac OSX
check that .tar.gz and .xz are identical to those from autotools
pavel
Le 06/05/2011 08:24, Stephan Witt a écrit :
* Run in place, without using LYX_DIR_20x
copy the resources (bind/ ui/ layouts/ dicts/ thes/ ...) to the build stage
(?)
This is what I do: copy them from an autotools install into the cmake
project.
No, Package.cpp has to be fixed.
JMar
Le 05/05/2011 22:32, Peter Kümmel a écrit :
This removes the patch for
http://www.lyx.org/trac/ticket/7407
locale_init(); asserts and the try/catch doesn't help.
Tried it again, seems I was wrong.
The trick is that now locale_init is in the try {} part and does not get
invoked when there
Le 05/05/2011 21:35, Peter Kümmel a écrit :
On 05.05.2011 14:55, Kornel wrote:
- NLS disabled by default
Formerly it was enabled by default, but after some discussions Peter
change it
It was too annoying to always having build all the .po stuff when you
wanna only
work on on C++ code. For in
On 06/05/2011 10:46, Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
Log:
So schlafe nun du Kleine!
Was weinest du?
Sanft ist im Mondenscheine,
Und süß die Ruh.
Je vous demande pardon?
Un adieu privée ...
Voilà ce que dit Google :-)
Alors maintenant dormir un peu!
Qu'est-ce que vous pleu
Abdelrazak Younes wrote:
> > Log:
> > So schlafe nun du Kleine!
> > Was weinest du?
> > Sanft ist im Mondenscheine,
> > Und süß die Ruh.
>
> Je vous demande pardon?
Un adieu privée ...
Jürgen
On 06/05/2011 10:40, sp...@lyx.org wrote:
Author: spitz
Date: Fri May 6 10:40:37 2011
New Revision: 38605
URL: http://www.lyx.org/trac/changeset/38605
Log:
So schlafe nun du Kleine!
Was weinest du?
Sanft ist im Mondenscheine,
Und süß die Ruh.
Je vous demande pardon?
On 06/05/2011 10:28, Stephan Witt wrote:
Am 06.05.2011 um 10:15 schrieb Kornel:
Am Freitag, 6. Mai 2011 schrieb Stephan Witt:
Am 06.05.2011 um 09:08 schrieb Kornel:
Am Freitag, 6. Mai 2011 schrieb Stephan Witt:
Bug fixing
* Run in place, without using LYX_DIR_20x
copy the resources (bi
Am Freitag, 6. Mai 2011 schrieb Stephan Witt:
> Am 06.05.2011 um 10:15 schrieb Kornel:
> > Am Freitag, 6. Mai 2011 schrieb Stephan Witt:
> > > Am 06.05.2011 um 09:08 schrieb Kornel:
> > > > Am Freitag, 6. Mai 2011 schrieb Stephan Witt:
> > > > > > Bug fixing
> > > > > > * Run in place, without usin
I've uploaded the tarballs here:
ftp://ftp.devel.lyx.org/pub/lyx/stable/lyx-1.6.10.tar.bz2
ftp://ftp.devel.lyx.org/pub/lyx/stable/lyx-1.6.10.tar.gz
Please test. I will wait with the announcement for the 2.0 announcement and
for binaries.
Thanks,
Jürgen
Am 06.05.2011 um 10:15 schrieb Kornel:
> Am Freitag, 6. Mai 2011 schrieb Stephan Witt:
> > Am 06.05.2011 um 09:08 schrieb Kornel:
> > > Am Freitag, 6. Mai 2011 schrieb Stephan Witt:
> > > > > Bug fixing
> > > > > * Run in place, without using LYX_DIR_20x
> > > > >
> > > >copy the resources (b
Am Freitag, 6. Mai 2011 schrieb Pavel Sanda:
> Kornel wrote:
> > Every so often there were svn-conflicts,
>
> po conflicts are seldom under autotools (ie the remerge isn't done for each
> build).
>
> > either I was forced to remove the created po-files, or I had to commit
> > the remerged.
>
> s
> I think I have quite an uncommon opinion (among LyX developers) about
> what LFUNs are causing (perhaps as a side effect) in the LyX code.
> Basically, many classes use this machinery to invoke operations, with
> the result that sometimes the class does not get a properly designed
> interface
Am Freitag, 6. Mai 2011 schrieb Kornel:
> > > * Run in place, without using LYX_DIR_20x
> >
> >
This is now LYX_DIR_21x.
Kornel
signature.asc
Description: This is a digitally signed message part.
Am Freitag, 6. Mai 2011 schrieb Stephan Witt:
> Am 06.05.2011 um 09:08 schrieb Kornel:
> > Am Freitag, 6. Mai 2011 schrieb Stephan Witt:
> > > > Bug fixing
> > > > * Run in place, without using LYX_DIR_20x
> > > >
> > >copy the resources (bind/ ui/ layouts/ dicts/ thes/ ...) to the
> > >bu
Il 05/05/2011 22:40, venom00 ha scritto:
My idea was to issue commands to LyX via LFUNs, which are
quite stable, even because they're associated with
customizable shortcuts. I think this is a very uninvasive approach.
For the language I prefer Python because _a lot_ of people
uses it and I thi
Joost Verburg wrote:
> "Pavel Sanda" wrote in message
> news:20110505061312.ga15...@atrey.karlin.mff.cuni.cz...
>> Joost do you have time to fix (in another words should i wait with
>> announce for the new version)?
>
> I was just able to reproduce the problem. Compiling new installers now.
ple
... and will probably stay in this state forever.
I'm setting up 1.6.10 now.
Jürgen
Am 06.05.2011 um 09:08 schrieb Kornel:
> Am Freitag, 6. Mai 2011 schrieb Stephan Witt:
> > > Bug fixing
> > > * Run in place, without using LYX_DIR_20x
> >
> >copy the resources (bind/ ui/ layouts/ dicts/ thes/ ...) to the build
> > stage (?) This is what I do: copy them from an autotools ins
On 6-5-2011 8:37, Peter Kümmel wrote:
> And who collects all the ideas from this 100+ thread?
I do.
Vincent
venom00 wrote:
> > And who collects all the ideas from this 100+ thread?
> >
> > When extending the list we should post the complete list.
> > And discussion should not be done within the list.
>
> A wiki page?
this sounds nice idea, but i doesn't work in practise looking for last two
attempts
Am Freitag, 6. Mai 2011 schrieb Stephan Witt:
> > Bug fixing
> > * Run in place, without using LYX_DIR_20x
>
>copy the resources (bind/ ui/ layouts/ dicts/ thes/ ...) to the build
> stage (?) This is what I do: copy them from an autotools install into the
> cmake project.
We may as well try t
Kornel wrote:
> Every so often there were svn-conflicts,
po conflicts are seldom under autotools (ie the remerge isn't done for each
build).
> either I was forced to remove the created po-files, or I had to commit the
> remerged.
svn revert *.po //git checkout -f
> At that time the created po
> And who collects all the ideas from this 100+ thread?
>
> When extending the list we should post the complete list.
> And discussion should not be done within the list.
A wiki page?
venom00
75 matches
Mail list logo
