Re: Suggestion: Inkscape External Document

[Julien Rioux]

On 28/07/2014 10:18 AM, Jean-Marc Lasgouttes wrote:

Le 28/07/2014 16:02, Paul Johnson a écrit :

I've found Xfig to be increasingly difficult to use on newer Linux
systems and consider now using Inkscape.

[...]


Now Inkscape has a similar --export-latex flag, described here:

http://www.ctan.org/tex-archive/info/svg-inkscape

That has preamble code that works exactly like the LyX external
document s.

I think it would be nice if you incorporate that in LyX, save me the
trouble of running inkscape scripts separately.


This can be done by copying and modifying the Xfig entry in
external_templates. The format looks a bit intimidating at first sight,
but it is documented as far as I know.

JMarc





You would need to define the converters, too. But somebody already did 
this and explained it here: http://www.lyx.org/trac/ticket/7510


Cheers,
Julien

Re: Suggestion: Inkscape External Document

[Julien Rioux]

On 28/07/2014 10:18 AM, Jean-Marc Lasgouttes wrote:

Le 28/07/2014 16:02, Paul Johnson a écrit :

I've found Xfig to be increasingly difficult to use on newer Linux
systems and consider now using Inkscape.

[...]


Now Inkscape has a similar --export-latex flag, described here:

http://www.ctan.org/tex-archive/info/svg-inkscape

That has preamble code that works exactly like the LyX external
document s.

I think it would be nice if you incorporate that in LyX, save me the
trouble of running inkscape scripts separately.


This can be done by copying and modifying the Xfig entry in
external_templates. The format looks a bit intimidating at first sight,
but it is documented as far as I know.

JMarc





You would need to define the converters, too. But somebody already did 
this and explained it here: http://www.lyx.org/trac/ticket/7510


Cheers,
Julien

Re: LyX 2.0.8.1 Sources, For Real This Time!

[Julien Rioux]

On 16/06/2014 12:52 PM, stefano franchi wrote:

On 06/13/2014 06:26 PM, stefano franchi wrote:



2. Configuration fails on the automake version. I have 1.14.1
installed, and autogen.sh claims LyX only supports versions
up to 1.13. Editing the autogen.sh file to accept 1.14 seems
to fix the problem, though. Unless there are issues with
automake I am unaware of.

Ok. I'll make a one line patch for the Archlinux package then. That
seems the simplest solution.




Normally you don't need to run autogen.sh from the tarball, you only 
need to run it for a git checkout. So no patch should be necessary, 
unless something is messed up with the tarball.


Cheers,
Julien

Re: LyX 2.0.8.1 Sources, For Real This Time!

[Julien Rioux]

On 16/06/2014 12:52 PM, stefano franchi wrote:

On 06/13/2014 06:26 PM, stefano franchi wrote:



2. Configuration fails on the automake version. I have 1.14.1
installed, and autogen.sh claims LyX only supports versions
up to 1.13. Editing the autogen.sh file to accept 1.14 seems
to fix the problem, though. Unless there are issues with
automake I am unaware of.

Ok. I'll make a one line patch for the Archlinux package then. That
seems the simplest solution.




Normally you don't need to run autogen.sh from the tarball, you only 
need to run it for a git checkout. So no patch should be necessary, 
unless something is messed up with the tarball.


Cheers,
Julien

Re: GSoC: Overhauling LyX's converter scheme

[Julien Rioux]

On 11/03/2014 1:42 PM, Jean-Marc Lasgouttes wrote:

Le 11/03/14 10:43, Rainer M Krug a écrit :

Just an observation from somebody not involved:

The conversion route should be taking quality loss in consideration,
i.e. a conversion path which only involves lossless conversions, even if
it is longer, should be preferred.


We already have a vector flag that serves this purpose, but we could
maybe improve on that.

JMarc



I am not sure if we use this information. Last time I looked we selected 
a shorter conversion path over a longer, fully vectorial one.


--
Julien

Re: GSoC: Overhauling LyX's converter scheme

[Julien Rioux]

On 11/03/2014 12:30 PM, Pavel Sanda wrote:

Roy Xia wrote:

additional goals out there


Special flag for dangerous targets which allow running 3rd party code,
like R/knitr or gnuplot. User should allow these targets explicitly and
and they shouldn't run by default as it is now.

Pavel



Agreed. Lilypond is in that category too, right now it is run in safe 
mode which prevents any harm, but it also restricts the kind of music 
snippet that you can write, i.e. it prevents using any coding. It should 
be possible for advanced users to activate nonsafe mode for files they 
trust.


--
Julien

Re: GSoC: Overhauling LyX's converter scheme

[Julien Rioux]

On 11/03/2014 1:42 PM, Jean-Marc Lasgouttes wrote:

Le 11/03/14 10:43, Rainer M Krug a écrit :

Just an observation from somebody not involved:

The conversion route should be taking quality loss in consideration,
i.e. a conversion path which only involves lossless conversions, even if
it is longer, should be preferred.


We already have a "vector" flag that serves this purpose, but we could
maybe improve on that.

JMarc



I am not sure if we use this information. Last time I looked we selected 
a shorter conversion path over a longer, fully vectorial one.


--
Julien

Re: GSoC: Overhauling LyX's converter scheme

[Julien Rioux]

On 11/03/2014 12:30 PM, Pavel Sanda wrote:

Roy Xia wrote:

additional goals out there


Special flag for "dangerous" targets which allow running 3rd party code,
like R/knitr or gnuplot. User should allow these targets explicitly and
and they shouldn't run by default as it is now.

Pavel



Agreed. Lilypond is in that category too, right now it is run in "safe" 
mode which prevents any harm, but it also restricts the kind of music 
snippet that you can write, i.e. it prevents using any coding. It should 
be possible for advanced users to activate "nonsafe" mode for files they 
trust.


--
Julien

Re: PATCH: automatic copying and migration of elder user config directories Was: LyX user directory path on Mac contains PACKAGE

[Julien Rioux]

On 28/07/2013 10:36 AM, Richard Heck wrote:

On 07/28/2013 04:32 AM, Stephan Witt wrote:

Am 28.07.2013 um 10:04 schrieb Pavel Sanda sa...@lyx.org:


Stephan Witt wrote:

I don't think we want to check this on every OS. If I'd
specifically created such a directory on Linux, I'd be surpried by
this behavior.

IMHO, it's a question of using --with-version-suffix or not. It's
not the platform.

You use --with-version-suffix by default on mac installs?

Yes. All LyX packages I've seen on Mac are built with version suffix.
Starting with 1.6 for all 1.6.X versions. I simply did not change that.
Now on Mac the build is done with 2.0.

As 2.0.0 was released I had to accompany this with a README to explain
how to copy the user preferences manually.

This I want to avoid for 2.1.0.


I guess maybe I'm confused. I thought --with-version-suffix affected the
installation directory for the system-wide install. I.e., if I use it,
then stuff goes to /usr/local/share/lyx-2.0/ instead of
/usr/local/share/lyx/. Does it also affect the default user directory? How?



The userdir with version suffix is ~/.lyx-2.0 instead of ~/.lyx

--
Julien

Re: two design questions

[Julien Rioux]

On 28/07/2013 10:42 AM, Richard Heck wrote:

On 07/28/2013 02:04 AM, Cyrille Artho wrote:


For the image name, is X a temporary name or a token to separate
file names with the same paths but different subdirectories? If it's
the latter, it can't be removed. I would either use the directory
relative to the document root as X (with slashes replaced by
underscores, for example), or a unique token.


In the mangled filename, we always have, as Josh said,
X_path_to_original_file_filename.ext, where X is the index of the image
within the file. So X is just a counter that guarantees that the
filename will be unique, no matter what happens with the rest.

In the end, I think X_filename.ext would be sufficient for purposes of
export. Simple, elegant, etc.


+1


Note that, if LaTeX export works the same way, then we have been
exposing the directory structure for a long time and should probably
change this globally. If LaTeX export does not work the same way,
however, then there is presumably a ready-made solution waiting to be used.



LaTeX export does not work that way, but I think that it also does 
nothing to prevent duplicate filenames from different subdir.


--
Julien

Re: PATCH: automatic copying and migration of elder user config directories Was: LyX user directory path on Mac contains PACKAGE

[Julien Rioux]

On 28/07/2013 10:36 AM, Richard Heck wrote:

On 07/28/2013 04:32 AM, Stephan Witt wrote:

Am 28.07.2013 um 10:04 schrieb Pavel Sanda :


Stephan Witt wrote:

I don't think we want to check this on every OS. If I'd
specifically created such a directory on Linux, I'd be surpried by
this behavior.

IMHO, it's a question of using --with-version-suffix or not. It's
not the platform.

You use --with-version-suffix by default on mac installs?

Yes. All LyX packages I've seen on Mac are built with version suffix.
Starting with 1.6 for all 1.6.X versions. I simply did not change that.
Now on Mac the build is done with 2.0.

As 2.0.0 was released I had to accompany this with a README to explain
how to copy the user preferences manually.

This I want to avoid for 2.1.0.


I guess maybe I'm confused. I thought --with-version-suffix affected the
installation directory for the system-wide install. I.e., if I use it,
then stuff goes to /usr/local/share/lyx-2.0/ instead of
/usr/local/share/lyx/. Does it also affect the default user directory? How?



The userdir with version suffix is ~/.lyx-2.0 instead of ~/.lyx

--
Julien

Re: two design questions

[Julien Rioux]

On 28/07/2013 10:42 AM, Richard Heck wrote:

On 07/28/2013 02:04 AM, Cyrille Artho wrote:


For the image name, is "X" a temporary name or a token to separate
file names with the same paths but different subdirectories? If it's
the latter, it can't be removed. I would either use the directory
relative to the document root as "X" (with slashes replaced by
underscores, for example), or a unique token.


In the "mangled" filename, we always have, as Josh said,
"X_path_to_original_file_filename.ext, where X is the index of the image
within the file". So X is just a counter that guarantees that the
filename will be unique, no matter what happens with the rest.

In the end, I think X_filename.ext would be sufficient for purposes of
export. Simple, elegant, etc.


+1


Note that, if LaTeX export works the same way, then we have been
exposing the directory structure for a long time and should probably
change this globally. If LaTeX export does not work the same way,
however, then there is presumably a ready-made solution waiting to be used.



LaTeX export does not work that way, but I think that it also does 
nothing to prevent duplicate filenames from different subdir.


--
Julien

Re: questions about using Doxygen and Python scripting

[Julien Rioux]

On 22/07/2013 4:10 AM, Guenter Milde wrote:

On 2013-07-22, Josh Hieronymus wrote:




Second, is there a tutorial
serves as a gentle introduction to Python scripting for LyX? I've not
worked with Python and C++ in the same project before, so I'm not really
sure how to get them to work together, especially when you consider issues
like type checking, namespaces, header files, and so on.


The Python scripts that come with LyX are all separate tools and pure
Python. There is no LyX Python module in C or C++.



Exactly, we just call the python interpreter on our scripts (or external 
scripts). They are run as separate processes, nothing tricky.



See the existing tools for examples how to configure a Python script as
exporter.



What Günter refers to is lib/configure.py where target export formats 
are defined, converters are being detected whther they are installed or 
not, etc. So e.g. ePub could be added as format, and configure could 
check if the lyx2epub.py converter (or whatever) is installed and define 
it as a converter. Then when LyX is requested to export to ePub, we call 
the python interpreter to run the python script ina temporary folder and 
move its output file(s) to the export folder.


Cheers,
Julien

Re: questions about using Doxygen and Python scripting

[Julien Rioux]

On 22/07/2013 4:10 AM, Guenter Milde wrote:

On 2013-07-22, Josh Hieronymus wrote:




Second, is there a tutorial
serves as a gentle introduction to Python scripting for LyX? I've not
worked with Python and C++ in the same project before, so I'm not really
sure how to get them to work together, especially when you consider issues
like type checking, namespaces, header files, and so on.


The Python scripts that come with LyX are all separate tools and pure
Python. There is no LyX Python module in C or C++.



Exactly, we just call the python interpreter on our scripts (or external 
scripts). They are run as separate processes, nothing tricky.



See the existing tools for examples how to configure a Python script as
exporter.



What Günter refers to is lib/configure.py where target export formats 
are defined, converters are being detected whther they are installed or 
not, etc. So e.g. ePub could be added as format, and configure could 
check if the lyx2epub.py converter (or whatever) is installed and define 
it as a converter. Then when LyX is requested to export to ePub, we call 
the python interpreter to run the python script ina temporary folder and 
move its output file(s) to the export folder.


Cheers,
Julien

Re: [LyX GSoC/xhtml/bugs/8280] Render multicharacter delims properly to MathML and XHTML (Fix bug #8280)

[Julien Rioux]

On 08/07/2013 8:21 PM, Josh Hieronymus wrote:

I'm looking at how to put convertDelimToXMLEscape() into output_xhtml,
but I'm not sure how best to do this, or whether it might be better to
put it somewhere else. convertDelimToXMLEscape() uses mathedWordList()
from MathFactory, which isn't currently included in output_xhtml. Would
it make more sense just to make a new file and include that in both
InsetMathDelim and InsetMathBig?





Hi Josh,
I would put convertDelimToXMLEscape() into MathFactory, then, and see if 
that works. We can always move it later; a new file might make sense if 
we end up with many of these helper functions, but for now this should 
be fine.


Cheers,
Julien

Re: [LyX GSoC/xhtml/bugs/8280] Render multicharacter delims properly to MathML and XHTML (Fix bug #8280)

[Julien Rioux]

On 08/07/2013 8:21 PM, Josh Hieronymus wrote:

I'm looking at how to put convertDelimToXMLEscape() into output_xhtml,
but I'm not sure how best to do this, or whether it might be better to
put it somewhere else. convertDelimToXMLEscape() uses mathedWordList()
from MathFactory, which isn't currently included in output_xhtml. Would
it make more sense just to make a new file and include that in both
InsetMathDelim and InsetMathBig?





Hi Josh,
I would put convertDelimToXMLEscape() into MathFactory, then, and see if 
that works. We can always move it later; a new file might make sense if 
we end up with many of these helper functions, but for now this should 
be fine.


Cheers,
Julien

Re: Fourth of July Weekend

[Julien Rioux]

On 06/07/2013 12:41 PM, Ashley Shan wrote:

I pushed updated code to master branch on the remote server.


Hi Ashley,
Where exactly are you pushing this code? It would be nice to experiment 
with it a bit.

Thanks,
Cheers,
Julien

Re: Fourth of July Weekend

[Julien Rioux]

On 06/07/2013 12:41 PM, Ashley Shan wrote:

I pushed updated code to master branch on the remote server.


Hi Ashley,
Where exactly are you pushing this code? It would be nice to experiment 
with it a bit.

Thanks,
Cheers,
Julien

Re: LyX 2.1 -- now ;)

[Julien Rioux]

On 04/07/2013 2:19 PM, Vincent van Ravesteijn wrote:

Dear all,

As you noted, I was busy last weeks. As always, time seems to backfire
after spending a lot of it on LyX.

I will pick up some last patches, and start tagging and releasing the
first beta.

Vincent



Hi Vincent,
Welcome back! Can these patches go in?
http://www.lyx.org/trac/ticket/7951
http://www.lyx.org/trac/ticket/8759

--
Julien

Re: LyX 2.1 -- now ;)

[Julien Rioux]

On 04/07/2013 2:19 PM, Vincent van Ravesteijn wrote:

Dear all,

As you noted, I was busy last weeks. As always, time seems to backfire
after spending a lot of it on LyX.

I will pick up some last patches, and start tagging and releasing the
first beta.

Vincent



Hi Vincent,
Welcome back! Can these patches go in?
http://www.lyx.org/trac/ticket/7951
http://www.lyx.org/trac/ticket/8759

--
Julien

Re: [patch] 2 patches for master

[Julien Rioux]

On 24/06/2013 5:35 PM, Uwe Stöhr wrote:

Am 09.06.2013 01:15, schrieb Uwe Stöhr:


attached a 2 fixes for LyX 2.1 beta:...


Ping!

Why about the current development? I have been away for 2 weeks but LyX
seems to stuck on something I don't know and cannot find in the mails.


Probably because Vincent asked to stop committing to master:
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg179711.html

That said, the 2.1 beta due in two weeks announcement is now over a 
month old:

http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg179270.html

It would make sense to cut a 2.1.0 stable branch now. Development could 
continue normally in master, while critical fixes and final translations 
would trickle down to this stable branch as a beta is prepared.


Cheers,
Julien

Re: [patch] 2 patches for master

[Julien Rioux]

On 24/06/2013 5:35 PM, Uwe Stöhr wrote:

Am 09.06.2013 01:15, schrieb Uwe Stöhr:


attached a 2 fixes for LyX 2.1 beta:...


Ping!

Why about the current development? I have been away for 2 weeks but LyX
seems to stuck on something I don't know and cannot find in the mails.


Probably because Vincent asked to stop committing to master:
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg179711.html

That said, the "2.1 beta due in two weeks" announcement is now over a 
month old:

http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg179270.html

It would make sense to cut a 2.1.0 stable branch now. Development could 
continue normally in master, while critical fixes and final translations 
would trickle down to this stable branch as a beta is prepared.


Cheers,
Julien

Re: LyX user directory path on Mac contains PACKAGE

[Julien Rioux]

On 26/05/2013 4:14 PM, Stephan Witt wrote:

When 2.0.0 came out we had a problem on Mac with the user directory path.
All the time it's name was the value of the PACKAGE definition.
Consequently it changed from LyX-1.6 to LyX-2.0 then.

Now we start the 2.1 series and the user directory will change to LyX-2.1.
Because we have prefs2prefs it should be copied somehow from LyX-2.0 to LyX-2.1
initially in case LyX-2.0 (or LyX-1.6) is present.

But I'm not sure if this can be done by the configure.py script
or what other way one can go.

It would be good if this can be fixed before the final 2.1 release.

Stephan



It's correct for the user directory to contain the version, so that you 
can have both 2.0 and 2.1 installed without interfering. If the user 
wants to retain their preferences from 2.0 when installing 2.1, they can 
copy their 2.0 folder to the 2.1 folder. This is something that the 
installer could offer to do for the user, but I doubt that it belongs in 
configure.py.


Cheers,
Julien

Re: Xfig external file import bug.

[Julien Rioux]

On 23/05/2013 3:23 PM, Georg Baum wrote:

Julien Rioux wrote:


On 08/04/2013 3:20 PM, Georg Baum wrote:

If nobody beats me to it I'll have a look, but since I am very short on
time currently this may only be in about two weeks.


Georg




Ping!


Sorry, I forgot this one, and now I am short on time again. It would be very
nice if you could create a bug entry including the test cases and cc me,
then I won't forget again.


Georg




http://www.lyx.org/trac/ticket/8751

--
Julien

Re: LyX user directory path on Mac contains PACKAGE

[Julien Rioux]

On 26/05/2013 4:14 PM, Stephan Witt wrote:

When 2.0.0 came out we had a problem on Mac with the user directory path.
All the time it's name was the value of the PACKAGE definition.
Consequently it changed from LyX-1.6 to LyX-2.0 then.

Now we start the 2.1 series and the user directory will change to LyX-2.1.
Because we have prefs2prefs it should be copied somehow from LyX-2.0 to LyX-2.1
initially in case LyX-2.0 (or LyX-1.6) is present.

But I'm not sure if this can be done by the "configure.py" script
or what other way one can go.

It would be good if this can be fixed before the final 2.1 release.

Stephan



It's correct for the user directory to contain the version, so that you 
can have both 2.0 and 2.1 installed without interfering. If the user 
wants to retain their preferences from 2.0 when installing 2.1, they can 
copy their 2.0 folder to the 2.1 folder. This is something that the 
installer could offer to do for the user, but I doubt that it belongs in 
configure.py.


Cheers,
Julien

Re: Xfig external file import bug.

[Julien Rioux]

On 23/05/2013 3:23 PM, Georg Baum wrote:

Julien Rioux wrote:


On 08/04/2013 3:20 PM, Georg Baum wrote:

If nobody beats me to it I'll have a look, but since I am very short on
time currently this may only be in about two weeks.


Georg




Ping!


Sorry, I forgot this one, and now I am short on time again. It would be very
nice if you could create a bug entry including the test cases and cc me,
then I won't forget again.


Georg




http://www.lyx.org/trac/ticket/8751

--
Julien

Re: [LyX/master] Update tex2lyx testcases to latest fileformat

[Julien Rioux]

On 05/06/2013 6:44 AM, Kornel Benko wrote:

Am Dienstag, 4. Juni 2013 um 21:57:33, schrieb Vincent van Ravesteijn
v...@lyx.org

  commit d15bc5ef538b2923da57d205ba6fea84a6d80a73

  Author: Vincent van Ravesteijn v...@lyx.org

  Date:   Tue Jun 4 20:27:24 2013 +0200

 

  Update tex2lyx testcases to latest fileformat

 

  diff --git a/src/tex2lyx/test/CJK.lyx.lyx b/src/tex2lyx/test/CJK.lyx.lyx

Not nice, I get now:

--- /usr/src/lyx/lyx-git/src/tex2lyx/test/test-modules.lyx.lyx Wed Jun 5
11:13:06 2013

+++ /usr/BUILD/BuildLyxGit/src/tex2lyx/test/test-modules.lyx Wed Jun 5
12:37:22 2013

@@ -1,4 +1,4 @@

-#LyX file created by tex2lyx 2.1.0

+#LyX file created by tex2lyx 2.1.0dev



Did we not decide to drop the .0 part? Although I did not see an issue 
for tex2lyx, we still have this issue for lyx2lyx: 
http://www.lyx.org/trac/ticket/7951


--
Julien

Re: [LyX/master] Update tex2lyx testcases to latest fileformat

[Julien Rioux]

On 05/06/2013 6:44 AM, Kornel Benko wrote:

Am Dienstag, 4. Juni 2013 um 21:57:33, schrieb Vincent van Ravesteijn


 > commit d15bc5ef538b2923da57d205ba6fea84a6d80a73

 > Author: Vincent van Ravesteijn 

 > Date:   Tue Jun 4 20:27:24 2013 +0200

 >

 > Update tex2lyx testcases to latest fileformat

 >

 > diff --git a/src/tex2lyx/test/CJK.lyx.lyx b/src/tex2lyx/test/CJK.lyx.lyx

Not nice, I get now:

--- /usr/src/lyx/lyx-git/src/tex2lyx/test/test-modules.lyx.lyx Wed Jun 5
11:13:06 2013

+++ /usr/BUILD/BuildLyxGit/src/tex2lyx/test/test-modules.lyx Wed Jun 5
12:37:22 2013

@@ -1,4 +1,4 @@

-#LyX file created by tex2lyx 2.1.0

+#LyX file created by tex2lyx 2.1.0dev



Did we not decide to drop the .0 part? Although I did not see an issue 
for tex2lyx, we still have this issue for lyx2lyx: 
http://www.lyx.org/trac/ticket/7951


--
Julien

Re: Google Summer of Code: XHTML and ePub

[Julien Rioux]

On Tue, May 28, 2013 at 9:53 AM, Richard Heck rgh...@lyx.org wrote:


 Hi, also, from me, Josh,

 We have had some previous communication, but let me welcome you officially
 to LyX's very first year of participation in GSoC. We're excited to be
 doing this, and we hope very much that the experience will be a good one
 for you and for LyX.

 As you know, the next three weeks or so are dedicated to community
 bonding. In practice, this is supposed to provide an opportunity for you
 to become integrated into the development community here, so that you are
 comfortable asking questions, etc, once you actually start coding.

 Interaction among LyX developers happens almost entirely on the lyx-devel
 mailing list, and you should join the list immediately, if you have not
 already done so. It would also be worth your subscribing to lyx-cvs, the
 misnamed list that receives messages from git when commits are made. The
 best way to get a sense for how things work around here is to watch how
 things work around here.

 My memory is that you have already set up a functional development
 environment. If not, please let us know, and we'll help get that working.
 You should work off the master branch, which is what will shortly become
 LyX 2.1.0.

 Are you familiar with git? If so, then great. If not, then have a look at
 http://wiki.lyx.org/Devel/Git
 http://wiki.lyx.org/Devel/LyXGit
 which gives some basic guidance to how to use it. Julien and I, and others
 on the list who know git much better than we do, can answer any questions
 you may have. But the basic workflow is pretty well described on those
 pages, and we will develop one as a group as we proceed.

 Somehow, somewhere, we will set up a git repo for this project, so that
 you can share your work there. We are still deciding exactly how and where
 to do this.

 It would be really useful if you could spend some time using LyX, to get a
 sense for how it functions. The particular project in which you are engaged
 has less to do with the GUI, of course, than with backend operations, but
 the overall goal here is to make LyX a great platform for ePub, and having
 some sense for how the pieces fit together will be helpful. LyX's
 semantic model for writing is different from most other text processors,
 though it will feel familiar if you have used LaTeX in the past.

 Julien and I have been thinking it would be useful if we post a general
 message to lyx-users and lyx-devel, telling everyone this project is
 underway and soliciting ideas for what needs to be done to make LyX a great
 ePub platform. A page on the wiki might be useful, too. We have quite a few
 ideas collected already, and Rob Oakes, who is mentoring another project,
 has thought quite a bit about this. But there are many LyX users who will
 have ideas, and it would be good to brainstorm a bit before we get started.

 You can find a list of existing XHTML export bugs on my page on the wiki:
 http://www.lyx.org/trac/wiki/HomeRgh
 The list is down toward the bottom. This will give you some sense for what
 complaints people have had to this point.

 Otherwise, you should take a couple days to get set up, letting me and
 Julien know how things are going. We can talk more, the three of us, once
 you are set up, about how best to direct your energies in the near future.
 You and I talked a bit a while ago about how the export facility works, but
 it will be good to focus on that for a while at some point.

 One thing perhaps to think about, on the XHTML side, is how footnotes
 should be handled. The way it is done now is kind of cool, but a bit too
 cool, as it seems not to work on several platforms, and it definitely is
 too fancy for ePub. More generally, you might want to try exporting the
 User's Guide, or some other manual, to LyXHTML, and then looking it over in
 a browser. This will give you a sense for what is working well and what
 needs help.

 Hope that doesn't seem overwhelming!

 Congratulations, again, and welcome to the LyX community.

 Richard


Hi,

Welcome to LyX! I've not much more to add, as Richard has very well said
everything. I would just suggest that you start out playing around with the
code right now! As a LyX user, you'll know already some things that are not
to your liking about the XHTML exports. If not, there is the list that
Richard mentioned. It's always a good start to go for some small
incremental fix. See for example http://www.lyx.org/trac/ticket/8022 or
http://www.lyx.org/trac/ticket/8362 as a start.

Very soon you will see that to achieve anything, you are required to get
acquainted with many tools: git, make or cmake, grep, $EDITOR, etc. To set
you up, checkout the LyX git repository and see if you can compile it
first. Whenever you start working on a independent fix, create a git branch
based off the master branch. Then grep for the relevant part of the code
that seems relevant to a bug report, make the change, compile again, and
cycle until you see a 

Re: Google Summer of Code: XHTML and ePub

[Julien Rioux]

On Tue, May 28, 2013 at 9:53 AM, Richard Heck rgh...@lyx.org wrote:


 Hi, also, from me, Josh,

 We have had some previous communication, but let me welcome you officially
 to LyX's very first year of participation in GSoC. We're excited to be
 doing this, and we hope very much that the experience will be a good one
 for you and for LyX.

 As you know, the next three weeks or so are dedicated to community
 bonding. In practice, this is supposed to provide an opportunity for you
 to become integrated into the development community here, so that you are
 comfortable asking questions, etc, once you actually start coding.

 Interaction among LyX developers happens almost entirely on the lyx-devel
 mailing list, and you should join the list immediately, if you have not
 already done so. It would also be worth your subscribing to lyx-cvs, the
 misnamed list that receives messages from git when commits are made. The
 best way to get a sense for how things work around here is to watch how
 things work around here.

 My memory is that you have already set up a functional development
 environment. If not, please let us know, and we'll help get that working.
 You should work off the master branch, which is what will shortly become
 LyX 2.1.0.

 Are you familiar with git? If so, then great. If not, then have a look at
 http://wiki.lyx.org/Devel/Git
 http://wiki.lyx.org/Devel/LyXGit
 which gives some basic guidance to how to use it. Julien and I, and others
 on the list who know git much better than we do, can answer any questions
 you may have. But the basic workflow is pretty well described on those
 pages, and we will develop one as a group as we proceed.

 Somehow, somewhere, we will set up a git repo for this project, so that
 you can share your work there. We are still deciding exactly how and where
 to do this.

 It would be really useful if you could spend some time using LyX, to get a
 sense for how it functions. The particular project in which you are engaged
 has less to do with the GUI, of course, than with backend operations, but
 the overall goal here is to make LyX a great platform for ePub, and having
 some sense for how the pieces fit together will be helpful. LyX's
 semantic model for writing is different from most other text processors,
 though it will feel familiar if you have used LaTeX in the past.

 Julien and I have been thinking it would be useful if we post a general
 message to lyx-users and lyx-devel, telling everyone this project is
 underway and soliciting ideas for what needs to be done to make LyX a great
 ePub platform. A page on the wiki might be useful, too. We have quite a few
 ideas collected already, and Rob Oakes, who is mentoring another project,
 has thought quite a bit about this. But there are many LyX users who will
 have ideas, and it would be good to brainstorm a bit before we get started.

 You can find a list of existing XHTML export bugs on my page on the wiki:
 http://www.lyx.org/trac/wiki/HomeRgh
 The list is down toward the bottom. This will give you some sense for what
 complaints people have had to this point.

 Otherwise, you should take a couple days to get set up, letting me and
 Julien know how things are going. We can talk more, the three of us, once
 you are set up, about how best to direct your energies in the near future.
 You and I talked a bit a while ago about how the export facility works, but
 it will be good to focus on that for a while at some point.

 One thing perhaps to think about, on the XHTML side, is how footnotes
 should be handled. The way it is done now is kind of cool, but a bit too
 cool, as it seems not to work on several platforms, and it definitely is
 too fancy for ePub. More generally, you might want to try exporting the
 User's Guide, or some other manual, to LyXHTML, and then looking it over in
 a browser. This will give you a sense for what is working well and what
 needs help.

 Hope that doesn't seem overwhelming!

 Congratulations, again, and welcome to the LyX community.

 Richard


Hi,

Welcome to LyX! I've not much more to add, as Richard has very well said
everything. I would just suggest that you start out playing around with the
code right now! As a LyX user, you'll know already some things that are not
to your liking about the XHTML exports. If not, there is the list that
Richard mentioned. It's always a good start to go for some small
incremental fix. See for example http://www.lyx.org/trac/ticket/8022 or
http://www.lyx.org/trac/ticket/8362 as a start.

Very soon you will see that to achieve anything, you are required to get
acquainted with many tools: git, make or cmake, grep, $EDITOR, etc. To set
you up, checkout the LyX git repository and see if you can compile it
first. Whenever you start working on a independent fix, create a git branch
based off the master branch. Then grep for the relevant part of the code
that seems relevant to a bug report, make the change, compile again, and
cycle until you see a 

Re: Google Summer of Code: XHTML and ePub

[Julien Rioux]

On Tue, May 28, 2013 at 9:53 AM, Richard Heck  wrote:

>
> Hi, also, from me, Josh,
>
> We have had some previous communication, but let me welcome you officially
> to LyX's very first year of participation in GSoC. We're excited to be
> doing this, and we hope very much that the experience will be a good one
> for you and for LyX.
>
> As you know, the next three weeks or so are dedicated to "community
> bonding". In practice, this is supposed to provide an opportunity for you
> to become integrated into the development community here, so that you are
> comfortable asking questions, etc, once you actually start coding.
>
> Interaction among LyX developers happens almost entirely on the lyx-devel
> mailing list, and you should join the list immediately, if you have not
> already done so. It would also be worth your subscribing to lyx-cvs, the
> misnamed list that receives messages from git when commits are made. The
> best way to get a sense for how things work around here is to watch how
> things work around here.
>
> My memory is that you have already set up a functional development
> environment. If not, please let us know, and we'll help get that working.
> You should work off the master branch, which is what will shortly become
> LyX 2.1.0.
>
> Are you familiar with git? If so, then great. If not, then have a look at
> http://wiki.lyx.org/Devel/Git
> http://wiki.lyx.org/Devel/LyXGit
> which gives some basic guidance to how to use it. Julien and I, and others
> on the list who know git much better than we do, can answer any questions
> you may have. But the basic workflow is pretty well described on those
> pages, and we will develop one as a group as we proceed.
>
> Somehow, somewhere, we will set up a git repo for this project, so that
> you can share your work there. We are still deciding exactly how and where
> to do this.
>
> It would be really useful if you could spend some time using LyX, to get a
> sense for how it functions. The particular project in which you are engaged
> has less to do with the GUI, of course, than with backend operations, but
> the overall goal here is to make LyX a great platform for ePub, and having
> some sense for how the pieces fit together will be helpful. LyX's
> "semantic" model for writing is different from most other text processors,
> though it will feel familiar if you have used LaTeX in the past.
>
> Julien and I have been thinking it would be useful if we post a general
> message to lyx-users and lyx-devel, telling everyone this project is
> underway and soliciting ideas for what needs to be done to make LyX a great
> ePub platform. A page on the wiki might be useful, too. We have quite a few
> ideas collected already, and Rob Oakes, who is mentoring another project,
> has thought quite a bit about this. But there are many LyX users who will
> have ideas, and it would be good to brainstorm a bit before we get started.
>
> You can find a list of existing XHTML export bugs on my page on the wiki:
> http://www.lyx.org/trac/wiki/HomeRgh
> The list is down toward the bottom. This will give you some sense for what
> complaints people have had to this point.
>
> Otherwise, you should take a couple days to get set up, letting me and
> Julien know how things are going. We can talk more, the three of us, once
> you are set up, about how best to direct your energies in the near future.
> You and I talked a bit a while ago about how the export facility works, but
> it will be good to focus on that for a while at some point.
>
> One thing perhaps to think about, on the XHTML side, is how footnotes
> should be handled. The way it is done now is kind of cool, but a bit too
> cool, as it seems not to work on several platforms, and it definitely is
> too fancy for ePub. More generally, you might want to try exporting the
> User's Guide, or some other manual, to LyXHTML, and then looking it over in
> a browser. This will give you a sense for what is working well and what
> needs help.
>
> Hope that doesn't seem overwhelming!
>
> Congratulations, again, and welcome to the LyX community.
>
> Richard
>
>
Hi,

Welcome to LyX! I've not much more to add, as Richard has very well said
everything. I would just suggest that you start out playing around with the
code right now! As a LyX user, you'll know already some things that are not
to your liking about the XHTML exports. If not, there is the list that
Richard mentioned. It's always a good start to go for some small
incremental fix. See for example http://www.lyx.org/trac/ticket/8022 or
http://www.lyx.org/trac/ticket/8362 as a start.

Very soon you will see that to achieve anything, you are required to get
acquainted with many tools: git, make or cmake, grep, $EDITOR, etc. To set
you up, checkout the LyX git repository and see if you can compile it
first. Whenever you start working on a independent fix, create a git branch
based off the master branch. Then grep for the relevant part of the code
that seems 

Re: Google Summer of Code: XHTML and ePub

[Julien Rioux]

On Tue, May 28, 2013 at 9:53 AM, Richard Heck  wrote:

>
> Hi, also, from me, Josh,
>
> We have had some previous communication, but let me welcome you officially
> to LyX's very first year of participation in GSoC. We're excited to be
> doing this, and we hope very much that the experience will be a good one
> for you and for LyX.
>
> As you know, the next three weeks or so are dedicated to "community
> bonding". In practice, this is supposed to provide an opportunity for you
> to become integrated into the development community here, so that you are
> comfortable asking questions, etc, once you actually start coding.
>
> Interaction among LyX developers happens almost entirely on the lyx-devel
> mailing list, and you should join the list immediately, if you have not
> already done so. It would also be worth your subscribing to lyx-cvs, the
> misnamed list that receives messages from git when commits are made. The
> best way to get a sense for how things work around here is to watch how
> things work around here.
>
> My memory is that you have already set up a functional development
> environment. If not, please let us know, and we'll help get that working.
> You should work off the master branch, which is what will shortly become
> LyX 2.1.0.
>
> Are you familiar with git? If so, then great. If not, then have a look at
> http://wiki.lyx.org/Devel/Git
> http://wiki.lyx.org/Devel/LyXGit
> which gives some basic guidance to how to use it. Julien and I, and others
> on the list who know git much better than we do, can answer any questions
> you may have. But the basic workflow is pretty well described on those
> pages, and we will develop one as a group as we proceed.
>
> Somehow, somewhere, we will set up a git repo for this project, so that
> you can share your work there. We are still deciding exactly how and where
> to do this.
>
> It would be really useful if you could spend some time using LyX, to get a
> sense for how it functions. The particular project in which you are engaged
> has less to do with the GUI, of course, than with backend operations, but
> the overall goal here is to make LyX a great platform for ePub, and having
> some sense for how the pieces fit together will be helpful. LyX's
> "semantic" model for writing is different from most other text processors,
> though it will feel familiar if you have used LaTeX in the past.
>
> Julien and I have been thinking it would be useful if we post a general
> message to lyx-users and lyx-devel, telling everyone this project is
> underway and soliciting ideas for what needs to be done to make LyX a great
> ePub platform. A page on the wiki might be useful, too. We have quite a few
> ideas collected already, and Rob Oakes, who is mentoring another project,
> has thought quite a bit about this. But there are many LyX users who will
> have ideas, and it would be good to brainstorm a bit before we get started.
>
> You can find a list of existing XHTML export bugs on my page on the wiki:
> http://www.lyx.org/trac/wiki/HomeRgh
> The list is down toward the bottom. This will give you some sense for what
> complaints people have had to this point.
>
> Otherwise, you should take a couple days to get set up, letting me and
> Julien know how things are going. We can talk more, the three of us, once
> you are set up, about how best to direct your energies in the near future.
> You and I talked a bit a while ago about how the export facility works, but
> it will be good to focus on that for a while at some point.
>
> One thing perhaps to think about, on the XHTML side, is how footnotes
> should be handled. The way it is done now is kind of cool, but a bit too
> cool, as it seems not to work on several platforms, and it definitely is
> too fancy for ePub. More generally, you might want to try exporting the
> User's Guide, or some other manual, to LyXHTML, and then looking it over in
> a browser. This will give you a sense for what is working well and what
> needs help.
>
> Hope that doesn't seem overwhelming!
>
> Congratulations, again, and welcome to the LyX community.
>
> Richard
>
>
Hi,

Welcome to LyX! I've not much more to add, as Richard has very well said
everything. I would just suggest that you start out playing around with the
code right now! As a LyX user, you'll know already some things that are not
to your liking about the XHTML exports. If not, there is the list that
Richard mentioned. It's always a good start to go for some small
incremental fix. See for example http://www.lyx.org/trac/ticket/8022 or
http://www.lyx.org/trac/ticket/8362 as a start.

Very soon you will see that to achieve anything, you are required to get
acquainted with many tools: git, make or cmake, grep, $EDITOR, etc. To set
you up, checkout the LyX git repository and see if you can compile it
first. Whenever you start working on a independent fix, create a git branch
based off the master branch. Then grep for the relevant part of the code
that seems 

Re: r40348 - lyx-devel/trunk/src/insets

[Julien Rioux]

On Sun, Dec 4, 2011 at 5:24 PM, Richard Heck rgh...@comcast.net wrote:

 On 12/04/2011 04:27 PM, Julien Rioux wrote:
  On Sat, Dec 3, 2011 at 10:16 PM, Richard Heck rgh...@comcast.net
  mailto:rgh...@comcast.net wrote:
 
  On 12/03/2011 05:24 PM, jri...@lyx.org mailto:jri...@lyx.org
 wrote:
   Author: jrioux
   Date: Sat Dec  3 23:24:38 2011
   New Revision: 40348
   URL: http://www.lyx.org/trac/changeset/40348
  
   Log:
   Show insets as text in the formatted bibliography entry.
  
  Probably also for branch? That said, can you tell me what the
  issue was
  here?
 
  Richard
 
 
  The issue was, if you have an inset within a bibitem (an hyperlink
  would be common), the content of this inset was dropped from the
  biblio info. So in the Citation GUI, it would look like the citation
  was incomplete, some part of it was simply dropped.
 
  I noticed this from the file example/FeynmanDiagrams.lyx. Before this
  commit you had in the citation GUI
  of the LaTeX-package feyn
  and now:
  [http link||Documentation] of the LaTeX-package feyn
 
 OK, good for branch, then.

 Richard


Finally in, at 3e5c9e51.
--
Julien

Re: r40347 - lyx-devel/trunk/src/insets

[Julien Rioux]

On Sun, Dec 4, 2011 at 5:25 PM, Richard Heck rgh...@comcast.net wrote:

 On 12/04/2011 04:32 PM, Julien Rioux wrote:
 
  On Sat, Dec 3, 2011 at 10:13 PM, Richard Heck rgh...@comcast.net
  mailto:rgh...@comcast.net wrote:
 
  On 12/03/2011 05:24 PM, jri...@lyx.org mailto:jri...@lyx.org
 wrote:
   Author: jrioux
   Date: Sat Dec  3 23:24:30 2011
   New Revision: 40347
   URL: http://www.lyx.org/trac/changeset/40347
  
   Log:
   Update a bibitem label also when it is emptied.
  
   It is valid for a label to be empty, but up to now the bibliography
   information was not updated when a label was emptied.
  
  Needed in branch, too, I'd suppose?
 
  Richard
 
 
  The commits from yesterday are fixing some small issues that are most
  likely in branch as well, but I did not test. I suppose one could say
  they are needed there, although it's probably safer to test run them
  for a bit.
 
 OK, I'll leave it to you to decide when it is appropriate to commit
 them. They look fairly safe.

 rh


Finally in, at 43893c16
--
Julien

Re: bug on Lyx 2.0.6?

[Julien Rioux]

On Mon, May 20, 2013 at 3:08 PM, Richard Heck rgh...@lyx.org wrote:

 On 05/19/2013 05:07 PM, Julien Rioux wrote:

 On 13/05/2013 9:19 AM, Richard Heck wrote:

 On 05/12/2013 12:44 PM, Julien Rioux wrote:

 I see this too. The modifier, which is an additional letter used if
 you have more than one reference with the same author and year, isn't
 initialized properly. We should fix this in LyX, so thanks for your
 report of the problem.


 Do you mean it is not initialized in the BibTeXInfo constructor?

 Richard



 Yes. This was http://www.lyx.org/trac/**changeset/**
 75ffcc8e866de04b076c81d78003a8**6efca98e4e/lyxgithttp://www.lyx.org/trac/changeset/75ffcc8e866de04b076c81d78003a86efca98e4e/lyxgit

 OK for branch?


 Yes, please.

 rh


It's in at aa475ea7.
--
Julien

Re: r40348 - lyx-devel/trunk/src/insets

[Julien Rioux]

On Sun, Dec 4, 2011 at 5:24 PM, Richard Heck <rgh...@comcast.net> wrote:

> On 12/04/2011 04:27 PM, Julien Rioux wrote:
> > On Sat, Dec 3, 2011 at 10:16 PM, Richard Heck <rgh...@comcast.net
> > <mailto:rgh...@comcast.net>> wrote:
> >
> > On 12/03/2011 05:24 PM, jri...@lyx.org <mailto:jri...@lyx.org>
> wrote:
> > > Author: jrioux
> > > Date: Sat Dec  3 23:24:38 2011
> > > New Revision: 40348
> > > URL: http://www.lyx.org/trac/changeset/40348
> > >
> > > Log:
> > > Show insets as text in the formatted bibliography entry.
> > >
> > Probably also for branch? That said, can you tell me what the
> > issue was
> > here?
> >
> > Richard
> >
> >
> > The issue was, if you have an inset within a bibitem (an hyperlink
> > would be common), the content of this inset was dropped from the
> > biblio info. So in the Citation GUI, it would look like the citation
> > was incomplete, some part of it was simply dropped.
> >
> > I noticed this from the file example/FeynmanDiagrams.lyx. Before this
> > commit you had in the citation GUI
> > "of the LaTeX-package feyn"
> > and now:
> > "[http link||Documentation] of the LaTeX-package feyn"
> >
> OK, good for branch, then.
>
> Richard
>
>
Finally in, at 3e5c9e51.
--
Julien

Re: r40347 - lyx-devel/trunk/src/insets

[Julien Rioux]

On Sun, Dec 4, 2011 at 5:25 PM, Richard Heck <rgh...@comcast.net> wrote:

> On 12/04/2011 04:32 PM, Julien Rioux wrote:
> >
> > On Sat, Dec 3, 2011 at 10:13 PM, Richard Heck <rgh...@comcast.net
> > <mailto:rgh...@comcast.net>> wrote:
> >
> > On 12/03/2011 05:24 PM, jri...@lyx.org <mailto:jri...@lyx.org>
> wrote:
> > > Author: jrioux
> > > Date: Sat Dec  3 23:24:30 2011
> > > New Revision: 40347
> > > URL: http://www.lyx.org/trac/changeset/40347
> > >
> > > Log:
> > > Update a bibitem label also when it is emptied.
> > >
> > > It is valid for a label to be empty, but up to now the bibliography
> > > information was not updated when a label was emptied.
> > >
> > Needed in branch, too, I'd suppose?
> >
> > Richard
> >
> >
> > The commits from yesterday are fixing some small issues that are most
> > likely in branch as well, but I did not test. I suppose one could say
> > they are needed there, although it's probably safer to test run them
> > for a bit.
> >
> OK, I'll leave it to you to decide when it is appropriate to commit
> them. They look fairly safe.
>
> rh
>
>
Finally in, at 43893c16
--
Julien

Re: bug on Lyx 2.0.6?

[Julien Rioux]

On Mon, May 20, 2013 at 3:08 PM, Richard Heck <rgh...@lyx.org> wrote:

> On 05/19/2013 05:07 PM, Julien Rioux wrote:
>
>> On 13/05/2013 9:19 AM, Richard Heck wrote:
>>
>>> On 05/12/2013 12:44 PM, Julien Rioux wrote:
>>>
>>>> I see this too. The "modifier", which is an additional letter used if
>>>> you have more than one reference with the same author and year, isn't
>>>> initialized properly. We should fix this in LyX, so thanks for your
>>>> report of the problem.
>>>>
>>>
>>> Do you mean it is not initialized in the BibTeXInfo constructor?
>>>
>>> Richard
>>>
>>>
>>>
>> Yes. This was http://www.lyx.org/trac/**changeset/**
>> 75ffcc8e866de04b076c81d78003a8**6efca98e4e/lyxgit<http://www.lyx.org/trac/changeset/75ffcc8e866de04b076c81d78003a86efca98e4e/lyxgit>
>>
>> OK for branch?
>>
>
> Yes, please.
>
> rh
>
>
It's in at aa475ea7.
--
Julien

Re: Bounding box of png files

[Julien Rioux]

On 04/05/2013 12:41 PM, Jean-Pierre Chrétien wrote:

Hello,

A recent post on lyx-fr

http://thread.gmane.org/gmane.editors.lyx.french/1769

draw my attention about a bounding box consistency problem for the
exemple.png file attached to this post, which may happen with other png
files unless this one is very particular.

This image is recognised by LyX as being 400x900
(GraphicsClippingGet from file).

However clipping to {90,30,370,815} to remove left legend and title
fails completely and moves the figure around the page whatever the LaTeX
engine chosen, in spite of the fact that clipping appears correctly in
the LyX window.

Converting externally the file to eps with IM convert gives a BB of
0 0 203 456. Clipping the original png figure to homothetic values
{46,15,188,413} gives a wrong clipping on screen, but a correct one on
the output.

Moreover, applying the ebb utility to exemple.png gives a BB of
0 0 288 648
but this is harmless as LyX obviously does not use this utility.

Applying

$ identify -verbose exemple.png | head
Image: exemple.png
   Format: PNG (Portable Network Graphics)
   Class: DirectClass
   Geometry: 400x900+0+0
   Resolution: 55.9x55.9
   Print size: 7.15564x16.1002
   Units: PixelsPerCentimeter

does not help much, I don't see data explaining the difference between
the difference in pixel size in png and eps.

Does this deserve an entry in bugzilla ? A warning in the docs ?



I've opened http://www.lyx.org/trac/ticket/8688 for this.

--
Julien

Re: Xfig external file import bug.

[Julien Rioux]

On 08/04/2013 3:20 PM, Georg Baum wrote:

If nobody beats me to it I'll have a look, but since I am very short on time
currently this may only be in about two weeks.


Georg




Ping!

--
Julien

Re: Howto avoid cygwin/python import problems

[Julien Rioux]

On 04/04/2013 6:53 AM, John McCabe-Dansted wrote:

Just in case someone hits the same problem as me: I had lots of
problems importing files in Windows, getting errors like

  LyX: Document formmat failure
C: ... Buffer_convertLyXFormat.Xd9288
is not a readable Lyx document

It took me a while to figure out that if you are calling a native LyX
exe from a Cygwin shell you can avoid the cygwin python etc. by
running lyx with something like like
   (PATH= /.../lyx)

Cheers,




http://www.lyx.org/trac/ticket/8691

--
Julien

Re: Extending biblatex support

[Julien Rioux]

On 19/02/2013 9:11 AM, Richard Heck wrote:

On 02/18/2013 12:43 PM, stefano franchi wrote:




On Mon, Feb 18, 2013 at 10:02 AM, Richard Heck rgh...@lyx.org
mailto:rgh...@lyx.org wrote:

On 02/18/2013 10:28 AM, stefano franchi wrote:

Currently, support of biblatex's citation commands is very
minimal. In particular, there is no direct support for
\citetitle, \autocite, and so on. The former, in particular, I
use all the times, andit would be really convenient to avoid
entering it as ERT (not to speak of the convenience to have it
appear in the list of citations, the better readability of the
document, and so on).



Unless these macros have special handling, it should be possible to 
define them in a biblatex.module based on, say, jurabib.module or 
natbib.module (the authoryear part of it).



I'd like to take a stab at this, but I never touched Lyx code,
and would appreciate if someone could direct me to the right
place. Or to the right neighborhood. In fact, I'm not even
sure touching the code is necessary. Perhaps, modifying the
biblatex's module would be enough? It does not seem likely
(biblatex.module simply defers to natbib), but I maybe wrong.




At least for the macros part, that stuff is in modules now, so no 
compilation necessary.



It's possible that the only other thing we really need is some
indication in the citation module of how the database info is to
be output. I'll be happy to help with that if it looks worth doing.




The document settings now have a entry for bibliography style. This 
stuff needs to be output to the preamble for biblatex, right? Something 
like that should be added for the .bib file, too. So there is still some 
code to write on this front.



I took a look at the 2.1 natbib.module and it seems it should be
possible to model a biblatex.module from it. However, there may be
some difficulties with all the various styles that biblatex supports.


We'll probably need separate modules for each of the various styles.
Modularization makes this easy to do, whereas the old way this would
mean hard-coding style after style after style.


At any rate, I will look into it a bit further. I see that the
customization manual has some info on the format of the CiteFormat
block. I don't not see any info on the CiteEngine block, though. I
suppose it's a new 2.1 feature related to the modularization of the
bibtex machinery you mentioned?


Yes. Probably we should get on someone to write the docs.

rh



Indeed!

--
Julien

Re: Extending biblatex support

[Julien Rioux]

On 18/02/2013 10:28 AM, stefano franchi wrote:

Currently, support of biblatex's citation commands is very minimal. In
particular, there is no direct support for \citetitle, \autocite, and so
on. The former, in particular, I use all the times, andit would be
really convenient to avoid entering it as ERT (not to speak of the
convenience to have it appear in the list of citations, the better
readability of the document, and so on).

I'd like to take a stab at this, but I never touched Lyx code, and would
appreciate if someone could direct me to the right place. Or to the
right neighborhood. In fact, I'm not even sure touching the code is
necessary. Perhaps, modifying the biblatex's module would be enough? It
does not seem likely (biblatex.module simply defers to natbib), but I
maybe wrong.


Thanks,

Stefano

--
__
Stefano Franchi
Associate Research Professor
Department of Hispanic StudiesPh:   +1 (979) 845-2125
Texas AM University  Fax:  +1 (979) 845-6421
College Station, Texas, USA

stef...@tamu.edu mailto:stef...@tamu.edu
http://stefano.cleinias.org


More on the topic of biblatex support: It seems we don't have a very 
good idea of what we need to do. Never having used biblatex, I only have 
a vague idea how interfacing with biblatex actually happens. For 
example, I think some of the .bib/.bst selection happen in the preamble 
instead of the BibTeX inset, etc, but I am not actually sure which one, 
or is it both. This LaTeX export part should be coded now if we want 
this in for LyX 2.1, especially since including a document setting to 
select .bib files is still a fileformat change.


Another thing that we should do regarding citation engines in general, 
is to change the bibliography pane to be more like the module pane, with 
available citation modules on the left and selected modules on the 
right. This way, users can add their own modules, and we hopefully will 
see the development of some of them during the LyX 2.1 cycle.


Cheers,
Julien

Re: Bounding box of png files

[Julien Rioux]

On 04/05/2013 12:41 PM, Jean-Pierre Chrétien wrote:

Hello,

A recent post on lyx-fr

http://thread.gmane.org/gmane.editors.lyx.french/1769

draw my attention about a bounding box consistency problem for the
exemple.png file attached to this post, which may happen with other png
files unless this one is very particular.

This image is recognised by LyX as being 400x900
(Graphics>Clipping>Get from file).

However clipping to {90,30,370,815} to remove left legend and title
fails completely and moves the figure around the page whatever the LaTeX
engine chosen, in spite of the fact that clipping appears correctly in
the LyX window.

Converting externally the file to eps with IM convert gives a BB of
0 0 203 456. Clipping the original png figure to homothetic values
{46,15,188,413} gives a wrong clipping on screen, but a correct one on
the output.

Moreover, applying the ebb utility to exemple.png gives a BB of
0 0 288 648
but this is harmless as LyX obviously does not use this utility.

Applying

$ identify -verbose exemple.png | head
Image: exemple.png
   Format: PNG (Portable Network Graphics)
   Class: DirectClass
   Geometry: 400x900+0+0
   Resolution: 55.9x55.9
   Print size: 7.15564x16.1002
   Units: PixelsPerCentimeter

does not help much, I don't see data explaining the difference between
the difference in pixel size in png and eps.

Does this deserve an entry in bugzilla ? A warning in the docs ?



I've opened http://www.lyx.org/trac/ticket/8688 for this.

--
Julien

Re: Xfig external file import bug.

[Julien Rioux]

On 08/04/2013 3:20 PM, Georg Baum wrote:

If nobody beats me to it I'll have a look, but since I am very short on time
currently this may only be in about two weeks.


Georg




Ping!

--
Julien

Re: Howto avoid cygwin/python import problems

[Julien Rioux]

On 04/04/2013 6:53 AM, John McCabe-Dansted wrote:

Just in case someone hits the same problem as me: I had lots of
problems importing files in Windows, getting errors like

  LyX: Document formmat failure
C: ... Buffer_convertLyXFormat.Xd9288
is not a readable Lyx document

It took me a while to figure out that if you are calling a native LyX
exe from a Cygwin shell you can avoid the cygwin python etc. by
running lyx with something like like
   (PATH="" /.../lyx)

Cheers,




http://www.lyx.org/trac/ticket/8691

--
Julien

Re: Extending biblatex support

[Julien Rioux]

On 19/02/2013 9:11 AM, Richard Heck wrote:

On 02/18/2013 12:43 PM, stefano franchi wrote:




On Mon, Feb 18, 2013 at 10:02 AM, Richard Heck > wrote:

On 02/18/2013 10:28 AM, stefano franchi wrote:

Currently, support of biblatex's citation commands is very
minimal. In particular, there is no direct support for
\citetitle, \autocite, and so on. The former, in particular, I
use all the times, andit would be really convenient to avoid
entering it as ERT (not to speak of the convenience to have it
appear in the list of citations, the better readability of the
document, and so on).



Unless these macros have special handling, it should be possible to 
define them in a biblatex.module based on, say, jurabib.module or 
natbib.module (the authoryear part of it).



I'd like to take a stab at this, but I never touched Lyx code,
and would appreciate if someone could direct me to the right
place. Or to the right neighborhood. In fact, I'm not even
sure touching the code is necessary. Perhaps, modifying the
biblatex's module would be enough? It does not seem likely
(biblatex.module simply defers to natbib), but I maybe wrong.




At least for the macros part, that stuff is in modules now, so no 
compilation necessary.



It's possible that the only other thing we really need is some
indication in the citation module of how the database info is to
be output. I'll be happy to help with that if it looks worth doing.




The document settings now have a entry for bibliography style. This 
stuff needs to be output to the preamble for biblatex, right? Something 
like that should be added for the .bib file, too. So there is still some 
code to write on this front.



I took a look at the 2.1 natbib.module and it seems it should be
possible to model a biblatex.module from it. However, there may be
some difficulties with all the various styles that biblatex supports.


We'll probably need separate modules for each of the various styles.
Modularization makes this easy to do, whereas the old way this would
mean hard-coding style after style after style.


At any rate, I will look into it a bit further. I see that the
customization manual has some info on the format of the CiteFormat
block. I don't not see any info on the CiteEngine block, though. I
suppose it's a new 2.1 feature related to the modularization of the
bibtex machinery you mentioned?


Yes. Probably we should get on someone to write the docs.

rh



Indeed!

--
Julien

Re: Extending biblatex support

[Julien Rioux]

On 18/02/2013 10:28 AM, stefano franchi wrote:

Currently, support of biblatex's citation commands is very minimal. In
particular, there is no direct support for \citetitle, \autocite, and so
on. The former, in particular, I use all the times, andit would be
really convenient to avoid entering it as ERT (not to speak of the
convenience to have it appear in the list of citations, the better
readability of the document, and so on).

I'd like to take a stab at this, but I never touched Lyx code, and would
appreciate if someone could direct me to the right place. Or to the
right neighborhood. In fact, I'm not even sure touching the code is
necessary. Perhaps, modifying the biblatex's module would be enough? It
does not seem likely (biblatex.module simply defers to natbib), but I
maybe wrong.


Thanks,

Stefano

--
__
Stefano Franchi
Associate Research Professor
Department of Hispanic StudiesPh:   +1 (979) 845-2125
Texas A University  Fax:  +1 (979) 845-6421
College Station, Texas, USA

stef...@tamu.edu 
http://stefano.cleinias.org


More on the topic of biblatex support: It seems we don't have a very 
good idea of what we need to do. Never having used biblatex, I only have 
a vague idea how interfacing with biblatex actually happens. For 
example, I think some of the .bib/.bst selection happen in the preamble 
instead of the BibTeX inset, etc, but I am not actually sure which one, 
or is it both. This LaTeX export part should be coded now if we want 
this in for LyX 2.1, especially since including a document setting to 
select .bib files is still a fileformat change.


Another thing that we should do regarding citation engines in general, 
is to change the bibliography pane to be more like the module pane, with 
available citation modules on the left and selected modules on the 
right. This way, users can add their own modules, and we hopefully will 
see the development of some of them during the LyX 2.1 cycle.


Cheers,
Julien

Re: bug on Lyx 2.0.6?

[Julien Rioux]

On 13/05/2013 9:19 AM, Richard Heck wrote:

On 05/12/2013 12:44 PM, Julien Rioux wrote:

I see this too. The modifier, which is an additional letter used if
you have more than one reference with the same author and year, isn't
initialized properly. We should fix this in LyX, so thanks for your
report of the problem.


Do you mean it is not initialized in the BibTeXInfo constructor?

Richard




Yes. This was 
http://www.lyx.org/trac/changeset/75ffcc8e866de04b076c81d78003a86efca98e4e/lyxgit


OK for branch?

--
Julien

Re: bug on Lyx 2.0.6?

[Julien Rioux]

On 12/05/2013 12:44 PM, Julien Rioux wrote:

On 09/05/2013 5:05 PM, Nicola Scafetta, Ph. D. wrote:

The reference in the Bibliography starts with [White(2010)] that
should not be visible.



This is at the moment not customizable, so you would have to remove it
yourself, unfortunately. Maybe we can have this customizable in LyX 2.1.



Actually, the CSS needed to hide this label is very simple, since you 
can target the span element with a class='bibitemlabel'.


--
Julien

Re: bug on Lyx 2.0.6?

[Julien Rioux]

On 13/05/2013 9:19 AM, Richard Heck wrote:

On 05/12/2013 12:44 PM, Julien Rioux wrote:

I see this too. The "modifier", which is an additional letter used if
you have more than one reference with the same author and year, isn't
initialized properly. We should fix this in LyX, so thanks for your
report of the problem.


Do you mean it is not initialized in the BibTeXInfo constructor?

Richard




Yes. This was 
http://www.lyx.org/trac/changeset/75ffcc8e866de04b076c81d78003a86efca98e4e/lyxgit


OK for branch?

--
Julien

Re: bug on Lyx 2.0.6?

[Julien Rioux]

On 12/05/2013 12:44 PM, Julien Rioux wrote:

On 09/05/2013 5:05 PM, Nicola Scafetta, Ph. D. wrote:

The reference in the Bibliography starts with "[White(2010)]" that
should not be visible.



This is at the moment not customizable, so you would have to remove it
yourself, unfortunately. Maybe we can have this customizable in LyX 2.1.



Actually, the CSS needed to hide this label is very simple, since you 
can target the span element with a class='bibitemlabel'.


--
Julien

Re: [LyX master] qt5: Fix use of zlib

[Julien Rioux]

On 14/05/2013 10:10 AM, Stephan Witt wrote:

This breaks the compilation of tex2lyx:

In file included from /Users/stephan/git/lyx/src/tex2lyx/../Lexer.cpp:23:
/Users/stephan/git/lyx/src/tex2lyx/../support/gzstream.h:35:18: error: QtCore: 
No such file or directory

Stephan





Master is still not compilable here, I need the patch below to be able 
to compile.Is this the correct fix?


commit 442907e29a2b9ff89f1bce1fac85a4e789f5e00d
Author: Julien Rioux jri...@lyx.org
Date:   Tue May 14 21:53:08 2013 +0200

Compilation fix.

diff --git a/src/frontends/qt4/GuiAbout.cpp b/src/frontends/qt4/GuiAbout.cpp
index ae9a2a3..09834d4 100644
--- a/src/frontends/qt4/GuiAbout.cpp
+++ b/src/frontends/qt4/GuiAbout.cpp
@@ -23,6 +23,7 @@
 #include support/Package.h

 #include QDate
+#include QFile
 #include QTextStream

 using namespace lyx::support;


--
Julien

Re: [LyX master] qt5: Fix use of zlib

[Julien Rioux]

On 14/05/2013 4:00 PM, Julien Rioux wrote:

On 14/05/2013 10:10 AM, Stephan Witt wrote:

This breaks the compilation of tex2lyx:

In file included from /Users/stephan/git/lyx/src/tex2lyx/../Lexer.cpp:23:
/Users/stephan/git/lyx/src/tex2lyx/../support/gzstream.h:35:18: error:
QtCore: No such file or directory

Stephan





Master is still not compilable here


Here's the error, with Qt 4.7.4, LyX compiled with autotools, fixed by 
the previous patch:


make[7]: Entering directory 
`/home/watt/jrioux/git/lyx/build-dirac/src/frontends/qt4'

  CXXGuiAbout.o
../../../../src/frontends/qt4/GuiAbout.cpp: In function 'QString 
lyx::frontend::credits()':
../../../../src/frontends/qt4/GuiAbout.cpp:46:2: error: 'QFile' was not 
declared in this scope
../../../../src/frontends/qt4/GuiAbout.cpp:46:8: error: expected ';' 
before 'file'
../../../../src/frontends/qt4/GuiAbout.cpp:49:6: error: 'file' was not 
declared in this scope

make[7]: *** [GuiAbout.o] Error 1


--
Julien

Re: [LyX master] qt5: Fix use of zlib

[Julien Rioux]

On 14/05/2013 10:10 AM, Stephan Witt wrote:

This breaks the compilation of tex2lyx:

In file included from /Users/stephan/git/lyx/src/tex2lyx/../Lexer.cpp:23:
/Users/stephan/git/lyx/src/tex2lyx/../support/gzstream.h:35:18: error: QtCore: 
No such file or directory

Stephan





Master is still not compilable here, I need the patch below to be able 
to compile.Is this the correct fix?


commit 442907e29a2b9ff89f1bce1fac85a4e789f5e00d
Author: Julien Rioux <jri...@lyx.org>
Date:   Tue May 14 21:53:08 2013 +0200

Compilation fix.

diff --git a/src/frontends/qt4/GuiAbout.cpp b/src/frontends/qt4/GuiAbout.cpp
index ae9a2a3..09834d4 100644
--- a/src/frontends/qt4/GuiAbout.cpp
+++ b/src/frontends/qt4/GuiAbout.cpp
@@ -23,6 +23,7 @@
 #include "support/Package.h"

 #include 
+#include 
 #include 

 using namespace lyx::support;


--
Julien

Re: [LyX master] qt5: Fix use of zlib

[Julien Rioux]

On 14/05/2013 4:00 PM, Julien Rioux wrote:

On 14/05/2013 10:10 AM, Stephan Witt wrote:

This breaks the compilation of tex2lyx:

In file included from /Users/stephan/git/lyx/src/tex2lyx/../Lexer.cpp:23:
/Users/stephan/git/lyx/src/tex2lyx/../support/gzstream.h:35:18: error:
QtCore: No such file or directory

Stephan





Master is still not compilable here


Here's the error, with Qt 4.7.4, LyX compiled with autotools, fixed by 
the previous patch:


make[7]: Entering directory 
`/home/watt/jrioux/git/lyx/build-dirac/src/frontends/qt4'

  CXXGuiAbout.o
../../../../src/frontends/qt4/GuiAbout.cpp: In function 'QString 
lyx::frontend::credits()':
../../../../src/frontends/qt4/GuiAbout.cpp:46:2: error: 'QFile' was not 
declared in this scope
../../../../src/frontends/qt4/GuiAbout.cpp:46:8: error: expected ';' 
before 'file'
../../../../src/frontends/qt4/GuiAbout.cpp:49:6: error: 'file' was not 
declared in this scope

make[7]: *** [GuiAbout.o] Error 1


--
Julien

Re: bug on Lyx 2.0.6?

[Julien Rioux]

On 09/05/2013 5:05 PM, Nicola Scafetta, Ph. D. wrote:

The bug with LyXHTML, which is different from that encountered with
elyxer.py, is the following.

See the attached files.

In the .xhtml file the reference in the text appears with a symbol after
the year that should not be there.



I see this too. The modifier, which is an additional letter used if 
you have more than one reference with the same author and year, isn't 
initialized properly. We should fix this in LyX, so thanks for your 
report of the problem.



The reference in the Bibliography starts with [White(2010)] that
should not be visible.



This is at the moment not customizable, so you would have to remove it 
yourself, unfortunately. Maybe we can have this customizable in LyX 2.1.



Compare the .xhtml file with the .pdf of the same .lyx file.


nicola



Cheers,
Julien

Re: [PATCH] WIP Make python scripts work with python3

[Julien Rioux]

On 12/05/2013 10:07 AM, Lars Gullik Bjønnes wrote:

---
  development/autotests/keytest.py | 112 ++--
  development/cmake/doc/ReplaceValues.py   |   4 +-
  development/cmake/po/cat.py  |   2 +-
  development/keystest/cache-bisect.py |  78 +--
  development/keystest/keytest.py  |  62 +--
  development/keystest/make_screenshot_html.py |  20 +-
  development/tools/convert_kmap.py|  18 +-
  development/tools/generate_symbols_images.py |  14 +-
  development/tools/generate_symbols_list.py   |  28 +-
  development/tools/unicodesymbols.py  |   2 +-
  lib/configure.py |  14 +-
  lib/generate_contributions.py| 786 +--
  lib/lyx2lyx/LyX.py   |   8 +-
  lib/lyx2lyx/generate_encoding_info.py|   8 +-
  lib/lyx2lyx/lyx2lyx_tools.py |   2 +-
  lib/lyx2lyx/lyx_1_2.py   |   6 +-
  lib/lyx2lyx/lyx_1_4.py   |   4 +-
  lib/lyx2lyx/lyx_1_5.py   |  70 +--
  lib/lyx2lyx/lyx_1_6.py   |  10 +-
  lib/lyx2lyx/lyx_2_1.py   |  24 +-
  lib/lyx2lyx/parser_tools.py  |  12 +-
  lib/lyx2lyx/unicode_symbols.py   |   6 +-
  lib/scripts/TeXFiles.py  |  10 +-
  lib/scripts/convertDefault.py|   4 +-
  lib/scripts/date.py  |   2 +-
  lib/scripts/fen2ascii.py |   8 +-
  lib/scripts/fig2pdftex.py|   6 +-
  lib/scripts/fig2pstex.py |   2 +-
  lib/scripts/fig_copy.py  |   8 +-
  lib/scripts/html2latexwrapper.py |   2 +-
  lib/scripts/include_bib.py   |   8 +-
  lib/scripts/legacy_lyxpreview2ppm.py |   6 +-
  lib/scripts/lyxpak.py|   4 +-
  lib/scripts/lyxpreview2bitmap.py |   6 +-
  lib/scripts/lyxpreview_tools.py  |   2 +-
  lib/scripts/prefs2prefs.py   |  18 +-
  lib/scripts/prefs2prefs_prefs.py |   4 +-
  po/lyx_pot.py|  74 +--
  po/postats.py|   6 +-
  src/tex2lyx/test/runtests.py |   2 +-
  40 files changed, 731 insertions(+), 731 deletions(-)

diff --git a/development/autotests/keytest.py b/development/autotests/keytest.py
index a510a3f..5331348 100755
--- a/development/autotests/keytest.py
+++ b/development/autotests/keytest.py
@@ -16,7 +16,7 @@ import time
  #from subprocess import call
  import subprocess

-print 'Beginning keytest.py'
+print('Beginning keytest.py')

  FNULL = open('/dev/null', 'w')

@@ -78,7 +78,7 @@ class CommandSourceFromFile(CommandSource):
  self.infile.close()
  linesbak = self.lines
  self.p = p
-print p, self.p, 'self.p'
+print(p, self.p, 'self.p')


Is this intended to support both python 2 and 3? From a quick glance I 
do not see from __future__ import print_function anywhere.


--
Julien

Re: [PATCH] WIP Make python scripts work with python3

[Julien Rioux]

On 12/05/2013 1:00 PM, José Matos wrote:

On Sunday 12 May 2013 12:46:26 Julien Rioux wrote:

Is this intended to support both python 2 and 3? From a quick glance I
do not see from __future__ import print_function anywhere.


If it did that then the minimal version required would need to be 2.6.

As it is the parenthesis are ignore in python 2 and required in python 3.



Not quite ignored, if you have comma-delimited stuff and add () then 
python 2 prints a tuple:


$ python
Python 2.7 (r27:82500, Aug 07 2010, 16:54:59) [GCC] on linux2
Type help, copyright, credits or license for more information.
 print 'h', 0
h 0
 print('h', 0)
('h', 0)
 from __future__ import print_function
 print('h', 0)
h 0

--
Julien

Re: Trac mails b0rken

[Julien Rioux]

On 12/05/2013 2:56 PM, Pavel Sanda wrote:

Georg Baum wrote:

Indeed it seems if CC myself with lyx unrelated email it works, if I'm
CC-ed either as sanda or sa...@lyx.org I get nothing (the @lyx.org mail
work fine itself though).


I don't get any trac mail either, but I do get the cvs list emails to the
.lyx.org address.


Hm. That means that all the mass triage of 2.1 milestoned bugs with all
the posted questions will be ignored.

Pavel



I did get a couple ticket emails to @lyx.org, don't know if I missed 
any. Is the plan to release LyX 2.1 this month?


--
Julien

Re: bug on Lyx 2.0.6?

[Julien Rioux]

On 09/05/2013 5:05 PM, Nicola Scafetta, Ph. D. wrote:

The bug with LyXHTML, which is different from that encountered with
elyxer.py, is the following.

See the attached files.

In the .xhtml file the reference in the text appears with a symbol after
the year that should not be there.



I see this too. The "modifier", which is an additional letter used if 
you have more than one reference with the same author and year, isn't 
initialized properly. We should fix this in LyX, so thanks for your 
report of the problem.



The reference in the Bibliography starts with "[White(2010)]" that
should not be visible.



This is at the moment not customizable, so you would have to remove it 
yourself, unfortunately. Maybe we can have this customizable in LyX 2.1.



Compare the .xhtml file with the .pdf of the same .lyx file.


nicola



Cheers,
Julien

Re: [PATCH] WIP Make python scripts work with python3

[Julien Rioux]

On 12/05/2013 10:07 AM, Lars Gullik Bjønnes wrote:

---
  development/autotests/keytest.py | 112 ++--
  development/cmake/doc/ReplaceValues.py   |   4 +-
  development/cmake/po/cat.py  |   2 +-
  development/keystest/cache-bisect.py |  78 +--
  development/keystest/keytest.py  |  62 +--
  development/keystest/make_screenshot_html.py |  20 +-
  development/tools/convert_kmap.py|  18 +-
  development/tools/generate_symbols_images.py |  14 +-
  development/tools/generate_symbols_list.py   |  28 +-
  development/tools/unicodesymbols.py  |   2 +-
  lib/configure.py |  14 +-
  lib/generate_contributions.py| 786 +--
  lib/lyx2lyx/LyX.py   |   8 +-
  lib/lyx2lyx/generate_encoding_info.py|   8 +-
  lib/lyx2lyx/lyx2lyx_tools.py |   2 +-
  lib/lyx2lyx/lyx_1_2.py   |   6 +-
  lib/lyx2lyx/lyx_1_4.py   |   4 +-
  lib/lyx2lyx/lyx_1_5.py   |  70 +--
  lib/lyx2lyx/lyx_1_6.py   |  10 +-
  lib/lyx2lyx/lyx_2_1.py   |  24 +-
  lib/lyx2lyx/parser_tools.py  |  12 +-
  lib/lyx2lyx/unicode_symbols.py   |   6 +-
  lib/scripts/TeXFiles.py  |  10 +-
  lib/scripts/convertDefault.py|   4 +-
  lib/scripts/date.py  |   2 +-
  lib/scripts/fen2ascii.py |   8 +-
  lib/scripts/fig2pdftex.py|   6 +-
  lib/scripts/fig2pstex.py |   2 +-
  lib/scripts/fig_copy.py  |   8 +-
  lib/scripts/html2latexwrapper.py |   2 +-
  lib/scripts/include_bib.py   |   8 +-
  lib/scripts/legacy_lyxpreview2ppm.py |   6 +-
  lib/scripts/lyxpak.py|   4 +-
  lib/scripts/lyxpreview2bitmap.py |   6 +-
  lib/scripts/lyxpreview_tools.py  |   2 +-
  lib/scripts/prefs2prefs.py   |  18 +-
  lib/scripts/prefs2prefs_prefs.py |   4 +-
  po/lyx_pot.py|  74 +--
  po/postats.py|   6 +-
  src/tex2lyx/test/runtests.py |   2 +-
  40 files changed, 731 insertions(+), 731 deletions(-)

diff --git a/development/autotests/keytest.py b/development/autotests/keytest.py
index a510a3f..5331348 100755
--- a/development/autotests/keytest.py
+++ b/development/autotests/keytest.py
@@ -16,7 +16,7 @@ import time
  #from subprocess import call
  import subprocess

-print 'Beginning keytest.py'
+print('Beginning keytest.py')

  FNULL = open('/dev/null', 'w')

@@ -78,7 +78,7 @@ class CommandSourceFromFile(CommandSource):
  self.infile.close()
  linesbak = self.lines
  self.p = p
-print p, self.p, 'self.p'
+print(p, self.p, 'self.p')


Is this intended to support both python 2 and 3? From a quick glance I 
do not see "from __future__ import print_function" anywhere.


--
Julien

Re: [PATCH] WIP Make python scripts work with python3

[Julien Rioux]

On 12/05/2013 1:00 PM, José Matos wrote:

On Sunday 12 May 2013 12:46:26 Julien Rioux wrote:

Is this intended to support both python 2 and 3? From a quick glance I
do not see "from __future__ import print_function" anywhere.


If it did that then the minimal version required would need to be 2.6.

As it is the parenthesis are ignore in python 2 and required in python 3.



Not quite ignored, if you have comma-delimited stuff and add () then 
python 2 prints a tuple:


$ python
Python 2.7 (r27:82500, Aug 07 2010, 16:54:59) [GCC] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print 'h', 0
h 0
>>> print('h', 0)
('h', 0)
>>> from __future__ import print_function
>>> print('h', 0)
h 0

--
Julien

Re: Trac mails b0rken

[Julien Rioux]

On 12/05/2013 2:56 PM, Pavel Sanda wrote:

Georg Baum wrote:

Indeed it seems if CC myself with lyx unrelated email it works, if I'm
CC-ed either as sanda or sa...@lyx.org I get nothing (the @lyx.org mail
work fine itself though).


I don't get any trac mail either, but I do get the cvs list emails to the
.lyx.org address.


Hm. That means that all the mass triage of 2.1 milestoned bugs with all
the posted questions will be ignored.

Pavel



I did get a couple ticket emails to @lyx.org, don't know if I missed 
any. Is the plan to release LyX 2.1 this month?


--
Julien

Re: [LyX master] Math.lyx: fix a typo

[Julien Rioux]

On 11/05/2013 5:30 AM, Pavel Sanda wrote:

Uwe Stöhr wrote:

Am 11.05.2013 10:59, schrieb Pavel Sanda:


I have the setting check out as is, commit as is in mysgit.
Also in the commit I cannot see any EOL change:
http://www.lyx.org/trac/changeset/c962e1ca/lyxgit


Don't look at trac. What do you see at your own local git repo,
e.g. git show c962e1ca1daf6bf572d558f ?


I see only one changed line when looking at that commit locally.


Hm, thats strange. After pulling your commit Math.lyx get converted
to windows CRLF lines at my box and logs show exactly as our
lyx-cvs list:
http://article.gmane.org/gmane.editors.lyx.cvs/37396

Do other people on linux see the same problem?



Yes, I see it too. The whole file was converted and the diff is over 70k 
lines.


 git show c962e1ca1daf6bf572d558f | wc
  76911  148048 1308880

--
Julien

Re: [LyX master] Math.lyx: fix a typo

[Julien Rioux]

On 11/05/2013 5:30 AM, Pavel Sanda wrote:

Uwe Stöhr wrote:

Am 11.05.2013 10:59, schrieb Pavel Sanda:


I have the setting "check out as is, commit as is" in mysgit.
Also in the commit I cannot see any EOL change:
http://www.lyx.org/trac/changeset/c962e1ca/lyxgit


Don't look at trac. What do you see at your own local git repo,
e.g. git show c962e1ca1daf6bf572d558f ?


I see only one changed line when looking at that commit locally.


Hm, thats strange. After pulling your commit Math.lyx get converted
to windows CRLF lines at my box and logs show exactly as our
lyx-cvs list:
http://article.gmane.org/gmane.editors.lyx.cvs/37396

Do other people on linux see the same problem?



Yes, I see it too. The whole file was converted and the diff is over 70k 
lines.


> git show c962e1ca1daf6bf572d558f | wc
  76911  148048 1308880

--
Julien

Re: [PATCH] Pass the binary dir to the configure script to find tex2lyx

[Julien Rioux]

On 30/03/2013 9:46 AM, Vincent van Ravesteijn wrote:

When using CMake, the binary files are stored in build-dir/bin. LyX can't fin 
tex2lyx with the current code. So, we have to point configure.py to explicitly look 
in the binary dir.

Any objections ?

Vincent

---
  lib/configure.py|9 -
  src/support/Package.cpp |2 +-
  2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/lib/configure.py b/lib/configure.py
index b6c453d..2ae6ec2 100644
--- a/lib/configure.py
+++ b/lib/configure.py
@@ -652,7 +652,10 @@ def checkConverterEntries():
  in_place = os.path.join(srcdir, '..', 'src', 'tex2lyx', 'tex2lyx')
  in_place = os.path.abspath(in_place)

-path, t2l = checkProg('a LaTeX/Noweb - LyX converter', [in_place, 
'tex2lyx' + version_suffix, 'tex2lyx'],
+in_binary_dir = os.path.join(lyx_binary_dir, 'tex2lyx')
+in_binary_dir = os.path.abspath(in_binary_dir)
+
+path, t2l = checkProg('a LaTeX/Noweb - LyX converter', [in_place, 
in_place + version_suffix, in_binary_dir, in_binary_dir + version_suffix, 
'tex2lyx' + version_suffix, 'tex2lyx'],
  rc_entry = [r'''\converter latex  lyx%% -f $$i $$o
  \converter literate   lyx%% -n -m noweb -f $$i $$o'''], 
not_found = 'tex2lyx')
  if path == '':
@@ -1394,6 +1397,7 @@ if __name__ == '__main__':
  rc_entries = ''
  lyx_keep_temps = False
  version_suffix = ''
+lyx_binary_dir = ''
  ## Parse the command line
  for op in sys.argv[1:]:   # default shell/for list is $*, the options
  if op in [ '-help', '--help', '-h' ]:
@@ -1404,6 +1408,7 @@ Options:
  --without-kpsewhich  do not update TeX files information via kpsewhich
  --without-latex-config   do not run LaTeX to determine configuration
  --with-version-suffix=suffix suffix of binary installed files
+--binary-dir=directory   directory of binary installed files
  '''
  sys.exit(0)
  elif op == '--without-kpsewhich':
@@ -1414,6 +1419,8 @@ Options:
  lyx_keep_temps = True
  elif op[0:22] == '--with-version-suffix=':  # never mind if op is not 
long enough
  version_suffix = op[22:]
+elif op[0:13] == '--binary-dir=':
+lyx_binary_dir = op[13:]
  else:
  print Unknown option, op
  sys.exit(1)
diff --git a/src/support/Package.cpp b/src/support/Package.cpp
index dab008e..695e89f 100644
--- a/src/support/Package.cpp
+++ b/src/support/Package.cpp
@@ -141,7 +141,7 @@ Package::Package(string const  command_line_arg0,
FileName const configure_script(addName(system_support().absFileName(), 
configure.py));
configure_command_ = os::python() + ' ' +
quoteName(configure_script.toFilesystemEncoding(), 
quote_python) +
-   with_version_suffix();
+   with_version_suffix() +  --binary-dir= + 
binary_dir().absFileName();

LYXERR(Debug::INIT, package\n
 \tbinary_dir   binary_dir().absFileName()  '\n'



+1, I think this fixes http://www.lyx.org/trac/ticket/6986 in a nice 
build-system-agnostic way.


--
Julien

Re: [PATCH] Pass the binary dir to the configure script to find tex2lyx

[Julien Rioux]

On 30/03/2013 9:46 AM, Vincent van Ravesteijn wrote:

When using CMake, the binary files are stored in /bin. LyX can't fin 
tex2lyx with the current code. So, we have to point configure.py to explicitly look 
in the binary dir.

Any objections ?

Vincent

---
  lib/configure.py|9 -
  src/support/Package.cpp |2 +-
  2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/lib/configure.py b/lib/configure.py
index b6c453d..2ae6ec2 100644
--- a/lib/configure.py
+++ b/lib/configure.py
@@ -652,7 +652,10 @@ def checkConverterEntries():
  in_place = os.path.join(srcdir, '..', 'src', 'tex2lyx', 'tex2lyx')
  in_place = os.path.abspath(in_place)

-path, t2l = checkProg('a LaTeX/Noweb -> LyX converter', [in_place, 
'tex2lyx' + version_suffix, 'tex2lyx'],
+in_binary_dir = os.path.join(lyx_binary_dir, 'tex2lyx')
+in_binary_dir = os.path.abspath(in_binary_dir)
+
+path, t2l = checkProg('a LaTeX/Noweb -> LyX converter', [in_place, 
in_place + version_suffix, in_binary_dir, in_binary_dir + version_suffix, 
'tex2lyx' + version_suffix, 'tex2lyx'],
  rc_entry = [r'''\converter latex  lyx"%% -f $$i $$o"""
  \converter literate   lyx"%% -n -m noweb -f $$i $$o"""'''], 
not_found = 'tex2lyx')
  if path == '':
@@ -1394,6 +1397,7 @@ if __name__ == '__main__':
  rc_entries = ''
  lyx_keep_temps = False
  version_suffix = ''
+lyx_binary_dir = ''
  ## Parse the command line
  for op in sys.argv[1:]:   # default shell/for list is $*, the options
  if op in [ '-help', '--help', '-h' ]:
@@ -1404,6 +1408,7 @@ Options:
  --without-kpsewhich  do not update TeX files information via kpsewhich
  --without-latex-config   do not run LaTeX to determine configuration
  --with-version-suffix=suffix suffix of binary installed files
+--binary-dir=directory   directory of binary installed files
  '''
  sys.exit(0)
  elif op == '--without-kpsewhich':
@@ -1414,6 +1419,8 @@ Options:
  lyx_keep_temps = True
  elif op[0:22] == '--with-version-suffix=':  # never mind if op is not 
long enough
  version_suffix = op[22:]
+elif op[0:13] == '--binary-dir=':
+lyx_binary_dir = op[13:]
  else:
  print "Unknown option", op
  sys.exit(1)
diff --git a/src/support/Package.cpp b/src/support/Package.cpp
index dab008e..695e89f 100644
--- a/src/support/Package.cpp
+++ b/src/support/Package.cpp
@@ -141,7 +141,7 @@ Package::Package(string const & command_line_arg0,
FileName const configure_script(addName(system_support().absFileName(), 
"configure.py"));
configure_command_ = os::python() + ' ' +
quoteName(configure_script.toFilesystemEncoding(), 
quote_python) +
-   with_version_suffix();
+   with_version_suffix() + " --binary-dir=" + 
binary_dir().absFileName();

LYXERR(Debug::INIT, "\n"
<< "\tbinary_dir " << binary_dir().absFileName() << '\n'



+1, I think this fixes http://www.lyx.org/trac/ticket/6986 in a nice 
build-system-agnostic way.


--
Julien

Re: Extreme slowness in lyx 2.1.

[Julien Rioux]

On 05/03/2013 1:45 PM, Richard Heck wrote:

On 03/05/2013 10:21 AM, Kornel Benko wrote:


Am Dienstag, 5. März 2013 um 16:02:27, schrieb Kornel Benko
kor...@lyx.org

 Am Dienstag, 5. März 2013 um 15:36:41, schrieb Kornel Benko
kor...@lyx.org

   Actually, you might start by just putting a LYXERR0 into the
routine to make

   sure it really is being called a lot.

 

  Will do.

 



 Here are the calls to InsetBibtex::plaintext() routine.



 Action How often called

 ##

 On Start 6

 Position cursor with mouse in master file 3

 Select new file on TOC 3

 Select file on tab 3

 Select file on TOC (already in tab-bar) 0

 Select area with keys 3

 Select area with mouse 0

 Insert Return 3

 Insert other char 0

 ###



 This does not seam much, but it takes about 10 seconds each time (~3
seconds/call)



Backtracing now:

Start:

#0 lyx::InsetBibtex::plaintext (this=0x2a1c8b0, os=...)

at /usr/src/lyx/lyx-git/src/insets/InsetBibtex.cpp:934

#1 0x009e5cd6 in lyx::writePlaintextParagraph (buf=...,
par=..., os=..., runparams=...,

ref_printed=@0x7fffa9cf: false) at
/usr/src/lyx/lyx-git/src/output_plaintext.cpp:205

#2 0x00d52957 in lyx::InsetText::toolTipText (this=0x2a4d280,
prefix=..., numlines=3,

len=60) at /usr/src/lyx/lyx-git/src/insets/InsetText.cpp:976

#3 0x00d4b555 in lyx::InsetBranch::addToToc (this=0x2a4d280,
cpit=...)

at /usr/src/lyx/lyx-git/src/insets/InsetBranch.cpp:359



That's exactly the king of thing I thought we'd find: plaintext() is
often used to generate tooltips. And that is what is happening here,
since you have the bibliography inset in a branch. I've always been
suspicious of this, and we've had this kind of problem before.

I don't have time to deal with this today, but the solution is pretty
straightforward. First of all, in InsetText::toolTipText(), I'd set
 rp.for_toc = true;
before calling writePlaintextParagraph(). This isn't exactly right, and
one might think it's a hack. Maybe we should also have for_tooltip. But
I doubt they'd ever come apart. But one could create the new boolean if
one wished.

Second, around line 205 of writePlaintextParagraph(), do a test like:
 if (!runparams.for_toc || par.getInset(i).isInToc())
before doing anything substantial. Then we skip stuff that isn't for the
TOC.

That much, we should probably do anyway.

Third, add:
  InsetBibtex::isInToc() const { return false; }
to ignore that.

Richard




So it sounds like plaintext() is used for export + other things. The 
code I added really needs to be executed only on actual export. What you 
suggests is to use for_toc to distinguish between calling plaintext for 
export vs. all the other use cases. Sounds like a plan.


--
Julien

Re: Extreme slowness in lyx 2.1.

[Julien Rioux]

On 05/03/2013 1:45 PM, Richard Heck wrote:

On 03/05/2013 10:21 AM, Kornel Benko wrote:


Am Dienstag, 5. März 2013 um 16:02:27, schrieb Kornel Benko


> Am Dienstag, 5. März 2013 um 15:36:41, schrieb Kornel Benko


> > > Actually, you might start by just putting a LYXERR0 into the
routine to make

> > > sure it really is being called a lot.

> >

> > Will do.

> >

>

> Here are the calls to InsetBibtex::plaintext() routine.

>

> Action How often called

> ##

> On Start 6

> Position cursor with mouse in master file 3

> Select new file on TOC 3

> Select file on tab 3

> Select file on TOC (already in tab-bar) 0

> Select area with keys 3

> Select area with mouse 0

> Insert  3

> Insert other char 0

> ###

>

> This does not seam much, but it takes about 10 seconds each time (~3
seconds/call)

>

Backtracing now:

Start:

#0 lyx::InsetBibtex::plaintext (this=0x2a1c8b0, os=...)

at /usr/src/lyx/lyx-git/src/insets/InsetBibtex.cpp:934

#1 0x009e5cd6 in lyx::writePlaintextParagraph (buf=...,
par=..., os=..., runparams=...,

ref_printed=@0x7fffa9cf: false) at
/usr/src/lyx/lyx-git/src/output_plaintext.cpp:205

#2 0x00d52957 in lyx::InsetText::toolTipText (this=0x2a4d280,
prefix=..., numlines=3,

len=60) at /usr/src/lyx/lyx-git/src/insets/InsetText.cpp:976

#3 0x00d4b555 in lyx::InsetBranch::addToToc (this=0x2a4d280,
cpit=...)

at /usr/src/lyx/lyx-git/src/insets/InsetBranch.cpp:359



That's exactly the king of thing I thought we'd find: plaintext() is
often used to generate tooltips. And that is what is happening here,
since you have the bibliography inset in a branch. I've always been
suspicious of this, and we've had this kind of problem before.

I don't have time to deal with this today, but the solution is pretty
straightforward. First of all, in InsetText::toolTipText(), I'd set
 rp.for_toc = true;
before calling writePlaintextParagraph(). This isn't exactly right, and
one might think it's a hack. Maybe we should also have for_tooltip. But
I doubt they'd ever come apart. But one could create the new boolean if
one wished.

Second, around line 205 of writePlaintextParagraph(), do a test like:
 if (!runparams.for_toc || par.getInset(i).isInToc())
before doing anything substantial. Then we skip stuff that isn't for the
TOC.

That much, we should probably do anyway.

Third, add:
  InsetBibtex::isInToc() const { return false; }
to ignore that.

Richard




So it sounds like plaintext() is used for export + other things. The 
code I added really needs to be executed only on actual export. What you 
suggests is to use for_toc to distinguish between calling plaintext for 
export vs. all the other use cases. Sounds like a plan.


--
Julien

Re: commit [9dd1b7c5/lyxgit]

[Julien Rioux]

On 18/02/2013 6:26 PM, Uwe Stöhr wrote:

Hello Julien,

you added in this commit an empty line to tex2lyx's TODO.txt. Can you
please specify what needs to be supported by tex2lyx?
As far as i see, nothing needs to be done, but I am not sure. If so, can
you please remove the line?

thanks and regards
Uwe



Empty line = Nothing needs to be done ;)
(as opposed to No line == did this guy forgets to touch tex2lyx?)

--
Julien

Re: commit [9dd1b7c5/lyxgit]

[Julien Rioux]

On 18/02/2013 6:26 PM, Uwe Stöhr wrote:

Hello Julien,

you added in this commit an empty line to tex2lyx's TODO.txt. Can you
please specify what needs to be supported by tex2lyx?
As far as i see, nothing needs to be done, but I am not sure. If so, can
you please remove the line?

thanks and regards
Uwe



Empty line = Nothing needs to be done ;)
(as opposed to No line == did this guy forgets to touch tex2lyx?)

--
Julien

Re: I cannot export examples/beamer.lyx with pdflatex

[Julien Rioux]

On 09/02/2013 5:43 AM, Scott Kostyshak wrote:

I can export beamerlyxexample1.lyx fine but exporting beamer.lyx
stalls. If I export to LaTeX (pdflatex) and then run pdflatex on it
manually, I get the following log:
http://paste.debian.net/232860/

I can reproduce the above on two Ubuntu 12.04 64-bit computers, both
with TeXLive 2012. Could this be a problem with my beamer package? I
have not updated any of my packages since installing TeXLive 2012. In
my beamer.cls file I see 2010/06/21.

Any ideas?

Thanks,

Scott



I think we have the same problem: 
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg176483.html


--
Julien

Re: I cannot export examples/beamer.lyx with pdflatex

[Julien Rioux]

On 09/02/2013 6:28 AM, Jürgen Spitzmüller wrote:

Julien Rioux wrote:

I think we have the same problem:
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg176483.html


Wasn't yours one with beamer-article? Scott's problem occurs with the
presentation.

Jürgen



I cannot get either one to compile.

--
Julien

Re: I cannot export examples/beamer.lyx with pdflatex

[Julien Rioux]

On 09/02/2013 5:43 AM, Scott Kostyshak wrote:

I can export beamerlyxexample1.lyx fine but exporting beamer.lyx
stalls. If I export to LaTeX (pdflatex) and then run pdflatex on it
manually, I get the following log:
http://paste.debian.net/232860/

I can reproduce the above on two Ubuntu 12.04 64-bit computers, both
with TeXLive 2012. Could this be a problem with my beamer package? I
have not updated any of my packages since installing TeXLive 2012. In
my beamer.cls file I see "2010/06/21".

Any ideas?

Thanks,

Scott



I think we have the same problem: 
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg176483.html


--
Julien

Re: I cannot export examples/beamer.lyx with pdflatex

[Julien Rioux]

On 09/02/2013 6:28 AM, Jürgen Spitzmüller wrote:

Julien Rioux wrote:

I think we have the same problem:
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg176483.html


Wasn't yours one with beamer-article? Scott's problem occurs with the
presentation.

Jürgen



I cannot get either one to compile.

--
Julien

Patch for #8408

[Julien Rioux]

How do people feel about the patch attached to ticket 
http://www.lyx.org/trac/ticket/8408 Additional support for Japanese 
pLaTeX with utf8 encoding ?


Direct link to the patch: 
http://www.lyx.org/trac/attachment/ticket/8408/0001-Use-the-LyX-name-of-encodings-instead-of-the-LaTeX-n.patch


--
Julien

Patch for #8408

[Julien Rioux]

How do people feel about the patch attached to ticket 
http://www.lyx.org/trac/ticket/8408 "Additional support for Japanese 
pLaTeX with utf8 encoding" ?


Direct link to the patch: 
http://www.lyx.org/trac/attachment/ticket/8408/0001-Use-the-LyX-name-of-encodings-instead-of-the-LaTeX-n.patch


--
Julien

Re: trunk no longer compilable

[Julien Rioux]

On Fri, Jan 25, 2013 at 5:36 PM, Uwe Stöhr uwesto...@web.de wrote:
 Am 25.01.2013 08:39, schrieb Kornel Benko:

 This for sure is not my doing. Looks, like your compiler/linker
 finds lyx::Encoding::any in Encoding.obj and BiblioInfo.obj.

 The last change was Jan 19 by Julien Rioux.


 Thanks for the pointer. This was indeed the bug and I corrected this now:
 http://www.lyx.org/trac/changeset/9e29dc2338842568de166cef8cee88de9210a84b/lyxgit

 thanks and regards
 Uwe


Your latest change break the compilation for me, while I had no
compilation problem beforehand:

make[5]: Entering directory `/home/jrioux/git/lyx/build-dirac/src'
  CXXEncoding.o
  AR liblyxcore.a
  CXXBiblioInfo.o
  CXXLD  lyx
liblyxcore.a(BufferParams.o): In function `lyx::BufferParams::encoding() const':
/home/jrioux/git/lyx/build-dirac/src/../../src/BufferParams.cpp:2916:
undefined reference to `lyx::Encoding::any'
/home/jrioux/git/lyx/build-dirac/src/../../src/BufferParams.cpp:2919:
undefined reference to `lyx::Encoding::any'
collect2: ld returned 1 exit status

I compile with autotools and gcc 4.6.2, and you?

Regards,
Julien

Re: trunk no longer compilable

[Julien Rioux]

On Fri, Jan 25, 2013 at 6:05 PM, Vincent van Ravesteijn v...@lyx.org wrote:

 Op 25 jan. 2013 23:51 schreef Julien Rioux jri...@lyx.org het volgende:



 On Fri, Jan 25, 2013 at 5:36 PM, Uwe Stöhr uwesto...@web.de wrote:
  Am 25.01.2013 08:39, schrieb Kornel Benko:
 
  This for sure is not my doing. Looks, like your compiler/linker
  finds lyx::Encoding::any in Encoding.obj and BiblioInfo.obj.
 
  The last change was Jan 19 by Julien Rioux.
 
 
  Thanks for the pointer. This was indeed the bug and I corrected this
  now:
 
  http://www.lyx.org/trac/changeset/9e29dc2338842568de166cef8cee88de9210a84b/lyxgit
 
  thanks and regards
  Uwe
 

 Your latest change break the compilation for me, while I had no
 compilation problem beforehand:

 make[5]: Entering directory `/home/jrioux/git/lyx/build-dirac/src'
   CXXEncoding.o
   AR liblyxcore.a
   CXXBiblioInfo.o
   CXXLD  lyx
 liblyxcore.a(BufferParams.o): In function `lyx::BufferParams::encoding()
 const':
 /home/jrioux/git/lyx/build-dirac/src/../../src/BufferParams.cpp:2916:
 undefined reference to `lyx::Encoding::any'
 /home/jrioux/git/lyx/build-dirac/src/../../src/BufferParams.cpp:2919:
 undefined reference to `lyx::Encoding::any'
 collect2: ld returned 1 exit status

 I compile with autotools and gcc 4.6.2, and you?

 Regards,
 Julien

 Uwe is using the merged build. Please revert this last change. And fix this
 without breaking compilation for others.

 I strongly advice not to use the merged build, especially if you don't
 understand the stuff and expect others to fix it.

 Vincent

Not sure if this was really meant towards me or if a cc:lyx-devel was
missing. I honestly don't know much C++ in details, so it is possible
that I broke something. In this case I would of course look to resolve
the situation, but it's hard for me to debug the problem Uwe was
having since I don't see it.

Regards,
Julien

Re: trunk no longer compilable

[Julien Rioux]

On Fri, Jan 25, 2013 at 5:36 PM, Uwe Stöhr <uwesto...@web.de> wrote:
> Am 25.01.2013 08:39, schrieb Kornel Benko:
>
>> This for sure is not my doing. Looks, like your compiler/linker
>> finds "lyx::Encoding::any" in Encoding.obj and BiblioInfo.obj.
>>
>> The last change was Jan 19 by Julien Rioux.
>
>
> Thanks for the pointer. This was indeed the bug and I corrected this now:
> http://www.lyx.org/trac/changeset/9e29dc2338842568de166cef8cee88de9210a84b/lyxgit
>
> thanks and regards
> Uwe
>

Your latest change break the compilation for me, while I had no
compilation problem beforehand:

make[5]: Entering directory `/home/jrioux/git/lyx/build-dirac/src'
  CXXEncoding.o
  AR liblyxcore.a
  CXXBiblioInfo.o
  CXXLD  lyx
liblyxcore.a(BufferParams.o): In function `lyx::BufferParams::encoding() const':
/home/jrioux/git/lyx/build-dirac/src/../../src/BufferParams.cpp:2916:
undefined reference to `lyx::Encoding::any'
/home/jrioux/git/lyx/build-dirac/src/../../src/BufferParams.cpp:2919:
undefined reference to `lyx::Encoding::any'
collect2: ld returned 1 exit status

I compile with autotools and gcc 4.6.2, and you?

Regards,
Julien

Re: trunk no longer compilable

[Julien Rioux]

On Fri, Jan 25, 2013 at 6:05 PM, Vincent van Ravesteijn <v...@lyx.org> wrote:
>
> Op 25 jan. 2013 23:51 schreef "Julien Rioux" <jri...@lyx.org> het volgende:
>
>
>>
>> On Fri, Jan 25, 2013 at 5:36 PM, Uwe Stöhr <uwesto...@web.de> wrote:
>> > Am 25.01.2013 08:39, schrieb Kornel Benko:
>> >
>> >> This for sure is not my doing. Looks, like your compiler/linker
>> >> finds "lyx::Encoding::any" in Encoding.obj and BiblioInfo.obj.
>> >>
>> >> The last change was Jan 19 by Julien Rioux.
>> >
>> >
>> > Thanks for the pointer. This was indeed the bug and I corrected this
>> > now:
>> >
>> > http://www.lyx.org/trac/changeset/9e29dc2338842568de166cef8cee88de9210a84b/lyxgit
>> >
>> > thanks and regards
>> > Uwe
>> >
>>
>> Your latest change break the compilation for me, while I had no
>> compilation problem beforehand:
>>
>> make[5]: Entering directory `/home/jrioux/git/lyx/build-dirac/src'
>>   CXXEncoding.o
>>   AR liblyxcore.a
>>   CXXBiblioInfo.o
>>   CXXLD  lyx
>> liblyxcore.a(BufferParams.o): In function `lyx::BufferParams::encoding()
>> const':
>> /home/jrioux/git/lyx/build-dirac/src/../../src/BufferParams.cpp:2916:
>> undefined reference to `lyx::Encoding::any'
>> /home/jrioux/git/lyx/build-dirac/src/../../src/BufferParams.cpp:2919:
>> undefined reference to `lyx::Encoding::any'
>> collect2: ld returned 1 exit status
>>
>> I compile with autotools and gcc 4.6.2, and you?
>>
>> Regards,
>> Julien
>
> Uwe is using the merged build. Please revert this last change. And fix this
> without breaking compilation for others.
>
> I strongly advice not to use the merged build, especially if you don't
> understand the stuff and expect others to fix it.
>
> Vincent

Not sure if this was really meant towards me or if a cc:lyx-devel was
missing. I honestly don't know much C++ in details, so it is possible
that I broke something. In this case I would of course look to resolve
the situation, but it's hard for me to debug the problem Uwe was
having since I don't see it.

Regards,
Julien

Re: [LyX master] chkconfig.ltx: correct check for cbgreek

[Julien Rioux]

On Wed, Jan 23, 2013 at 3:54 PM, Uwe Stöhr uwesto...@lyx.org wrote:
 The branch, master, has been updated.

 - Log -

 commit 6958af5979839aa4730d3270b0187413a7989631
 Author: Uwe Stöhr uwesto...@lyx.org
 Date:   Wed Jan 23 21:54:48 2013 +0100

 chkconfig.ltx: correct check for cbgreek

 fixes #8522

 diff --git a/lib/chkconfig.ltx b/lib/chkconfig.ltx
 index 76ece71..3c170c8 100644
 --- a/lib/chkconfig.ltx
 +++ b/lib/chkconfig.ltx
 @@ -400,7 +400,7 @@
  \TestPackage{ae}
  \TestPackage{bera}
  \TestPackage{biolinum-type1}
 -\TestPackage{cbgreek}% for Greek
 +\TestPackage[glic1000]{cbgreek}% for Greek

.tfm missing?

--
Julien

Re: [LyX master] chkconfig.ltx: correct check for cbgreek

[Julien Rioux]

On Wed, Jan 23, 2013 at 3:54 PM, Uwe Stöhr  wrote:
> The branch, master, has been updated.
>
> - Log -
>
> commit 6958af5979839aa4730d3270b0187413a7989631
> Author: Uwe Stöhr 
> Date:   Wed Jan 23 21:54:48 2013 +0100
>
> chkconfig.ltx: correct check for cbgreek
>
> fixes #8522
>
> diff --git a/lib/chkconfig.ltx b/lib/chkconfig.ltx
> index 76ece71..3c170c8 100644
> --- a/lib/chkconfig.ltx
> +++ b/lib/chkconfig.ltx
> @@ -400,7 +400,7 @@
>  \TestPackage{ae}
>  \TestPackage{bera}
>  \TestPackage{biolinum-type1}
> -\TestPackage{cbgreek}% for Greek
> +\TestPackage[glic1000]{cbgreek}% for Greek

.tfm missing?

--
Julien

Re: [LyX 2.0.x] de.po: update

[Julien Rioux]

On 17/01/2013 11:43 AM, Jürgen Spitzmüller wrote:

Julien Rioux wrote:

-   if (authors.size() == 2)
-   return bformat(translateIfPossible(from_ascii(%1$s and %2$s), 
lang),
+   if (authors.size() == 2  authors[1] != others)
+   return bformat(from_ascii(%1$s and %2$s),

familyName(authors[0]), familyName(authors[1]));

-   if (authors.size()  2)
-   return bformat(translateIfPossible(from_ascii(%1$s et al.), 
lang),
+   if (authors.size() = 2)
+   return bformat(from_ascii(%1$s et al.),

familyName(authors[0]));


Shouldn't these be translated as well?

Jürgen



Why?

--
Julien

Re: [LyX 2.0.x] de.po: update

[Julien Rioux]

On 17/01/2013 12:08 PM, Jürgen Spitzmüller wrote:

Julien Rioux wrote:

Why?


Why not? Where are these strings used?

Jürgen



1) Used for sorting the bib entries.
2) Used as starting point for the translated version of these strings, a 
few lines below in the diff, to avoid duplicating the code.


getAbbreviatedAuthor()- English, for sorting
getAbbreviatedAuthor(buf) - translated to buffer language

--
Julien

Re: [LyX 2.0.x] de.po: update

[Julien Rioux]

On 17/01/2013 11:43 AM, Jürgen Spitzmüller wrote:

Julien Rioux wrote:

-   if (authors.size() == 2)
-   return bformat(translateIfPossible(from_ascii("%1$s and %2$s"), 
lang),
+   if (authors.size() == 2 && authors[1] != "others")
+   return bformat(from_ascii("%1$s and %2$s"),

familyName(authors[0]), familyName(authors[1]));

-   if (authors.size() > 2)
-   return bformat(translateIfPossible(from_ascii("%1$s et al."), 
lang),
+   if (authors.size() >= 2)
+   return bformat(from_ascii("%1$s et al."),

familyName(authors[0]));


Shouldn't these be translated as well?

Jürgen



Why?

--
Julien

Re: [LyX 2.0.x] de.po: update

[Julien Rioux]

On 17/01/2013 12:08 PM, Jürgen Spitzmüller wrote:

Julien Rioux wrote:

Why?


Why not? Where are these strings used?

Jürgen



1) Used for sorting the bib entries.
2) Used as starting point for the translated version of these strings, a 
few lines below in the diff, to avoid duplicating the code.


getAbbreviatedAuthor()-> English, for sorting
getAbbreviatedAuthor(buf) -> translated to buffer language

--
Julien

Re: [LyX 2.0.x] de.po: update

[Julien Rioux]

On Tue, Jan 15, 2013 at 10:07 AM, Richard Heck rgh...@lyx.org wrote:
 On 01/14/2013 05:16 PM, Julien Rioux wrote:

 On 12/01/2013 11:34 AM, Jürgen Spitzmüller wrote:

 Julien Rioux wrote:

 The goal is to translate these strings (using mo database) to the
 document language.


 Then Buffer::B_() is the correct approach.

 Jürgen


 Does something like the attached patch (for branch) look OK?

 Is this the one that's needed for the other one? If so, fine.

 rh


It is needed for http://www.lyx.org/trac/ticket/7732, because
Buffer.B_() should be used instead of translateIfPossible(). I have
fixed this in master at
http://www.lyx.org/trac/changeset/3f8de8fe92f586b8c206b88a76139de3d6369dfe/lyxgit

Here's an updated version for branch. I'll commit this in 48 hours if
nobody objects.

Cheers,
Julien


0001-Better-fix-for-7732-Use-buffer.B_.patch
Description: Binary data

Re: [LyX 2.0.x] de.po: update

[Julien Rioux]

On 15/01/2013 3:18 PM, Georg Baum wrote:

Julien Rioux wrote:


On 12/01/2013 11:34 AM, Jürgen Spitzmüller wrote:

Julien Rioux wrote:

The goal is to translate these strings (using mo database) to the
document language.


Then Buffer::B_() is the correct approach.

Jürgen



Thank you, I'll try that.


In case it is not clear already: The various *_() methods accept only ASCII
input, so they must not be used if the input may come from user supplied
files. translateIfPossible() should be used in that case. Where do the
strings you are translating come from?


Georg





Thanks for clarifying. The strings are in the C++ source and not 
user-supplied, thus I made the change to use Buffer().B_() at 
http://www.lyx.org/trac/changeset/3f8de8fe92f586b8c206b88a76139de3d6369dfe/lyxgit


Cheers,
Julien

Re: [LyX 2.0.x] de.po: update

[Julien Rioux]

On Tue, Jan 15, 2013 at 10:07 AM, Richard Heck <rgh...@lyx.org> wrote:
> On 01/14/2013 05:16 PM, Julien Rioux wrote:
>>
>> On 12/01/2013 11:34 AM, Jürgen Spitzmüller wrote:
>>>
>>> Julien Rioux wrote:
>>>>
>>>> The goal is to translate these strings (using mo database) to the
>>>> document language.
>>>
>>>
>>> Then Buffer::B_() is the correct approach.
>>>
>>> Jürgen
>>>
>>
>> Does something like the attached patch (for branch) look OK?
>>
> Is this the one that's needed for the other one? If so, fine.
>
> rh
>

It is needed for http://www.lyx.org/trac/ticket/7732, because
Buffer.B_() should be used instead of translateIfPossible(). I have
fixed this in master at
http://www.lyx.org/trac/changeset/3f8de8fe92f586b8c206b88a76139de3d6369dfe/lyxgit

Here's an updated version for branch. I'll commit this in 48 hours if
nobody objects.

Cheers,
Julien


0001-Better-fix-for-7732-Use-buffer.B_.patch
Description: Binary data

Re: [LyX 2.0.x] de.po: update

[Julien Rioux]

On 15/01/2013 3:18 PM, Georg Baum wrote:

Julien Rioux wrote:


On 12/01/2013 11:34 AM, Jürgen Spitzmüller wrote:

Julien Rioux wrote:

The goal is to translate these strings (using mo database) to the
document language.


Then Buffer::B_() is the correct approach.

Jürgen



Thank you, I'll try that.


In case it is not clear already: The various *_() methods accept only ASCII
input, so they must not be used if the input may come from user supplied
files. translateIfPossible() should be used in that case. Where do the
strings you are translating come from?


Georg





Thanks for clarifying. The strings are in the C++ source and not 
user-supplied, thus I made the change to use Buffer().B_() at 
http://www.lyx.org/trac/changeset/3f8de8fe92f586b8c206b88a76139de3d6369dfe/lyxgit


Cheers,
Julien

Re: [LyX 2.0.x] de.po: update

[Julien Rioux]

On 12/01/2013 11:34 AM, Jürgen Spitzmüller wrote:

Julien Rioux wrote:

The goal is to translate these strings (using mo database) to the
document language.


Then Buffer::B_() is the correct approach.

Jürgen



Does something like the attached patch (for branch) look OK?

Regards,
Julien
From a8f5a42b4c27cf2c6405c023cbb13ab519336853 Mon Sep 17 00:00:00 2001
From: Julien Rioux jri...@lyx.org
Date: Mon, 14 Jan 2013 15:25:26 +0100
Subject: [PATCH] Better fix for #7732: Use buffer.B_().

---
 src/BiblioInfo.cpp   |   49 ++
 src/BiblioInfo.h |   20 +---
 src/insets/InsetBibtex.cpp   |4 +-
 src/insets/InsetCitation.cpp |6 +---
 4 files changed, 55 insertions(+), 24 deletions(-)

diff --git a/src/BiblioInfo.cpp b/src/BiblioInfo.cpp
index cd707c1..43b8662 100644
--- a/src/BiblioInfo.cpp
+++ b/src/BiblioInfo.cpp
@@ -212,7 +212,7 @@ BibTeXInfo::BibTeXInfo(docstring const  key, docstring const  type)
 {}
 
 
-docstring const BibTeXInfo::getAbbreviatedAuthor(string lang) const
+docstring const BibTeXInfo::getAbbreviatedAuthor() const
 {
 	if (!is_bibtex_) {
 		docstring const opt = label();
@@ -244,17 +244,31 @@ docstring const BibTeXInfo::getAbbreviatedAuthor(string lang) const
 		getVectorFromString(author, from_ascii( and ));
 
 	if (authors.size() == 2)
-		return bformat(translateIfPossible(from_ascii(%1$s and %2$s), lang),
+		return bformat(from_ascii(%1$s and %2$s),
 			familyName(authors[0]), familyName(authors[1]));
 
 	if (authors.size()  2)
-		return bformat(translateIfPossible(from_ascii(%1$s et al.), lang),
+		return bformat(from_ascii(%1$s and others),
 			familyName(authors[0]));
 
 	return familyName(authors[0]);
 }
 
 
+docstring const BibTeXInfo::getAbbreviatedAuthor(Buffer const  buf) const
+{
+	docstring const author = getAbbreviatedAuthor();
+	if (!is_bibtex_)
+		return author;
+	vectordocstring const authors = getVectorFromString(author, from_ascii( and ));
+	if (authors.size() == 2  authors[1] == others)
+		return bformat(buf.B_(%1$s et al.), authors[0]);
+	if (authors.size() == 2)
+		return bformat(buf.B_(%1$s and %2$s), authors[0], authors[1]);
+	return author;
+}
+
+
 docstring const BibTeXInfo::getYear() const
 {
 	if (is_bibtex_) 
@@ -635,13 +649,13 @@ vectordocstring const BiblioInfo::getEntries() const
 }
 
 
-docstring const BiblioInfo::getAbbreviatedAuthor(docstring const  key, string lang) const
+docstring const BiblioInfo::getAbbreviatedAuthor(docstring const  key, Buffer const  buf) const
 {
 	BiblioInfo::const_iterator it = find(key);
 	if (it == end())
 		return docstring();
 	BibTeXInfo const  data = it-second;
-	return data.getAbbreviatedAuthor(lang);
+	return data.getAbbreviatedAuthor(buf);
 }
 
 
@@ -655,7 +669,7 @@ docstring const BiblioInfo::getCiteNumber(docstring const  key) const
 }
 
 
-docstring const BiblioInfo::getYear(docstring const  key, bool use_modifier, string lang) const
+docstring const BiblioInfo::getYear(docstring const  key, bool use_modifier) const
 {
 	BiblioInfo::const_iterator it = find(key);
 	if (it == end())
@@ -667,11 +681,11 @@ docstring const BiblioInfo::getYear(docstring const  key, bool use_modifier, st
 		docstring const xref = data.getXRef();
 		if (xref.empty())
 			// no luck
-			return translateIfPossible(from_ascii(No year), lang);
+			return docstring();
 		BiblioInfo::const_iterator const xrefit = find(xref);
 		if (xrefit == end())
 			// no luck again
-			return translateIfPossible(from_ascii(No year), lang);
+			return docstring();
 		BibTeXInfo const  xref_data = xrefit-second;
 		year = xref_data.getYear();
 	}
@@ -681,6 +695,15 @@ docstring const BiblioInfo::getYear(docstring const  key, bool use_modifier, st
 }
 
 
+docstring const BiblioInfo::getYear(docstring const  key, Buffer const  buf, bool use_modifier) const
+{
+	docstring const year = getYear(key, use_modifier);
+	if (year.empty())
+		return buf.B_(No year);
+	return year;
+}
+
+
 docstring const BiblioInfo::getInfo(docstring const  key, 
 	Buffer const  buf, bool richtext) const
 {
@@ -726,9 +749,8 @@ vectordocstring const BiblioInfo::getNumericalStrings(
 	if (empty())
 		return vectordocstring();
 
-	string const lang = buf.params().language-code();
-	docstring const author = getAbbreviatedAuthor(key, lang);
-	docstring const year   = getYear(key, true, lang);
+	docstring const author = getAbbreviatedAuthor(key, buf);
+	docstring const year   = getYear(key, buf, true);
 	if (author.empty() || year.empty())
 		return vectordocstring();
 
@@ -786,9 +808,8 @@ vectordocstring const BiblioInfo::getAuthorYearStrings(
 	if (empty())
 		return vectordocstring();
 
-	string const lang = buf.params().language-code();
-	docstring const author = getAbbreviatedAuthor(key, lang);
-	docstring const year   = getYear(key, true, lang);
+	docstring const author = getAbbreviatedAuthor(key, buf);
+	docstring const year   = getYear(key, buf, true);
 	if (author.empty() || year.empty())
 		return

Re: [LyX 2.0.x] de.po: update

[Julien Rioux]

On 12/01/2013 11:34 AM, Jürgen Spitzmüller wrote:

Julien Rioux wrote:

The goal is to translate these strings (using mo database) to the
document language.


Then Buffer::B_() is the correct approach.

Jürgen



Does something like the attached patch (for branch) look OK?

Regards,
Julien
>From a8f5a42b4c27cf2c6405c023cbb13ab519336853 Mon Sep 17 00:00:00 2001
From: Julien Rioux <jri...@lyx.org>
Date: Mon, 14 Jan 2013 15:25:26 +0100
Subject: [PATCH] Better fix for #7732: Use buffer.B_().

---
 src/BiblioInfo.cpp   |   49 ++
 src/BiblioInfo.h |   20 +---
 src/insets/InsetBibtex.cpp   |4 +-
 src/insets/InsetCitation.cpp |6 +---
 4 files changed, 55 insertions(+), 24 deletions(-)

diff --git a/src/BiblioInfo.cpp b/src/BiblioInfo.cpp
index cd707c1..43b8662 100644
--- a/src/BiblioInfo.cpp
+++ b/src/BiblioInfo.cpp
@@ -212,7 +212,7 @@ BibTeXInfo::BibTeXInfo(docstring const & key, docstring const & type)
 {}
 
 
-docstring const BibTeXInfo::getAbbreviatedAuthor(string lang) const
+docstring const BibTeXInfo::getAbbreviatedAuthor() const
 {
 	if (!is_bibtex_) {
 		docstring const opt = label();
@@ -244,17 +244,31 @@ docstring const BibTeXInfo::getAbbreviatedAuthor(string lang) const
 		getVectorFromString(author, from_ascii(" and "));
 
 	if (authors.size() == 2)
-		return bformat(translateIfPossible(from_ascii("%1$s and %2$s"), lang),
+		return bformat(from_ascii("%1$s and %2$s"),
 			familyName(authors[0]), familyName(authors[1]));
 
 	if (authors.size() > 2)
-		return bformat(translateIfPossible(from_ascii("%1$s et al."), lang),
+		return bformat(from_ascii("%1$s and others"),
 			familyName(authors[0]));
 
 	return familyName(authors[0]);
 }
 
 
+docstring const BibTeXInfo::getAbbreviatedAuthor(Buffer const & buf) const
+{
+	docstring const author = getAbbreviatedAuthor();
+	if (!is_bibtex_)
+		return author;
+	vector const authors = getVectorFromString(author, from_ascii(" and "));
+	if (authors.size() == 2 && authors[1] == "others")
+		return bformat(buf.B_("%1$s et al."), authors[0]);
+	if (authors.size() == 2)
+		return bformat(buf.B_("%1$s and %2$s"), authors[0], authors[1]);
+	return author;
+}
+
+
 docstring const BibTeXInfo::getYear() const
 {
 	if (is_bibtex_) 
@@ -635,13 +649,13 @@ vector const BiblioInfo::getEntries() const
 }
 
 
-docstring const BiblioInfo::getAbbreviatedAuthor(docstring const & key, string lang) const
+docstring const BiblioInfo::getAbbreviatedAuthor(docstring const & key, Buffer const & buf) const
 {
 	BiblioInfo::const_iterator it = find(key);
 	if (it == end())
 		return docstring();
 	BibTeXInfo const & data = it->second;
-	return data.getAbbreviatedAuthor(lang);
+	return data.getAbbreviatedAuthor(buf);
 }
 
 
@@ -655,7 +669,7 @@ docstring const BiblioInfo::getCiteNumber(docstring const & key) const
 }
 
 
-docstring const BiblioInfo::getYear(docstring const & key, bool use_modifier, string lang) const
+docstring const BiblioInfo::getYear(docstring const & key, bool use_modifier) const
 {
 	BiblioInfo::const_iterator it = find(key);
 	if (it == end())
@@ -667,11 +681,11 @@ docstring const BiblioInfo::getYear(docstring const & key, bool use_modifier, st
 		docstring const xref = data.getXRef();
 		if (xref.empty())
 			// no luck
-			return translateIfPossible(from_ascii("No year"), lang);
+			return docstring();
 		BiblioInfo::const_iterator const xrefit = find(xref);
 		if (xrefit == end())
 			// no luck again
-			return translateIfPossible(from_ascii("No year"), lang);
+			return docstring();
 		BibTeXInfo const & xref_data = xrefit->second;
 		year = xref_data.getYear();
 	}
@@ -681,6 +695,15 @@ docstring const BiblioInfo::getYear(docstring const & key, bool use_modifier, st
 }
 
 
+docstring const BiblioInfo::getYear(docstring const & key, Buffer const & buf, bool use_modifier) const
+{
+	docstring const year = getYear(key, use_modifier);
+	if (year.empty())
+		return buf.B_("No year");
+	return year;
+}
+
+
 docstring const BiblioInfo::getInfo(docstring const & key, 
 	Buffer const & buf, bool richtext) const
 {
@@ -726,9 +749,8 @@ vector const BiblioInfo::getNumericalStrings(
 	if (empty())
 		return vector();
 
-	string const lang = buf.params().language->code();
-	docstring const author = getAbbreviatedAuthor(key, lang);
-	docstring const year   = getYear(key, true, lang);
+	docstring const author = getAbbreviatedAuthor(key, buf);
+	docstring const year   = getYear(key, buf, true);
 	if (author.empty() || year.empty())
 		return vector();
 
@@ -786,9 +808,8 @@ vector const BiblioInfo::getAuthorYearStrings(
 	if (empty())
 		return vector();
 
-	string const lang = buf.params().language->code();
-	docstring const author = getAbbreviatedAuthor(key, lang);
-	docstring co

Position of Custom InsetLayout Arguments in Insert menu

[Julien Rioux]

Custom InsetLayout X has an Argument Y. We have:

Insert  Custom  X, but
Insert  Y

I think both X and Y should appear under Insert  Custom.

Agreed?

Julien

Re: Position of Custom InsetLayout Arguments in Insert menu

[Julien Rioux]

On 12/01/2013 4:54 AM, Jürgen Spitzmüller wrote:

Julien Rioux wrote:

I think both X and Y should appear under Insert  Custom.

Agreed?


If you refer to InsetArgument: No.
All arguments should appear at the same place, namely the inset top level
menu.

Actually, I think that the Custom submenu is horrible UI design. Likewise
Edit  charstyle.

Jürgen



Should we kill the Custom submenu then?

--
Julien

Re: [LyX 2.0.x] Force BibTeX rerun upon add/remove/change citation (fixes #6955).

[Julien Rioux]

On 12/01/2013 10:44 AM, Jürgen Spitzmüller wrote:

Julien Rioux wrote:

The branch, 2.0.x, has been updated.


insets/InsetCitation.cpp: In constructor
‘lyx::InsetCitation::InsetCitation(lyx::Buffer*, const
lyx::InsetCommandParams)’:
insets/InsetCitation.cpp:49:11: error: ‘class lyx::Buffer’ has no member named
‘removeBiblioTempFiles’
insets/InsetCitation.cpp: In destructor ‘virtual
lyx::InsetCitation::~InsetCitation()’:
insets/InsetCitation.cpp:56:12: error: ‘class lyx::Buffer’ has no member named
‘removeBiblioTempFiles’
insets/InsetCitation.cpp: In member function ‘virtual void
lyx::InsetCitation::doDispatch(lyx::Cursor, lyx::FuncRequest)’:
insets/InsetCitation.cpp:117:12: error: ‘class lyx::Buffer’ has no member
named ‘removeBiblioTempFiles’
make[4]: *** [InsetCitation.o] Fehler 1
make[4]: Leaving directory `/home/juergen/lyx/lyx-stable/src'
make[3]: *** [all-recursive] Fehler 1
make[3]: Leaving directory `/home/juergen/lyx/lyx-stable/src'
make[2]: *** [all] Fehler 2
make[2]: Leaving directory `/home/juergen/lyx/lyx-stable/src'
make[1]: *** [all-recursive] Fehler 1
make[1]: Leaving directory `/home/juergen/lyx/lyx-stable'
make: *** [all] Fehler 2

Jürgen



Sorry, I pushed too soon.

--
Julien

Re: [LyX 2.0.x] Force BibTeX rerun upon add/remove/change citation (fixes #6955).

[Julien Rioux]

On 12/01/2013 10:48 AM, Richard Heck wrote:

On 01/12/2013 10:44 AM, Jürgen Spitzmüller wrote:

Julien Rioux wrote:

The branch, 2.0.x, has been updated.

insets/InsetCitation.cpp: In constructor
‘lyx::InsetCitation::InsetCitation(lyx::Buffer*, const
lyx::InsetCommandParams)’:
insets/InsetCitation.cpp:49:11: error: ‘class lyx::Buffer’ has no
member named
‘removeBiblioTempFiles’
insets/InsetCitation.cpp: In destructor ‘virtual
lyx::InsetCitation::~InsetCitation()’:
insets/InsetCitation.cpp:56:12: error: ‘class lyx::Buffer’ has no
member named
‘removeBiblioTempFiles’
insets/InsetCitation.cpp: In member function ‘virtual void
lyx::InsetCitation::doDispatch(lyx::Cursor, lyx::FuncRequest)’:
insets/InsetCitation.cpp:117:12: error: ‘class lyx::Buffer’ has no member
named ‘removeBiblioTempFiles’
make[4]: *** [InsetCitation.o] Fehler 1
make[4]: Leaving directory `/home/juergen/lyx/lyx-stable/src'
make[3]: *** [all-recursive] Fehler 1
make[3]: Leaving directory `/home/juergen/lyx/lyx-stable/src'
make[2]: *** [all] Fehler 2
make[2]: Leaving directory `/home/juergen/lyx/lyx-stable/src'
make[1]: *** [all-recursive] Fehler 1
make[1]: Leaving directory `/home/juergen/lyx/lyx-stable'
make: *** [all] Fehler 2


Looks like we need part of e93092e7, as well, Julien. I think that will
be OK. We can test it and, if not, roll it back out.

Richard



Thanks, I'm test compiling it right now.
--
Julien

Re: [LyX 2.0.x] de.po: update

[Julien Rioux]

On Sat, Jan 12, 2013 at 10:54 AM, Juergen Spitzmueller sp...@lyx.org wrote:
 The branch, 2.0.x, has been updated.

 - Log -

 commit e5a40e9616d4ab82ed092de22bdc8969eedfc051
 Author: Juergen Spitzmueller sp...@lyx.org
 Date:   Sat Jan 12 16:54:11 2013 +0100

 de.po: update

 diff --git a/po/de.po b/po/de.po
 index 71cb1ab..d5960a7 100644
 --- a/po/de.po
 +++ b/po/de.po
 @@ -95,8 +95,8 @@ msgid 
  msgstr 
  Project-Id-Version: LyX 2.0\n
  Report-Msgid-Bugs-To: lyx-devel@lists.lyx.org\n
 -POT-Creation-Date: 2013-01-03 12:06-0500\n
 -PO-Revision-Date: 2013-01-04 13:49+0100\n
 +POT-Creation-Date: 2013-01-12 16:52+0100\n
 +PO-Revision-Date: 2013-01-12 16:53+0100\n
  Last-Translator: Jürgen Spitzmüller sp...@lyx.org\n
  Language-Team: German lyx-d...@lists.lyx.org\n
  Language: de\n
 @@ -2247,7 +2247,7 @@ msgid Feedback window
  msgstr Feedback-Fenster

  #: src/frontends/qt4/ui/ListingsUi.ui:13 src/insets/InsetCaption.cpp:332
 -#: src/insets/InsetListings.cpp:351 src/insets/InsetListings.cpp:353
 +#: src/insets/InsetListings.cpp:352 src/insets/InsetListings.cpp:354
  msgid Listing
  msgstr Listing

 @@ -11154,7 +11154,7 @@ msgstr 
  msgid 
  This module adds support for using natbib together with apacite (the 
  bibliography style need not be apacite--it could be apacite, apacitex, or 
 -any bibliography that works with both the natbib and apacite packages.
 +any bibliography that works with both the natbib and apacite packages.)
  msgstr 
  Dieses Modul bietet Unterstützung für die Verwendung von Natbib zusammen 
 mit 
  Apacite. Der Bibliographiestil muss dabei nicht 'apacite' sein, auch 
 @@ -17124,30 +17124,16 @@ msgstr LyX-Archiv (zip)
  msgid LyX Archive (tar.gz)
  msgstr LyX-Archiv (tar.gz)

 -#: src/BiblioInfo.cpp:247 src/frontends/qt4/GuiDocument.cpp:1973
 -#, c-format
 -msgid %1$s and %2$s
 -msgstr %1$s und %2$s
 -
 -#: src/BiblioInfo.cpp:251
 -#, c-format
 -msgid %1$s et al.
 -msgstr %1$s et al.
 -

Hmmm, this removal is surely caused by
http://www.lyx.org/trac/changeset/62b131975244d6f389d2c2c43bf8a982a057f00f/lyxgit
... but for the fix to be effective, the translations should remain
available in the po file for these strings.t I guess gettext does not
catch them anymore? Can we force gettext to catch strings inside
translateIfPossible()?

Regards,
Julien

Re: [LyX 2.0.x] de.po: update

[Julien Rioux]

On 12/01/2013 11:19 AM, Jürgen Spitzmüller wrote:

Julien Rioux wrote:

Hmmm, this removal is surely caused by
http://www.lyx.org/trac/changeset/62b131975244d6f389d2c2c43bf8a982a057f00f/l
yxgit ... but for the fix to be effective, the translations should remain
available in the po file for these strings.t I guess gettext does not catch
them anymore? Can we force gettext to catch strings inside
translateIfPossible()?


Are you sure you wanted to use translateIfPossible()?


No.


Or rather buffer().B_()?



Maybe.

The goal is to translate these strings (using mo database) to the 
document language. At the moment this is done by passing the doc 
language as argument to getAbbreviatedAuthor etc.


--
Julien