Re: Bug in 2.0RC1? language changing change the language of already written text.
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
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
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
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.
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
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)
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
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)
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)
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
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
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
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
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
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
(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!
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.
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
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
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
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.
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
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)
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
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)
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)
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
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
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
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
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
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
(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!
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 FranchiTo: 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