Re: Bug in 2.0RC1? language changing change the language of already written text.

2011-03-09 Thread Jean-Marc Lasgouttes

Le 09/03/2011 07:24, Stephan Witt a écrit :

Ah, ok - I didn't thought of that. But it's not exactly the same.
When in front of a word the selection is not done too. That raises the
question if it's better or not to use WHOLE_WORD_STRICT...
When entering hebrew text is the word end at from() or at the to() pos?


Note that this is what is used for fonts in Text::toggleFree. I would 
think the two actions should behave similarly.


JMarc


Re: compile 2.0rc1 on mac

2011-03-09 Thread Jean-Marc Lasgouttes

Le 09/03/2011 07:40, Stephan Witt a écrit :

I think it was correct, but here is nevertheless a more idiomatic version (that 
subsumes José's patch too).


The problem was: the result of header presence detection - aka missing header 
is respected by the first test for the library but not by the second test.


I meant: I think _your_patch_ was correct.

JMarc


.odt - .lyx

2011-03-09 Thread Tommaso Cucinotta

Hi,

I need to convert a paper from .odt to .lyx for building an extended 
version (exact style unimportant -- I'll have to change the style 
anyway, but there are pictures and references [xrefs to numbered 
bullets] which I'd be happy to preserve). Is there any good resource 
describing how to proceed and what tools have the best chance ?


T.



Re: .odt - .lyx

2011-03-09 Thread Richard Heck

On 03/09/2011 05:27 AM, Tommaso Cucinotta wrote:

Hi,

I need to convert a paper from .odt to .lyx for building an extended 
version (exact style unimportant -- I'll have to change the style 
anyway, but there are pictures and references [xrefs to numbered 
bullets] which I'd be happy to preserve). Is there any good resource 
describing how to proceed and what tools have the best chance ?


The only option I know, realistically, is: Load the file in OOo and 
export it as LaTeX. Then load the LaTeX file into LyX.


Richard



Re: Bug in 2.0RC1? language changing change the language of already written text.

2011-03-09 Thread Stephan Witt
Am 09.03.2011 um 10:29 schrieb Jean-Marc Lasgouttes:

 Le 09/03/2011 07:24, Stephan Witt a écrit :
 Ah, ok - I didn't thought of that. But it's not exactly the same.
 When in front of a word the selection is not done too. That raises the
 question if it's better or not to use WHOLE_WORD_STRICT...
 When entering hebrew text is the word end at from() or at the to() pos?
 
 Note that this is what is used for fonts in Text::toggleFree. I would think 
 the two actions should behave similarly.

I did it that way. I had a positive feedback from Ronen. (Thanks for that.)

Stephan



Re: compile 2.0rc1 on mac

2011-03-09 Thread José Matos
On Tuesday 08 March 2011 22:06:36 Jean-Marc Lasgouttes wrote:
 Please and commit if it works also for you.
 José, if you have time, please test it too !
 
 JMarc

Yep, it works for me. Thank you Stephan. :-)

-- 
José Abílio


Re: Towards rc1 (status update #4, trunk frozen)

2011-03-09 Thread Anders Ekberg
Done, Ticket #7349

/Anders

On 2011-03-08 10.13, Pavel Sanda sa...@lyx.org wrote:

Stephan Witt wrote:
 But I tried to verify it on Linux - it is there too. No platform
dependency!
 You have to disable the Open documents in tabs check box in
preferences and
 follow the recipe Anders gave exactly.
 
 Interestingly the existing document is marked as changed after saving
the preamble
 of the new document!

Anders, can you file a new bug report? pavel




License ia.po

2011-03-09 Thread g.sora
Hereby I grant permission to license my contributions to
LyX under the GNU General Public License, version 2 or later.

 Giovanni Sora



Re: Bug with prettyref in lyx-2.0-rc1 (rev 37872)

2011-03-09 Thread Tommaso Cucinotta

Il 08/03/2011 17:47, Charpentier Philippe ha scritto:

Le 08.03.2011 14:56, Richard Heck a écrit :

On 03/08/2011 02:34 AM, Philippe Charpentier wrote:

Hi
the following bug is present in the revision 37872: if I choose
formated ref for a cross reference, the package prettyref is 
loaded in
the LaTeX preamble but the reference is traduced by \ref{...} 
instead of

\prettyref{...}.



No: with the french language and babel loaded, the form prefix:label 
will not compile on my system. As I said in a very old discussion, the 
only way to compile on all systems, is to modify prettyref.sty 
(replacing : by |) and to use prefix|label. This was possible 
with all previous versions of lyx and that is what I did in my french 
documents. Thus they will not compile correctly with lyx-2.0 if 
nothing is changed.


Just thinking aloud: again, this prettyref stuff that depends on 
user-specified prefixes doesn't really seem to me the right way to go . 
. . and this pointed out issue about the French language seems to 
confirm that prettyref may not be completely mature . . . so, that must 
be one of the reasons why refstyle is the default in the current trunk, 
but prettyref can still be used if one wants ?


T.



Re: Bug with prettyref in lyx-2.0-rc1 (rev 37872)

2011-03-09 Thread Richard Heck

On 03/09/2011 12:45 PM, Tommaso Cucinotta wrote:

Il 08/03/2011 17:47, Charpentier Philippe ha scritto:

Le 08.03.2011 14:56, Richard Heck a écrit :

On 03/08/2011 02:34 AM, Philippe Charpentier wrote:

Hi
the following bug is present in the revision 37872: if I choose
formated ref for a cross reference, the package prettyref is 
loaded in
the LaTeX preamble but the reference is traduced by \ref{...} 
instead of

\prettyref{...}.



No: with the french language and babel loaded, the form 
prefix:label will not compile on my system. As I said in a very old 
discussion, the only way to compile on all systems, is to modify 
prettyref.sty (replacing : by |) and to use prefix|label. This 
was possible with all previous versions of lyx and that is what I did 
in my french documents. Thus they will not compile correctly with 
lyx-2.0 if nothing is changed.


Just thinking aloud: again, this prettyref stuff that depends on 
user-specified prefixes doesn't really seem to me the right way to go 
. . . and this pointed out issue about the French language seems to 
confirm that prettyref may not be completely mature . . . so, that 
must be one of the reasons why refstyle is the default in the current 
trunk, but prettyref can still be used if one wants ?


Yes. We kept prettyref because lots of people have used and customized 
it in older documents.


I'm really not sure what to do here. We do NOT want to output 
uncompilable documents, and if prettyref does not see a : splitter (in 
its unmodified form), then it will choke. I understand why some people 
have modified prettyref themselves to deal with various problems, but 
how far can we go towards accommodating that?


Richard



Re: r37887 - lyx-devel/trunk/config

2011-03-09 Thread Stephan Witt
Am 09.03.2011 um 18:12 schrieb Jean-Marc Lasgouttes:

 Le 09/03/2011 16:40, sw...@lyx.org a écrit :
 Author: switt
 Date: Wed Mar  9 16:40:03 2011
 New Revision: 37887
 URL: http://www.lyx.org/trac/changeset/37887
 
 Log:
 do not check for hunspell libraries if header is not present
 
 Is it the patch you intended to commit?

Yes, this one I've posted and tested. Why do you ask?

Stephan

Re: .odt - .lyx

2011-03-09 Thread Dr Eberhard W Lisse
I have very good experiences, with exporting from NeoOffice
using the Write2LaTeX UltraClean option, then removing a few unnecessary
things, can be done by (perl) script and then
tex2lyx'ing it.

el


On 3/9/11 3:04 PM, Richard Heck wrote:
 On 03/09/2011 05:27 AM, Tommaso Cucinotta wrote:
 Hi,

 I need to convert a paper from .odt to .lyx for building an extended
 version (exact style unimportant -- I'll have to change the style
 anyway, but there are pictures and references [xrefs to numbered
 bullets] which I'd be happy to preserve). Is there any good resource
 describing how to proceed and what tools have the best chance ?

 The only option I know, realistically, is: Load the file in OOo and
 export it as LaTeX. Then load the LaTeX file into LyX.
 
 Richard
 
 




Re: .odt - .lyx

2011-03-09 Thread Rob Oakes
Hi Tommaso,

Sorry to hear about the difficulties. I actually had better luck creating my 
own import path.

ODF - HTML - Run tidy on HTML - HTML2LaTeX- LyX

This made sure that the markup coming into LyX was as clean as possible with no 
strange ERT or other data that couldn't be converted. I also had good luck with 
the conversion detailed in the article link that I sent. Again, it produced 
very clean input, though there were some limitations.

Any thoughts on how we might make it more approachable for the casual LyX user?

Cheers,

Rob

Re: Potential bug

2011-03-09 Thread Julien Rioux

On 09/03/2011 4:31 AM, Mark Dickinson wrote:

Hi,

Not sure if you can help.  I'm a complete LaTeX novice, but need to produce 
some exam scripts using a .sty produced by our hardcore LaTeX users (as usual 
there are two camps - the LaTeX users and the MS Word users!).  I don't have 
tome to learn command line stuff hence I thought I'd try LyX.  I'm on a Mac OS 
10x and have installed MacTex and Lyx.  Seems to all work fine except when I 
try to use the attached .tex and.sty files (these are an example exam script 
for our undergraduates).  I get errors (suggesting the /question def needs a 
number and that there are missing { and }.  Needless to say these files work 
perfectly in LaTeX.  Is this a bug in LyX or some other incompatibility?

Any help gratefully received,

Ma


Hi there,

You will need either a .layout or a .module file (in your case most 
likely a .module file). Such files are used to customize LyX so that it 
will interface with custom LaTeX document class and/or packages. A 
description of the syntax for such files is in the customization manual 
that you find in LyX's help menu.


In your case, LyX doesn't know what to do with non-standard LaTeX 
macros---as in \question---and environments---as in this:

\begin{exam}
...
\end{exam}.
So you want to describe those in your .module file.

Besides that, in your .tex file you will want to put all the \def... 
lines after these two lines:

\begin{document}
\maketitle

This last point is necessary due to the way in which the .tex to .lyx 
converter operates. I suppose it is not general enough, and you could 
consider this a bug, but the workaround is simple.


--
Julien


Side Caption Insets for Memoir

2011-03-09 Thread Rob Oakes
Dear LyX Developers and Users,

For the past couple of days, I've been working on a custom LaTeX document class 
for a non-profit. It is based on memoir, and while it is still a work in 
progress, I'd like to think that it is rather awesome.

Because the final goal is to use this document class in LyX (version 2.0, they 
have already downloaded and started using the release candidate), I'm trying to 
create custom insets and environments for the document class features. One 
environment that has me stumped though, is how to create an inset for the 
memoir sidecaption feature.

The sidecaption environment allows you to typeset the caption of your figure in 
the margin (similar to the way that the Tufte handout and book classes work), 
and the style guide for this class calls for their use. This is how an example 
in LaTeX would work.

\begin{figure}
\begin{sidecaption}{A typical learning center in Mexico City.}
\resizebox*{\textwidth}{!}{\includegraphics{learning1.jpg}}
\end{sidecaption}
\end{figure}

Does anyone have any ideas on how I could create an inset that captures all of 
this information? The tricky bit seems to be that the caption is specified in 
the \begin{sidecaption} statement, rather than as a \caption command. I know 
that LyX 2 now supports creating insets for optional arguments, but I'm not 
entirely sure how I could use that to solve this difficulty.

I'd greatly appreciate any thoughts. (Also, if it works, this would be a very 
nice addition to the memoir layout that currently ships with LyX 2. Would it be 
too late to incorporate it?)

Cheers,

Rob

Regression in r37463 by switt: Crash when deleting ERT from inside

2011-03-09 Thread John McCabe-Dansted
(Was Regression in r37463 by switt: Crash when deleting footnote)
I found another bug that appears to be caused by r37463

KEYCODES:  \Cla\[Delete]
To Reproduce
1) Press Ctrl-L to enter ERT mode
2) Press A to enter a character
3) Press Delete to delete the ERT container.

Program received signal SIGSEGV, Segmentation fault.
0x7552b2e8 in main_arena () from /lib/libc.so.6
(gdb) #0  0x7552b2e8 in main_arena () from /lib/libc.so.6
#1  0x00656a12 in lyx::CursorSlice::text (this=0x197e940,
cpp CursorSlice.h
loc=lyx::WHOLE_WORD) at CursorSlice.h:113
#2  lyx::DocIterator::locateWord (this=0x197e940, loc=lyx::WHOLE_WORD)
cpp DocIterator.cpp
at DocIterator.cpp:199
#3  0x0078413d in lyx::Cursor::checkNewWordPosition (this=0x197e8d8)
cpp Cursor.cpp
at Cursor.cpp:560
#4  0x00794b52 in lyx::cap::pasteParagraphList (cur=..., parlist=...,
cpp CutAndPaste.cpp
docclass=0x180cbe0, errorList=...) at CutAndPaste.cpp:971
#5  0x00703e82 in lyx::Text::dissolveInset (
cpp Text.cpp
...

lyx::CursorSlice::text also occurs in bug #6596, but #6596 has been
fixed while this bug still occurs in r37893.

For more information see:
  http://gmatht.homelinux.net/xp/keytest/html_out/out/t15/html/1299676478.html

-- 
John C. McCabe-Dansted


Re: Google Summer of Code: deadline is next Friday!

2011-03-09 Thread stefano franchi
Dear all,

I am forwarding a message from Leo Franchi with some thoughts about LyX's
participation to Google's SoC (he is not a subscriber to lyx-devel).

Stefano

-- Forwarded message --
From: Leo Franchi lfran...@kde.org
To: lyx-devel@lists.lyx.org
Date: Mon, 07 Mar 2011 22:59:27 -0500
Subject: Re: Google Summer of Code: deadline is next Friday!
Hello LyX developers,

(apologies for manually sending a reply, I am not subscribed. Please CC me
to
responses :)

I'm a LyX user, KDE developer and occasional reader of this list. I've also
been a student, mentor, and for the past three years Org Admin (one of 2-4)
for the KDE GSoC program. I thought I'd chime in with a few words of
encouragement and some comments based our our experience. To give an
overview:
KDE has been participating in the GSoC since 2005, and we've consistently
had
over 30 students and 200 mentors, and we've gained  tremendous amount of new
contributors as well as new code.

Before I write any comments, there's an invaluable Mentor Manual that a
few
folks including Leslie and Cat at Google wrote over the past few years. It's
very comprehensive and covers a lot of questions, so here are a few links:

http://www.booki.cc/gsoc-mentoring/_v/1.0/what-makes-a-good-mentor/
http://www.booki.cc/gsoc-mentoring/_v/1.0/making-your-ideas-page/
http://www.booki.cc/gsoc-mentoring/_v/1.0/org-application/

I'll add some comments inline and some more at the bottom. Please don't take
them as patronizing or anything, I think LyX is an awesome app and I want to
share any tips we've gleaned over the years to make your GSoC program as
successful as it can be. Thanks for reading!

p.s. See you at Camp KDE in a few weeks, most likely :)

Rob Oakes wrote:
 Dear Vincent and Pavel,

 I'm happy to serve as a mentor, developer point of contact, or both.  I'm
 also happy to help draft the application.

 In order to understand what would be required, I signed up for a developer
 account on GSoC. Here's what I found.

 Everything looks straightforward. In addition to the project name and
 background, they also ask to describe what we hope to get out of GSoC, and
 what sorts of difficulties we anticipate.
 There are a few points of the application that will need to be talked
 about, though. Specifically:

 * We will need to create an ideas page. I think that the projects we've
 talked about already might serve as a good starting point.

The Ideas page is essential to your application. That's the page that
students
will go to when they see LyX on the GSoC page, and it's an important page
for
Google's criteria in deciding to accept projects. It doesn't need to be
anything fancy or complicated, just a list with a table fo contents. Here's
our template that we stick to for ideas:
http://community.kde.org/GSoC/2011/Ideas#Adding_a_Proposal --- as you can
see,
nothing too long or complex, just an easily-searched and indexed list of
ideas.

 * We need to craft a suitable description of what criteria were used to
 select suitable mentors for the organization. They would like us to be as
 specific as possible.

This doesn't need to be anything particularly difficult---in my experience
it's enough to say something along the lines of mentors are selected from
existing Lyx developers. Longstanding developers who have shown the ability
to
guide new contributors in our project will be chosen to ensure that students
will be guided and supported throughout the program. Or something like that
:)

 * We need a plan for dealing with disappearing students. Perhaps we might
 adapt an institutional plan? Anyone who's supervised student research work
 probably has a formal or highly structured, informal version of motivating
 difficult people.

This is the biggest problem most organizations face, and it's one that we've
had to deal with over and over again. I can think of 2 big mistakes we've
made
in the past:

1) Too loose project goals

Projects without a coherent and definite timeline as a part of the
application
have fared much more poorly. It's easy to apply with an idea of doing
Feature
X in 3 months---it's much harder breaking it up into 6 2-week chunks of
time
and describing exactly what you (the student) thinks you can accomplish in
each time period. We now require all applications to have a detailed
timeline
in order to be given a good review---we follow up with students who submit
empty or thin timelines during the application process to help them improve.
It also forces the students to interact with the developers to guage how
hard
a feature/fix really will be to implement.

2) Too little constant communication between mentors and students

Students have disappeared because they've not been in constant contact
through
the project. This happened to me this past summer---I didn't do regular
status
updates with my student, and he seemed to be progressing rather slowly.
After
the first month, we instituted a weekly IRC meeting and blog/email reports
to
the developer list. 

Re: Bug in 2.0RC1? language changing change the language of already written text.

2011-03-09 Thread Jean-Marc Lasgouttes

Le 09/03/2011 07:24, Stephan Witt a écrit :

Ah, ok - I didn't thought of that. But it's not exactly the same.
When in front of a word the selection is not done too. That raises the
question if it's better or not to use WHOLE_WORD_STRICT...
When entering hebrew text is the word end at from() or at the to() pos?


Note that this is what is used for fonts in Text::toggleFree. I would 
think the two actions should behave similarly.


JMarc


Re: compile 2.0rc1 on mac

2011-03-09 Thread Jean-Marc Lasgouttes

Le 09/03/2011 07:40, Stephan Witt a écrit :

I think it was correct, but here is nevertheless a more idiomatic version (that 
subsumes José's patch too).


The problem was: the result of header presence detection - aka missing header 
is respected by the first test for the library but not by the second test.


I meant: I think _your_patch_ was correct.

JMarc


.odt -> .lyx

2011-03-09 Thread Tommaso Cucinotta

Hi,

I need to convert a paper from .odt to .lyx for building an extended 
version (exact style unimportant -- I'll have to change the style 
anyway, but there are pictures and references [xrefs to numbered 
bullets] which I'd be happy to preserve). Is there any good resource 
describing how to proceed and what tools have the best chance ?


T.



Re: .odt -> .lyx

2011-03-09 Thread Richard Heck

On 03/09/2011 05:27 AM, Tommaso Cucinotta wrote:

Hi,

I need to convert a paper from .odt to .lyx for building an extended 
version (exact style unimportant -- I'll have to change the style 
anyway, but there are pictures and references [xrefs to numbered 
bullets] which I'd be happy to preserve). Is there any good resource 
describing how to proceed and what tools have the best chance ?


The only option I know, realistically, is: Load the file in OOo and 
export it as LaTeX. Then load the LaTeX file into LyX.


Richard



Re: Bug in 2.0RC1? language changing change the language of already written text.

2011-03-09 Thread Stephan Witt
Am 09.03.2011 um 10:29 schrieb Jean-Marc Lasgouttes:

> Le 09/03/2011 07:24, Stephan Witt a écrit :
>> Ah, ok - I didn't thought of that. But it's not exactly the same.
>> When in front of a word the selection is not done too. That raises the
>> question if it's better or not to use WHOLE_WORD_STRICT...
>> When entering hebrew text is the word end at from() or at the to() pos?
> 
> Note that this is what is used for fonts in Text::toggleFree. I would think 
> the two actions should behave similarly.

I did it that way. I had a positive feedback from Ronen. (Thanks for that.)

Stephan



Re: compile 2.0rc1 on mac

2011-03-09 Thread José Matos
On Tuesday 08 March 2011 22:06:36 Jean-Marc Lasgouttes wrote:
> Please and commit if it works also for you.
> José, if you have time, please test it too !
> 
> JMarc

Yep, it works for me. Thank you Stephan. :-)

-- 
José Abílio


Re: Towards rc1 (status update #4, trunk frozen)

2011-03-09 Thread Anders Ekberg
Done, Ticket #7349

/Anders

On 2011-03-08 10.13, "Pavel Sanda"  wrote:

>Stephan Witt wrote:
>> But I tried to verify it on Linux - it is there too. No platform
>>dependency!
>> You have to disable the "Open documents in tabs" check box in
>>preferences and
>> follow the recipe Anders gave exactly.
>> 
>> Interestingly the existing document is marked as changed after saving
>>the preamble
>> of the new document!
>
>Anders, can you file a new bug report? pavel




License ia.po

2011-03-09 Thread g.sora
Hereby I grant permission to license my contributions to
LyX under the GNU General Public License, version 2 or later.

 Giovanni Sora



Re: Bug with prettyref in lyx-2.0-rc1 (rev 37872)

2011-03-09 Thread Tommaso Cucinotta

Il 08/03/2011 17:47, Charpentier Philippe ha scritto:

Le 08.03.2011 14:56, Richard Heck a écrit :

On 03/08/2011 02:34 AM, Philippe Charpentier wrote:

Hi
the following bug is present in the revision 37872: if I choose
"formated ref" for a cross reference, the package prettyref is 
loaded in
the LaTeX preamble but the reference is traduced by \ref{...} 
instead of

\prettyref{...}.



No: with the french language and babel loaded, the form "prefix:label" 
will not compile on my system. As I said in a very old discussion, the 
only way to compile on all systems, is to modify prettyref.sty 
(replacing ":" by "|") and to use "prefix|label". This was possible 
with all previous versions of lyx and that is what I did in my french 
documents. Thus they will not compile correctly with lyx-2.0 if 
nothing is changed.


Just thinking aloud: again, this prettyref stuff that depends on 
user-specified prefixes doesn't really seem to me the right way to go . 
. . and this pointed out issue about the French language seems to 
confirm that prettyref may not be completely mature . . . so, that must 
be one of the reasons why refstyle is the default in the current trunk, 
but prettyref can still be used if one wants ?


T.



Re: Bug with prettyref in lyx-2.0-rc1 (rev 37872)

2011-03-09 Thread Richard Heck

On 03/09/2011 12:45 PM, Tommaso Cucinotta wrote:

Il 08/03/2011 17:47, Charpentier Philippe ha scritto:

Le 08.03.2011 14:56, Richard Heck a écrit :

On 03/08/2011 02:34 AM, Philippe Charpentier wrote:

Hi
the following bug is present in the revision 37872: if I choose
"formated ref" for a cross reference, the package prettyref is 
loaded in
the LaTeX preamble but the reference is traduced by \ref{...} 
instead of

\prettyref{...}.



No: with the french language and babel loaded, the form 
"prefix:label" will not compile on my system. As I said in a very old 
discussion, the only way to compile on all systems, is to modify 
prettyref.sty (replacing ":" by "|") and to use "prefix|label". This 
was possible with all previous versions of lyx and that is what I did 
in my french documents. Thus they will not compile correctly with 
lyx-2.0 if nothing is changed.


Just thinking aloud: again, this prettyref stuff that depends on 
user-specified prefixes doesn't really seem to me the right way to go 
. . . and this pointed out issue about the French language seems to 
confirm that prettyref may not be completely mature . . . so, that 
must be one of the reasons why refstyle is the default in the current 
trunk, but prettyref can still be used if one wants ?


Yes. We kept prettyref because lots of people have used and customized 
it in older documents.


I'm really not sure what to do here. We do NOT want to output 
uncompilable documents, and if prettyref does not see a : splitter (in 
its unmodified form), then it will choke. I understand why some people 
have modified prettyref themselves to deal with various problems, but 
how far can we go towards accommodating that?


Richard



Re: r37887 - lyx-devel/trunk/config

2011-03-09 Thread Stephan Witt
Am 09.03.2011 um 18:12 schrieb Jean-Marc Lasgouttes:

> Le 09/03/2011 16:40, sw...@lyx.org a écrit :
>> Author: switt
>> Date: Wed Mar  9 16:40:03 2011
>> New Revision: 37887
>> URL: http://www.lyx.org/trac/changeset/37887
>> 
>> Log:
>> do not check for hunspell libraries if header is not present
> 
> Is it the patch you intended to commit?

Yes, this one I've posted and tested. Why do you ask?

Stephan

Re: .odt -> .lyx

2011-03-09 Thread Dr Eberhard W Lisse
I have very good experiences, with exporting from NeoOffice
using the Write2LaTeX UltraClean option, then removing a few unnecessary
things, can be done by (perl) script and then
tex2lyx'ing it.

el


On 3/9/11 3:04 PM, Richard Heck wrote:
> On 03/09/2011 05:27 AM, Tommaso Cucinotta wrote:
>> Hi,
>>
>> I need to convert a paper from .odt to .lyx for building an extended
>> version (exact style unimportant -- I'll have to change the style
>> anyway, but there are pictures and references [xrefs to numbered
>> bullets] which I'd be happy to preserve). Is there any good resource
>> describing how to proceed and what tools have the best chance ?
>>
> The only option I know, realistically, is: Load the file in OOo and
> export it as LaTeX. Then load the LaTeX file into LyX.
> 
> Richard
> 
> 




Re: .odt -> .lyx

2011-03-09 Thread Rob Oakes
Hi Tommaso,

Sorry to hear about the difficulties. I actually had better luck creating my 
own import path.

ODF -> HTML -> Run tidy on HTML -> HTML2LaTeX-> LyX

This made sure that the markup coming into LyX was as clean as possible with no 
strange ERT or other data that couldn't be converted. I also had good luck with 
the conversion detailed in the article link that I sent. Again, it produced 
very clean input, though there were some limitations.

Any thoughts on how we might make it more approachable for the casual LyX user?

Cheers,

Rob

Re: Potential bug

2011-03-09 Thread Julien Rioux

On 09/03/2011 4:31 AM, Mark Dickinson wrote:

Hi,

Not sure if you can help.  I'm a complete LaTeX novice, but need to produce 
some exam scripts using a .sty produced by our hardcore LaTeX users (as usual 
there are two camps - the LaTeX users and the MS Word users!).  I don't have 
tome to learn command line stuff hence I thought I'd try LyX.  I'm on a Mac OS 
10x and have installed MacTex and Lyx.  Seems to all work fine except when I 
try to use the attached .tex and.sty files (these are an example exam script 
for our undergraduates).  I get errors (suggesting the /question def needs a 
number and that there are missing { and }.  Needless to say these files work 
perfectly in LaTeX.  Is this a bug in LyX or some other incompatibility?

Any help gratefully received,

Ma


Hi there,

You will need either a .layout or a .module file (in your case most 
likely a .module file). Such files are used to customize LyX so that it 
will interface with custom LaTeX document class and/or packages. A 
description of the syntax for such files is in the customization manual 
that you find in LyX's help menu.


In your case, LyX doesn't know what to do with non-standard LaTeX 
macros---as in \question---and environments---as in this:

\begin{exam}
...
\end{exam}.
So you want to describe those in your .module file.

Besides that, in your .tex file you will want to put all the \def... 
lines after these two lines:

\begin{document}
\maketitle

This last point is necessary due to the way in which the .tex to .lyx 
converter operates. I suppose it is not general enough, and you could 
consider this a bug, but the workaround is simple.


--
Julien


Side Caption Insets for Memoir

2011-03-09 Thread Rob Oakes
Dear LyX Developers and Users,

For the past couple of days, I've been working on a custom LaTeX document class 
for a non-profit. It is based on memoir, and while it is still a work in 
progress, I'd like to think that it is rather awesome.

Because the final goal is to use this document class in LyX (version 2.0, they 
have already downloaded and started using the release candidate), I'm trying to 
create custom insets and environments for the document class features. One 
environment that has me stumped though, is how to create an inset for the 
memoir "sidecaption" feature.

The sidecaption environment allows you to typeset the caption of your figure in 
the margin (similar to the way that the Tufte handout and book classes work), 
and the style guide for this class calls for their use. This is how an example 
in LaTeX would work.

\begin{figure}
\begin{sidecaption}{A typical learning center in Mexico City.}
\resizebox*{\textwidth}{!}{\includegraphics{learning1.jpg}}
\end{sidecaption}
\end{figure}

Does anyone have any ideas on how I could create an inset that captures all of 
this information? The tricky bit seems to be that the caption is specified in 
the \begin{sidecaption} statement, rather than as a \caption command. I know 
that LyX 2 now supports creating insets for optional arguments, but I'm not 
entirely sure how I could use that to solve this difficulty.

I'd greatly appreciate any thoughts. (Also, if it works, this would be a very 
nice addition to the memoir layout that currently ships with LyX 2. Would it be 
too late to incorporate it?)

Cheers,

Rob

Regression in r37463 by switt: Crash when deleting ERT from inside

2011-03-09 Thread John McCabe-Dansted
(Was Regression in r37463 by switt: Crash when deleting footnote)
I found another bug that appears to be caused by r37463

KEYCODES:  \Cla\[Delete]
To Reproduce
1) Press Ctrl-L to enter ERT mode
2) Press A to enter a character
3) Press Delete to delete the ERT container.

Program received signal SIGSEGV, Segmentation fault.
0x7552b2e8 in main_arena () from /lib/libc.so.6
(gdb) #0  0x7552b2e8 in main_arena () from /lib/libc.so.6
#1  0x00656a12 in lyx::CursorSlice::text (this=0x197e940,
cpp CursorSlice.h
loc=lyx::WHOLE_WORD) at CursorSlice.h:113
#2  lyx::DocIterator::locateWord (this=0x197e940, loc=lyx::WHOLE_WORD)
cpp DocIterator.cpp
at DocIterator.cpp:199
#3  0x0078413d in lyx::Cursor::checkNewWordPosition (this=0x197e8d8)
cpp Cursor.cpp
at Cursor.cpp:560
#4  0x00794b52 in lyx::cap::pasteParagraphList (cur=..., parlist=...,
cpp CutAndPaste.cpp
docclass=0x180cbe0, errorList=...) at CutAndPaste.cpp:971
#5  0x00703e82 in lyx::Text::dissolveInset (
cpp Text.cpp
...

"lyx::CursorSlice::text" also occurs in bug #6596, but #6596 has been
fixed while this bug still occurs in r37893.

For more information see:
  http://gmatht.homelinux.net/xp/keytest/html_out/out/t15/html/1299676478.html

-- 
John C. McCabe-Dansted


Re: Google Summer of Code: deadline is next Friday!

2011-03-09 Thread stefano franchi
Dear all,

I am forwarding a message from Leo Franchi with some thoughts about LyX's
participation to Google's SoC (he is not a subscriber to lyx-devel).

Stefano

-- Forwarded message --
From: Leo Franchi 
To: lyx-devel@lists.lyx.org
Date: Mon, 07 Mar 2011 22:59:27 -0500
Subject: Re: Google Summer of Code: deadline is next Friday!
Hello LyX developers,

(apologies for manually sending a reply, I am not subscribed. Please CC me
to
responses :)

I'm a LyX user, KDE developer and occasional reader of this list. I've also
been a student, mentor, and for the past three years Org Admin (one of 2-4)
for the KDE GSoC program. I thought I'd chime in with a few words of
encouragement and some comments based our our experience. To give an
overview:
KDE has been participating in the GSoC since 2005, and we've consistently
had
over 30 students and 200 mentors, and we've gained  tremendous amount of new
contributors as well as new code.

Before I write any comments, there's an invaluable "Mentor Manual" that a
few
folks including Leslie and Cat at Google wrote over the past few years. It's
very comprehensive and covers a lot of questions, so here are a few links:

http://www.booki.cc/gsoc-mentoring/_v/1.0/what-makes-a-good-mentor/
http://www.booki.cc/gsoc-mentoring/_v/1.0/making-your-ideas-page/
http://www.booki.cc/gsoc-mentoring/_v/1.0/org-application/

I'll add some comments inline and some more at the bottom. Please don't take
them as patronizing or anything, I think LyX is an awesome app and I want to
share any tips we've gleaned over the years to make your GSoC program as
successful as it can be. Thanks for reading!

p.s. See you at Camp KDE in a few weeks, most likely :)

Rob Oakes wrote:
> Dear Vincent and Pavel,
>
> I'm happy to serve as a mentor, developer point of contact, or both.  I'm
> also happy to help draft the application.
>
> In order to understand what would be required, I signed up for a developer
> account on GSoC. Here's what I found.
>
> Everything looks straightforward. In addition to the project name and
> background, they also ask to describe what we hope to get out of GSoC, and
> what sorts of difficulties we anticipate.
> There are a few points of the application that will need to be talked
> about, though. Specifically:
>
> * We will need to create an "ideas" page. I think that the projects we've
> talked about already might serve as a good starting point.

The Ideas page is essential to your application. That's the page that
students
will go to when they see LyX on the GSoC page, and it's an important page
for
Google's criteria in deciding to accept projects. It doesn't need to be
anything fancy or complicated, just a list with a table fo contents. Here's
our template that we stick to for ideas:
http://community.kde.org/GSoC/2011/Ideas#Adding_a_Proposal --- as you can
see,
nothing too long or complex, just an easily-searched and indexed list of
ideas.

> * We need to craft a suitable description of what criteria were used to
> select suitable mentors for the organization. They would like us to be "as
> specific as possible."

This doesn't need to be anything particularly difficult---in my experience
it's enough to say something along the lines of "mentors are selected from
existing Lyx developers. Longstanding developers who have shown the ability
to
guide new contributors in our project will be chosen to ensure that students
will be guided and supported throughout the program." Or something like that
:)

> * We need a plan for dealing with disappearing students. Perhaps we might
> adapt an institutional plan? Anyone who's supervised student research work
> probably has a formal or highly structured, informal version of motivating
> difficult people.

This is the biggest problem most organizations face, and it's one that we've
had to deal with over and over again. I can think of 2 big mistakes we've
made
in the past:

1) Too loose project goals

Projects without a coherent and definite timeline as a part of the
application
have fared much more poorly. It's easy to apply with an idea of doing
"Feature
X" in 3 months---it's much harder breaking it up into 6 2-week chunks of
time
and describing exactly what you (the student) thinks you can accomplish in
each time period. We now require all applications to have a detailed
timeline
in order to be given a good review---we follow up with students who submit
empty or thin timelines during the application process to help them improve.
It also forces the students to interact with the developers to guage how
hard
a feature/fix really will be to implement.

2) Too little constant communication between mentors and students

Students have disappeared because they've not been in constant contact
through
the project. This happened to me this past summer---I didn't do regular
status
updates with my student, and he seemed to be progressing rather slowly.
After
the first month, we instituted a weekly IRC meeting and