[ANNOUNCE] LyX 2.0.5

[rgheck]

We are pleased to announce the release of LyX 2.0.5. This is the fifth
maintenance release in the 2.0.x series.

LyX 2.0.5 is the result of on-going efforts to make our stable version
even more reliable and stable. We have fixed a number of bugs and made
a number of improvements. These are detailed below. We encourage all
LyX users to upgrade to this version.

LyX is a document processor that encourages an approach to writing based
on the structure of your documents and not simply their appearance. It is
released under a Free and Open Source Software license.

You can download LyX 2.0.5 from http://www.lyx.org/Download/.

If you think you found a bug in LyX 2.0.5, either e-mail the LyX
developers' mailing list (lyx-devel at lists.lyx.org), or open a bug
report at http://www.lyx.org/trac/wiki/BugTrackerHome.

If you have trouble using LyX or have a question, consult the
documentation that comes with LyX and the LyX wiki, which lives at
http://wiki.lyx.org/. If you can't find the answer there, e-mail the LyX
users' list (lyx-users at lists.lyx.org).

We hope you enjoy using LyX 2.0.5.

The LyX team.
http://www.lyx.org


What's new in LyX 2.0.5
===

The ViewSource widget now allows you to select the backend to display,
e.g., LaTeX or XHTML, rather than the output format. The previous choice
really made no sense: You didn't see a PDF there if you chose one of the
PDF output formats, but rather LaTeX. This solves some long-standing issues
with ViewSource.

There has been an important change in how the language lfun works.
  - language LANG now toggles between languages
(status quo ante LyX 2.0.2)
  - language LANG set sets to language LANG
(meaning of language LANG as of LyX 2.0.2)
  - language [reset] resets to the document language.
  - Menu functions are unchanged.


What's new
==

** Updates:
***

* DOCUMENT INPUT/OUTPUT

- Add explicit dvilualatex output format.

- Add support for some IPA diacritics.

- Enclose underlined \ref{} commands in \mbox{} to protect them when
  using the package soul in place of (or together with) ulem.


* TEX2LYX IMPROVEMENTS

- The polyglossia/XeTeX language commands are now supported (bug 8212).

- It is now recognized if syncTeX is used (bug 8217).


* USER INTERFACE

- Reset only the top-level counter when starting the appendix.

- Show backends, not formats, in menu View-Source (bug #7652).

- Allow native LyX format to be shown in menu View-Source.

- Implementation of spell check of current selection (bug #2511).

- Add property list entries for high resolution display on Mac.

- Semantic change of the language lfun (bug 8175):
  - language LANG now toggles between languages
(status quo ante LyX 2.0.2)
  - language LANG set sets to language LANG
(meaning of language LANG as of LyX 2.0.2)
  - language [reset] resets to the document language.
  - Menu functions are unchanged.


* DOCUMENTATION AND LOCALIZATION

- Updated French, German, Interlingua, Italian, Nynorsk, Polish,
  Slovak, Spanish, Swedish and Ukrainian user interface localizations.

- New Spanish example files europeCV.lyx and modernCV.lyx.

- Updated Spanish translation of the LyX manuals.

- Updated french translation of the linguistics manual.

- Updated information about literate programming (noweb).


** Bug fixes:
*

* DOCUMENT INPUT/OUTPUT

- Fix assertion when start of appendix is in ERT (bug 8271).

- Do not output empty language switch commands (bug 8216).

- Do not let the master document interfere when a child is compiled 
standalone

  (bug 8000).

- When using Turkish language, use the xkeyval package to avoid
  incompatibilities (bug 2005).

- Do not ignore polyglossia commands in partial source preview (bug 8209).

- Show enabled child-only branches content in source preview (bug 8001).

- Export correct language change commands if document contains different
  CJK languages (bug 8215).

- Fix encoding problems in hyperlink name field (bug 8357).

- Fix bug that Elsevier documents became uncompilable when using 
refstyle for

  cross-references.

- Fixed the layout and template file for scientific articles published 
by the

  American Psychological Association (APA) (bug 8187).

- Write correct DTD for MathML (bug 8160).

- Make the ~ char in Basque, Estonian and Galician non-active (bug 8265).

- Embrace babel settings to \makeatletter ... \makeatother if they contain
  an @ glyph.

- Improve the external file monitor. LyX should now also honor changes in
  graphics that are included via ERT or generated via knitr (bug 8336).

- Fix LaTeX errors with right-to-left text when using XeTeX/Polyglossia
  (part of bug 8251).

- Fix brackets direction in Hebrew documents when using XeTeX/Polyglossia
  and in Arabic documents on plain text output (part of bug 8251).

- Fix bracket output with RTL languages (bug 8278).

- Fix babel call with Arabic (arabi).

- Fix suppression of language package.

- Fix forward search with the Okular 

[ANNOUNCE] LyX 2.0.5

[rgheck]

We are pleased to announce the release of LyX 2.0.5. This is the fifth
maintenance release in the 2.0.x series.

LyX 2.0.5 is the result of on-going efforts to make our stable version
even more reliable and stable. We have fixed a number of bugs and made
a number of improvements. These are detailed below. We encourage all
LyX users to upgrade to this version.

LyX is a document processor that encourages an approach to writing based
on the structure of your documents and not simply their appearance. It is
released under a Free and Open Source Software license.

You can download LyX 2.0.5 from http://www.lyx.org/Download/.

If you think you found a bug in LyX 2.0.5, either e-mail the LyX
developers' mailing list (lyx-devel  lists.lyx.org), or open a bug
report at http://www.lyx.org/trac/wiki/BugTrackerHome.

If you have trouble using LyX or have a question, consult the
documentation that comes with LyX and the LyX wiki, which lives at
http://wiki.lyx.org/. If you can't find the answer there, e-mail the LyX
users' list (lyx-users at lists.lyx.org).

We hope you enjoy using LyX 2.0.5.

The LyX team.
http://www.lyx.org


What's new in LyX 2.0.5
===

The View>Source widget now allows you to select the backend to display,
e.g., LaTeX or XHTML, rather than the output format. The previous choice
really made no sense: You didn't see a PDF there if you chose one of the
PDF output formats, but rather LaTeX. This solves some long-standing issues
with View>Source.

There has been an important change in how the "language" lfun works.
  - "language " now toggles between languages
(status quo ante LyX 2.0.2)
  - "language  set" sets to language 
(meaning of "language " as of LyX 2.0.2)
  - "language [reset]" resets to the document language.
  - Menu functions are unchanged.


What's new
==

** Updates:
***

* DOCUMENT INPUT/OUTPUT

- Add explicit dvilualatex output format.

- Add support for some IPA diacritics.

- Enclose underlined \ref{} commands in \mbox{} to protect them when
  using the package soul in place of (or together with) ulem.


* TEX2LYX IMPROVEMENTS

- The polyglossia/XeTeX language commands are now supported (bug 8212).

- It is now recognized if syncTeX is used (bug 8217).


* USER INTERFACE

- Reset only the top-level counter when starting the appendix.

- Show backends, not formats, in menu View->Source (bug #7652).

- Allow native LyX format to be shown in menu View->Source.

- Implementation of spell check of current selection (bug #2511).

- Add property list entries for high resolution display on Mac.

- Semantic change of the "language" lfun (bug 8175):
  - "language " now toggles between languages
(status quo ante LyX 2.0.2)
  - "language  set" sets to language 
(meaning of "language " as of LyX 2.0.2)
  - "language [reset]" resets to the document language.
  - Menu functions are unchanged.


* DOCUMENTATION AND LOCALIZATION

- Updated French, German, Interlingua, Italian, Nynorsk, Polish,
  Slovak, Spanish, Swedish and Ukrainian user interface localizations.

- New Spanish example files europeCV.lyx and modernCV.lyx.

- Updated Spanish translation of the LyX manuals.

- Updated french translation of the linguistics manual.

- Updated information about literate programming (noweb).


** Bug fixes:
*

* DOCUMENT INPUT/OUTPUT

- Fix assertion when start of appendix is in ERT (bug 8271).

- Do not output empty language switch commands (bug 8216).

- Do not let the master document interfere when a child is compiled 
standalone

  (bug 8000).

- When using Turkish language, use the xkeyval package to avoid
  incompatibilities (bug 2005).

- Do not ignore polyglossia commands in partial source preview (bug 8209).

- Show enabled child-only branches content in source preview (bug 8001).

- Export correct language change commands if document contains different
  CJK languages (bug 8215).

- Fix encoding problems in hyperlink name field (bug 8357).

- Fix bug that Elsevier documents became uncompilable when using 
refstyle for

  cross-references.

- Fixed the layout and template file for scientific articles published 
by the

  American Psychological Association (APA) (bug 8187).

- Write correct DTD for MathML (bug 8160).

- Make the ~ char in Basque, Estonian and Galician non-active (bug 8265).

- Embrace babel settings to \makeatletter ... \makeatother if they contain
  an @ glyph.

- Improve the external file monitor. LyX should now also honor changes in
  graphics that are included via ERT or generated via knitr (bug 8336).

- Fix LaTeX errors with right-to-left text when using XeTeX/Polyglossia
  (part of bug 8251).

- Fix brackets direction in Hebrew documents when using XeTeX/Polyglossia
  and in Arabic documents on plain text output (part of bug 8251).

- Fix bracket output with RTL languages (bug 8278).

- Fix babel call with Arabic (arabi).

- Fix suppression of language package.

- Fix forward search with the Okular viewer. If 

Re: fix for bug #8144 and partial fix for #5203

[rgheck]

On 05/14/2012 12:47 PM, Allen Barker wrote:


Oh well, no replies.  ;-)


Sorry, end of semester. Very busy. The other issue is that the person
who implemented the listings stuff is no longer active in development,
and I'm not sure how many of us really know about that code. I know
I don't.


I'm attaching the diffs to this post, rather than the actual files
(which were attached before).  Earlier I was running the svn diff
command in the main source directory and getting a huge file.


Yes, thanks. That makes things much easier.

Richard

Re: fix for bug #8144 and partial fix for #5203

[rgheck]

On 05/14/2012 12:47 PM, Allen Barker wrote:


Oh well, no replies.  ;-)


Sorry, end of semester. Very busy. The other issue is that the person
who implemented the listings stuff is no longer active in development,
and I'm not sure how many of us really know about that code. I know
I don't.


I'm attaching the diffs to this post, rather than the actual files
(which were attached before).  Earlier I was running the "svn diff"
command in the main source directory and getting a huge file.


Yes, thanks. That makes things much easier.

Richard

Re: [lyx/refs/heads/master] Let lyx2lyx create a proper TOC inset

[rgheck]

On 04/18/2012 02:46 PM, b...@lyx.org wrote:

Author: Georg Baumgeorg.b...@post.rwth-aachen.de
Date: Wed, 18 Apr 2012 20:44:33 +0200
New Commit: 8c45279696f3ed17cc40ee31dbbd352f815a094d
URL: 
http://git.lyx.org/?p=lyx.git;a=commit;h=8c45279696f3ed17cc40ee31dbbd352f815a094d

Log:
Let lyx2lyx create a proper TOC inset

Now that \lstlistoflistings is supported by InsetTOC, we should use that
instead of ERT. I could have updated the file format and directly used an
InsetTOC instead, but I was too lazy.

So far as I can see, this only changed 
lib/examples/localization_test.lyx. Was that intended?


Richard

Re: [lyx/refs/heads/master] Let lyx2lyx create a proper TOC inset

[rgheck]

On 04/18/2012 02:46 PM, b...@lyx.org wrote:

Author: Georg Baum
Date: Wed, 18 Apr 2012 20:44:33 +0200
New Commit: 8c45279696f3ed17cc40ee31dbbd352f815a094d
URL: 
http://git.lyx.org/?p=lyx.git;a=commit;h=8c45279696f3ed17cc40ee31dbbd352f815a094d

Log:
Let lyx2lyx create a proper TOC inset

Now that \lstlistoflistings is supported by InsetTOC, we should use that
instead of ERT. I could have updated the file format and directly used an
InsetTOC instead, but I was too lazy.

So far as I can see, this only changed 
lib/examples/localization_test.lyx. Was that intended?


Richard

Re: r36891 - lyx-devel/trunk/lib/layouts

[rgheck]

On 12/15/2010 10:30 AM, rgh...@lyx.org wrote:

Author: rgheck
Date: Wed Dec 15 16:30:25 2010
New Revision: 36891
URL: http://www.lyx.org/trac/changeset/36891

Log:
The letter class supports quote, quotation, and verse, and surely the 
---Separator--- might be wanted.

   
This would also be good for branch. Someone who is familiar with them 
might also want to check the other letter classes. I never use them 
myself, so don't know what they are supposed to be able to do.


Richard


Modified:
lyx-devel/trunk/lib/layouts/letter.layout

Modified: lyx-devel/trunk/lib/layouts/letter.layout
==
--- lyx-devel/trunk/lib/layouts/letter.layout   Wed Dec 15 08:12:42 2010
(r36890)
+++ lyx-devel/trunk/lib/layouts/letter.layout   Wed Dec 15 16:30:25 2010
(r36891)
@@ -11,6 +11,7 @@
  Input lyxmacros.inc
  Input stdfloats.inc
  Input stdcounters.inc
+Input stdlayouts.inc

  NoStyle Right_Address
  NoStyle Address
   

Re: r36891 - lyx-devel/trunk/lib/layouts

[rgheck]

On 12/15/2010 10:30 AM, rgh...@lyx.org wrote:

Author: rgheck
Date: Wed Dec 15 16:30:25 2010
New Revision: 36891
URL: http://www.lyx.org/trac/changeset/36891

Log:
The letter class supports quote, quotation, and verse, and surely the 
---Separator--- might be wanted.

   
This would also be good for branch. Someone who is familiar with them 
might also want to check the other letter classes. I never use them 
myself, so don't know what they are supposed to be able to do.


Richard


Modified:
lyx-devel/trunk/lib/layouts/letter.layout

Modified: lyx-devel/trunk/lib/layouts/letter.layout
==
--- lyx-devel/trunk/lib/layouts/letter.layout   Wed Dec 15 08:12:42 2010
(r36890)
+++ lyx-devel/trunk/lib/layouts/letter.layout   Wed Dec 15 16:30:25 2010
(r36891)
@@ -11,6 +11,7 @@
  Input lyxmacros.inc
  Input stdfloats.inc
  Input stdcounters.inc
+Input stdlayouts.inc

  NoStyle Right_Address
  NoStyle Address
   

Re: [Code Review] LyX-Outline - Two Column TocModel

[rgheck]

On 05/23/2010 09:12 PM, Rob Oakes wrote:

Dear LyX Developers,

I am writing to request a bit of code review.

   

I will have a look at this tonight, hopefully.

rh

Re: bufferparams output

[rgheck]

On 05/24/2010 09:17 AM, Pavel Sanda wrote:

Richard,

looking at the current .lyx header i find a little bit disturbing
those \html_latex_start span class='latex' and so on.

what about enclose all xhtml header stuff into something like 
xhtml().writeFile(os)
and dump it only in non default case as we do with pdfoptions/spacing.writeFile?

   

Good idea. I'll have a look at this.

rh

Re: r34492 - lyx-devel/trunk/src

[rgheck]

On 05/24/2010 03:45 PM, Pavel Sanda wrote:

rgh...@lyx.org wrote:
   

Author: rgheck
Date: Mon May 24 21:38:14 2010
New Revision: 34492
URL: http://www.lyx.org/trac/changeset/34492

Log:
Output these params only when they are not default. (In the case of
html_latex_*, we'll put the default elsewhere.)

Modified:
lyx-devel/trunk/src/BufferParams.cpp

Modified: lyx-devel/trunk/src/BufferParams.cpp
==
--- lyx-devel/trunk/src/BufferParams.cppMon May 24 21:34:43 2010
(r34491)
+++ lyx-devel/trunk/src/BufferParams.cppMon May 24 21:38:14 2010
(r34492)
@@ -404,8 +404,6 @@
html_be_strict = false;
html_math_output = MathML;
html_math_img_scale = 1.0;
-   html_latex_start = span class='latex';
-   html_latex_end = /span;
  }
 

but then things stop to work no? i thought you will test
on equality with span class='latex' below and not
check for emptiness...

   
That param isn't used yet. What I'll do when I implement it is check for 
emptiness where the LaTeX actually gets output, and output a default 
there. Seems better to have the default be where it's used, anyway.




@@ -1056,10 +1054,14 @@
os  \\tracking_changes   convertstring(trackChanges)  '\n'
  \\output_changes   convertstring(outputChanges)  
'\n'
  \\html_math_output   html_math_output  '\n'
- \\html_be_strict   convertstring(html_be_strict)  
'\n'
- \\html_math_img_scale   
convertstring(html_math_img_scale)  '\n'
- \\html_latex_start   html_latex_start  \n
- \\html_latex_end   html_latex_end  \n;
+ \\html_be_strict   convertstring(html_be_strict)  
'\n';
+   
+   if (html_math_img_scale != 1.0)
+   os  \\html_math_img_scale   
convertstring(html_math_img_scale)  '\n';
+   if (!html_latex_start.empty())
+   os  \\html_latex_start   html_latex_start  '\n';
+   if (!html_latex_end.empty())
+os  \\html_latex_end   html_latex_end  '\n';
 

i guess that  Buffer::readHeader is missing.

   

Right. Thanks.

rh


pavel
   

Re: [Code Review] LyX-Outline - Two Column TocModel

[rgheck]

On 05/23/2010 09:12 PM, Rob Oakes wrote:

Dear LyX Developers,

I am writing to request a bit of code review.

   

I will have a look at this tonight, hopefully.

rh

Re: bufferparams output

[rgheck]

On 05/24/2010 09:17 AM, Pavel Sanda wrote:

Richard,

looking at the current .lyx header i find a little bit disturbing
those \html_latex_start "" and so on.

what about enclose all xhtml header stuff into something like 
xhtml().writeFile(os)
and dump it only in non default case as we do with pdfoptions/spacing.writeFile?

   

Good idea. I'll have a look at this.

rh

Re: r34492 - lyx-devel/trunk/src

[rgheck]

On 05/24/2010 03:45 PM, Pavel Sanda wrote:

rgh...@lyx.org wrote:
   

Author: rgheck
Date: Mon May 24 21:38:14 2010
New Revision: 34492
URL: http://www.lyx.org/trac/changeset/34492

Log:
Output these params only when they are not default. (In the case of
html_latex_*, we'll put the default elsewhere.)

Modified:
lyx-devel/trunk/src/BufferParams.cpp

Modified: lyx-devel/trunk/src/BufferParams.cpp
==
--- lyx-devel/trunk/src/BufferParams.cppMon May 24 21:34:43 2010
(r34491)
+++ lyx-devel/trunk/src/BufferParams.cppMon May 24 21:38:14 2010
(r34492)
@@ -404,8 +404,6 @@
html_be_strict = false;
html_math_output = MathML;
html_math_img_scale = 1.0;
-   html_latex_start = "";
-   html_latex_end = "";
  }
 

but then things stop to work no? i thought you will test
on equality with "" below and not
check for emptiness...

   
That param isn't used yet. What I'll do when I implement it is check for 
emptiness where the LaTeX actually gets output, and output a default 
there. Seems better to have the default be where it's used, anyway.




@@ -1056,10 +1054,14 @@
os<<  "\\tracking_changes "<<  convert(trackChanges)<<  '\n'
<<  "\\output_changes "<<  convert(outputChanges)<<  
'\n'
<<  "\\html_math_output "<<  html_math_output<<  '\n'
-   <<  "\\html_be_strict "<<  convert(html_be_strict)<<  
'\n'
-   <<  "\\html_math_img_scale "<<  
convert(html_math_img_scale)<<  '\n'
-   <<  "\\html_latex_start "<<  html_latex_start<<  "\n"
-   <<  "\\html_latex_end "<<  html_latex_end<<  "\n";
+   <<  "\\html_be_strict "<<  convert(html_be_strict)<<  
'\n';
+   
+   if (html_math_img_scale != 1.0)
+   os<<  "\\html_math_img_scale "<<  
convert(html_math_img_scale)<<  '\n';
+   if (!html_latex_start.empty())
+   os<<  "\\html_latex_start "<<  html_latex_start<<  '\n';
+   if (!html_latex_end.empty())
+os<<  "\\html_latex_end "<<  html_latex_end<<  '\n';
 

i guess that  Buffer::readHeader is missing.

   

Right. Thanks.

rh


pavel
   

Re: Broken HTML/OpenDocument Code Generation

[rgheck]

On 04/20/2010 06:14 AM, Pavel Sanda wrote:

Richard Heck wrote:
   

There's also a question about what to do with the new InsetPreview. I
haven't thought much about this.
 

i hoped that this could be solved by the same mechanism as when
the math insets are plain images in the output...

   
That's what I would assume we would do. I think you had also suggested 
something like this same treatment for InsetExternal. Anyway, once I get 
the math part working, then I can see if the same ideas work elsewhere.


rh

Math-as-Images for XHTML

[rgheck]

The attached patch implements export of math as images for XHTML.

I am morally certain that there are lots of things here that could be 
done better. I do not really understand the code very well. I don't 
think the patch breaks anything, but I'm guessing (and hoping) that 
people will have design suggestions.


To test this, you need to take a LyX file with some math in it, open it 
in a text editor, and change the html_math_output setting to 2. There 
isn't yet a UI for this, since without this patch nothing happens. ;-)


As you will also see, at present the math images have the background 
color of the LyX work area. I'm still thinking about how best to deal 
with that.


Ultimately, the images will also work as a fall back for MathML and 
HTML output. If we are trying to output MathML, e.g., and run into 
something we can't handle, we'll issue an exception which will lead to 
the math being output as an image.


Richard

Index: src/Buffer.cpp
===
--- src/Buffer.cpp	(revision 34217)
+++ src/Buffer.cpp	(working copy)
@@ -72,6 +72,7 @@
 #include insets/InsetInclude.h
 #include insets/InsetText.h
 
+#include mathed/InsetMathHull.h
 #include mathed/MacroTable.h
 #include mathed/MathMacroTemplate.h
 #include mathed/MathSupport.h
@@ -163,7 +164,8 @@
 
 	/// Update macro table starting with position of it \param it in some
 	/// text inset.
-	void updateMacros(DocIterator  it, DocIterator  scope);
+	void updateMacros(DocIterator  it, DocIterator  scope,
+			bool record_docits = false);
 	///
 	void setLabel(ParIterator  it, UpdateType utype) const;
 	///
@@ -403,7 +405,9 @@
 	}
 
 	// Remove any previewed LaTeX snippets associated with this buffer.
-	thePreviews().removeLoader(*this);
+	// We need to leave them for use in export, though.
+	if (!isClone())
+		thePreviews().removeLoader(*this);
 
 	delete d;
 }
@@ -1566,7 +1570,7 @@
 	updateBuffer(UpdateMaster, OutputUpdate);
 	checkBibInfoCache();
 	d-bibinfo_.makeCitationLabels(*this);
-	updateMacros();
+	updateMacros(true);
 	updateMacroInstances();
 
 	if (!only_body) {
@@ -2644,7 +2648,8 @@
 }
 
 
-void Buffer::Impl::updateMacros(DocIterator  it, DocIterator  scope)
+void Buffer::Impl::updateMacros(DocIterator  it, DocIterator  scope,
+		bool record_docits)
 {
 	pit_type const lastpit = it.lastpit();
 
@@ -2698,6 +2703,14 @@
 continue;
 			}
 
+			if (record_docits  iit-inset-asInsetMath()) {
+InsetMath * im = static_castInsetMath *(iit-inset);
+if (im-asHullInset()) {
+	InsetMathHull * hull = static_castInsetMathHull *(im);
+	hull-recordLocation(it);
+}
+			}
+
 			if (iit-inset-lyxCode() != MATHMACRO_CODE)
 continue;
 
@@ -2729,7 +2742,7 @@
 }
 
 
-void Buffer::updateMacros() const
+void Buffer::updateMacros(bool record_docit) const
 {
 	if (d-macro_lock)
 		return;
@@ -2748,7 +2761,7 @@
 	DocIterator it = par_iterator_begin();
 	DocIterator outerScope = it;
 	outerScope.pit() = outerScope.lastpit() + 2;
-	d-updateMacros(it, outerScope);
+	d-updateMacros(it, outerScope, record_docit);
 }
 
 
Index: src/Buffer.h
===
--- src/Buffer.h	(revision 34217)
+++ src/Buffer.h	(working copy)
@@ -427,7 +427,7 @@
 	// Macro handling
 	//
 	/// Collect macro definitions in paragraphs
-	void updateMacros() const;
+	void updateMacros(bool record_docit = false) const;
 	/// Iterate through the whole buffer and try to resolve macros
 	void updateMacroInstances() const;
 
Index: src/graphics/PreviewImage.cpp
===
--- src/graphics/PreviewImage.cpp	(revision 34217)
+++ src/graphics/PreviewImage.cpp	(working copy)
@@ -70,6 +70,12 @@
 }
 
 
+support::FileName const  PreviewImage::filename() const
+{
+	return pimpl_-iloader_.filename();
+}
+
+
 Dimension PreviewImage::dim() const
 {
 	Dimension dim;
Index: src/graphics/PreviewImage.h
===
--- src/graphics/PreviewImage.h	(revision 34217)
+++ src/graphics/PreviewImage.h	(working copy)
@@ -46,6 +46,8 @@
 	 *  triggers that.
 	 */
 	Image const * image() const;
+	///
+	support::FileName const  filename() const;
 
 private:
 	/// Use the Pimpl idiom to hide the internals.
Index: src/graphics/PreviewLoader.cpp
===
--- src/graphics/PreviewLoader.cpp	(revision 34217)
+++ src/graphics/PreviewLoader.cpp	(working copy)
@@ -204,7 +204,7 @@
 	///
 	void remove(string const  latex_snippet);
 	///
-	void startLoading();
+	void startLoading(bool wait = false);
 
 	/// Emit this signal when an image is ready for display.
 	boost::signalvoid(PreviewImage const ) imageReady;
@@ -291,9 +291,9 @@
 }
 
 
-void PreviewLoader::startLoading() const
+void PreviewLoader::startLoading(bool wait) const
 {
-	pimpl_-startLoading();
+	pimpl_-startLoading(wait);
 }
 
 
@@ -520,7 +520,7 @@
 }
 
 
-void 

Re: result of a first test with LyX 2.0alpha2

[rgheck]

On 04/20/2010 09:16 AM, Jean-Marc Lasgouttes wrote:

In this case, I don't see how we could take advantage of that.
If the alert is never displayed again, the choice cannot be reverted.
Then, the alert doesn't distinguish between ancillary files and main 
file.


Ah, we have no way to revert these dialog choices? This is very bad.

I think the don't show it again thing is a per-session option. You see 
it again the next session.


rh

Re: Repeating Errors

[rgheck]

On 04/20/2010 11:34 AM, Rob Oakes wrote:

Dear LyX Developers,

I thought that I would take a stab at fixing bug #6650,
http://www.lyx.org/trac/ticket/6650 (mostly because it is driving me to
absolute distraction).  Thus, I've been looking at the code in the two
messages classes, GuiApplication (where the status indicator is updated)
and the dispatch functions to try and understand what might be causing
the problem.  (Brief Description: Some types of errors will repeat
endlessly on screen and in the View Messages pane. The easiest way to
replicate this problem is to open a new document in the SVN version of
LyX and deliberately type two spaces.  This will cause the You
cannot ...  error, which then will repeat itself after every subsequent
keystroke.)

It seems as though certain types of errors are not being cleared after
they are displayed.  Is there some flag that needs to be set?

Additionally, I've noticed that there are only certain types of message
(LyX Errors, for example) that elicit the problem.  Other actions, such
as toggling a dialog or dissolving an inset do not cause the repeating.

Despite my current theory, I haven't been able to find reference to this
mysterious variable.  (I've looked at individual errors and the
status.message() instances).  I'd appreciate any guidance that you can
give me in trying to fix the problem.

   
Find the message that's being displayed. Set a breakpoint at the place 
in the
code where the message is set. Now trace back through the call stack 
from there
and try to figure out what's happening to that variable. Try the same 
thing with

one of the messages that does get cleared and see what's different.

Don't know if it helps, but that's where I'd start.

rh

Re: Broken HTML/OpenDocument Code Generation

[rgheck]

On 04/20/2010 06:14 AM, Pavel Sanda wrote:

Richard Heck wrote:
   

There's also a question about what to do with the new InsetPreview. I
haven't thought much about this.
 

i hoped that this could be solved by the same mechanism as when
the math insets are plain images in the output...

   
That's what I would assume we would do. I think you had also suggested 
something like this same treatment for InsetExternal. Anyway, once I get 
the math part working, then I can see if the same ideas work elsewhere.


rh

Math-as-Images for XHTML

[rgheck]

The attached patch implements export of math as images for XHTML.

I am morally certain that there are lots of things here that could be 
done better. I do not really understand the code very well. I don't 
think the patch breaks anything, but I'm guessing (and hoping) that 
people will have design suggestions.


To test this, you need to take a LyX file with some math in it, open it 
in a text editor, and change the "html_math_output" setting to 2. There 
isn't yet a UI for this, since without this patch nothing happens. ;-)


As you will also see, at present the math images have the background 
color of the LyX work area. I'm still thinking about how best to deal 
with that.


Ultimately, the images will also work as a "fall back" for MathML and 
HTML output. If we are trying to output MathML, e.g., and run into 
something we can't handle, we'll issue an exception which will lead to 
the math being output as an image.


Richard

Index: src/Buffer.cpp
===
--- src/Buffer.cpp	(revision 34217)
+++ src/Buffer.cpp	(working copy)
@@ -72,6 +72,7 @@
 #include "insets/InsetInclude.h"
 #include "insets/InsetText.h"
 
+#include "mathed/InsetMathHull.h"
 #include "mathed/MacroTable.h"
 #include "mathed/MathMacroTemplate.h"
 #include "mathed/MathSupport.h"
@@ -163,7 +164,8 @@
 
 	/// Update macro table starting with position of it \param it in some
 	/// text inset.
-	void updateMacros(DocIterator & it, DocIterator & scope);
+	void updateMacros(DocIterator & it, DocIterator & scope,
+			bool record_docits = false);
 	///
 	void setLabel(ParIterator & it, UpdateType utype) const;
 	///
@@ -403,7 +405,9 @@
 	}
 
 	// Remove any previewed LaTeX snippets associated with this buffer.
-	thePreviews().removeLoader(*this);
+	// We need to leave them for use in export, though.
+	if (!isClone())
+		thePreviews().removeLoader(*this);
 
 	delete d;
 }
@@ -1566,7 +1570,7 @@
 	updateBuffer(UpdateMaster, OutputUpdate);
 	checkBibInfoCache();
 	d->bibinfo_.makeCitationLabels(*this);
-	updateMacros();
+	updateMacros(true);
 	updateMacroInstances();
 
 	if (!only_body) {
@@ -2644,7 +2648,8 @@
 }
 
 
-void Buffer::Impl::updateMacros(DocIterator & it, DocIterator & scope)
+void Buffer::Impl::updateMacros(DocIterator & it, DocIterator & scope,
+		bool record_docits)
 {
 	pit_type const lastpit = it.lastpit();
 
@@ -2698,6 +2703,14 @@
 continue;
 			}
 
+			if (record_docits && iit->inset->asInsetMath()) {
+InsetMath * im = static_cast(iit->inset);
+if (im->asHullInset()) {
+	InsetMathHull * hull = static_cast(im);
+	hull->recordLocation(it);
+}
+			}
+
 			if (iit->inset->lyxCode() != MATHMACRO_CODE)
 continue;
 
@@ -2729,7 +2742,7 @@
 }
 
 
-void Buffer::updateMacros() const
+void Buffer::updateMacros(bool record_docit) const
 {
 	if (d->macro_lock)
 		return;
@@ -2748,7 +2761,7 @@
 	DocIterator it = par_iterator_begin();
 	DocIterator outerScope = it;
 	outerScope.pit() = outerScope.lastpit() + 2;
-	d->updateMacros(it, outerScope);
+	d->updateMacros(it, outerScope, record_docit);
 }
 
 
Index: src/Buffer.h
===
--- src/Buffer.h	(revision 34217)
+++ src/Buffer.h	(working copy)
@@ -427,7 +427,7 @@
 	// Macro handling
 	//
 	/// Collect macro definitions in paragraphs
-	void updateMacros() const;
+	void updateMacros(bool record_docit = false) const;
 	/// Iterate through the whole buffer and try to resolve macros
 	void updateMacroInstances() const;
 
Index: src/graphics/PreviewImage.cpp
===
--- src/graphics/PreviewImage.cpp	(revision 34217)
+++ src/graphics/PreviewImage.cpp	(working copy)
@@ -70,6 +70,12 @@
 }
 
 
+support::FileName const & PreviewImage::filename() const
+{
+	return pimpl_->iloader_.filename();
+}
+
+
 Dimension PreviewImage::dim() const
 {
 	Dimension dim;
Index: src/graphics/PreviewImage.h
===
--- src/graphics/PreviewImage.h	(revision 34217)
+++ src/graphics/PreviewImage.h	(working copy)
@@ -46,6 +46,8 @@
 	 *  triggers that.
 	 */
 	Image const * image() const;
+	///
+	support::FileName const & filename() const;
 
 private:
 	/// Use the Pimpl idiom to hide the internals.
Index: src/graphics/PreviewLoader.cpp
===
--- src/graphics/PreviewLoader.cpp	(revision 34217)
+++ src/graphics/PreviewLoader.cpp	(working copy)
@@ -204,7 +204,7 @@
 	///
 	void remove(string const & latex_snippet);
 	///
-	void startLoading();
+	void startLoading(bool wait = false);
 
 	/// Emit this signal when an image is ready for display.
 	boost::signal imageReady;
@@ -291,9 +291,9 @@
 }
 
 
-void PreviewLoader::startLoading() const
+void PreviewLoader::startLoading(bool wait) const
 {
-	pimpl_->startLoading();
+	pimpl_->startLoading(wait);
 }
 
 
@@ -520,7 +520,7 @@
 }
 
 

Re: result of a first test with LyX 2.0alpha2

[rgheck]

On 04/20/2010 09:16 AM, Jean-Marc Lasgouttes wrote:

In this case, I don't see how we could take advantage of that.
If the alert is never displayed again, the choice cannot be reverted.
Then, the alert doesn't distinguish between ancillary files and main 
file.


Ah, we have no way to revert these dialog choices? This is very bad.

I think the "don't show it again" thing is a per-session option. You see 
it again the next session.


rh

Re: Repeating Errors

[rgheck]

On 04/20/2010 11:34 AM, Rob Oakes wrote:

Dear LyX Developers,

I thought that I would take a stab at fixing bug #6650,
http://www.lyx.org/trac/ticket/6650 (mostly because it is driving me to
absolute distraction).  Thus, I've been looking at the code in the two
messages classes, GuiApplication (where the status indicator is updated)
and the dispatch functions to try and understand what might be causing
the problem.  (Brief Description: Some types of errors will repeat
endlessly on screen and in the "View Messages" pane. The easiest way to
replicate this problem is to open a new document in the SVN version of
LyX and deliberately type two spaces.  This will cause the "You
cannot ... " error, which then will repeat itself after every subsequent
keystroke.)

It seems as though certain types of errors are not being cleared after
they are displayed.  Is there some flag that needs to be set?

Additionally, I've noticed that there are only certain types of message
(LyX Errors, for example) that elicit the problem.  Other actions, such
as toggling a dialog or dissolving an inset do not cause the repeating.

Despite my current theory, I haven't been able to find reference to this
mysterious variable.  (I've looked at individual errors and the
status.message() instances).  I'd appreciate any guidance that you can
give me in trying to fix the problem.

   
Find the message that's being displayed. Set a breakpoint at the place 
in the
code where the message is set. Now trace back through the call stack 
from there
and try to figure out what's happening to that variable. Try the same 
thing with

one of the messages that does get cleared and see what's different.

Don't know if it helps, but that's where I'd start.

rh

Re: result of a first test with LyX 2.0alpha2

[rgheck]

On 04/19/2010 02:54 AM, Abdelrazak Younes wrote:

On 04/19/2010 05:51 AM, Uwe Stöhr wrote:

Am 19.04.2010 02:14, schrieb Vincent van Ravesteijn:


When I export a file as PDF LyX asks me if I want to replace the
existing PDF. This is OK, but replacing should be the default and not
keeping.

Why don't you change this then if you think this behaviour is 'very
annoying' ?


This is not the annoying part. I can fix this quickly but want to 
hear what others say - and Richard said no.


Richard didn't understand what you meant I think :-)


Always possible

rh

Re: result of a first test with LyX 2.0alpha2

[rgheck]

On 04/19/2010 08:44 AM, Abdelrazak Younes wrote:

On 04/19/2010 01:41 PM, rgheck wrote:

On 04/19/2010 02:54 AM, Abdelrazak Younes wrote:

On 04/19/2010 05:51 AM, Uwe Stöhr wrote:

Am 19.04.2010 02:14, schrieb Vincent van Ravesteijn:


When I export a file as PDF LyX asks me if I want to replace the
existing PDF. This is OK, but replacing should be the default and 
not

keeping.


Why don't you change this then if you think this behaviour is 'very
annoying' ?


This is not the annoying part. I can fix this quickly but want to 
hear what others say - and Richard said no.


Richard didn't understand what you meant I think :-)


Always possible


Uwe was talking about the button which had the focus by default.


Oh, I see. I guess you can see what I thought he meant.

So, Uwe: I have no objection to making replace have default focus.

rh

Re: Broken HTML/OpenDocument Code Generation

[rgheck]

On 04/19/2010 10:01 AM, Rainer Dorsch wrote:

Hello,

I have a small LyX document, which shows a combination of a hyperlink and an
svg figure break html/opendocument generation:

The source documentation is here

http://bokomoko.de/~rd/lyxtest/

The output I get is here

http://bokomoko.de/~rd/lyxtest/output/lyx_tmpbuf0/test.html

I have a self-compiled version of LyX 1.6.5 and texlive and tex4ht from Debian
stable:

rdor...@paddy:~/tmp.nobackup/lyxtest$ aptitude show texlive|grep Version
Version: 2007.dfsg.2-1~lenny2
rdor...@paddy:~/tmp.nobackup/lyxtest$ aptitude show tex4ht|grep Version
Version: 20080701-2
rdor...@paddy:~/tmp.nobackup/lyxtest$

Is there anything I am doing wrong?

   

I doubt it. tex4ht is pretty fragile, as people's experience here shows.


Has anybody a newer version of tex4ht and tex and can verify if the problem is
already fixed (download two files, fire up lyx, and view-html)?

   
The last official release seems to have been the one you have. Perhaps 
you should report the bug here:

http://www.cse.ohio-state.edu/~gurari/TeX4ht/#QQ1-1-82
and see what happens.

rh

Re: Master vs Child Preamble, Etc

[rgheck]

On 04/19/2010 08:42 AM, Jean-Marc Lasgouttes wrote:

rgheckrgh...@bobjweil.com  writes:
   

Even better would be to use in both on input and output, and to let the user
change these params in the document dialog from within each child.
   

I would prefer that too.

   

I think I'm confused about what's meant by input and output.


I thought about this, and in a way it would be easy: Buffer::params()
just has to return masterBuffer-params(). (Probably there are some
complications?) But then I wondered if this is right: When we write
the child, we'll write the master's params, since, in effect, the
child doesn't even have its own. Is that what we want to do?
 

When writing the child, we can use params_::write() directly. I think it
requires to be careful, but it is doable and desirable.

   
So I'm a bit puzzled here. The idea seemed to be that DocumentSettings 
accessed the params of the master. But then what's to write for the 
child? You can't even get at those. As I said, I'm sure I'm just confused.


There's an odd circularity problem: We want to be able to set Use 
Master Params as a setting in the child. But then, how do you turn it 
off if DocumentSettings always gives you the master?


rh

Re: Broken HTML/OpenDocument Code Generation

[rgheck]

On 04/19/2010 11:42 AM, Rainer Dorsch wrote:

Am Monday 19 April 2010 17:03:41 schrieb Jürgen Spitzmüller:
   

rgheck wrote:
 

The last official release seems to have been the one you have. Perhaps
you should report the bug here:
  http://www.cse.ohio-state.edu/~gurari/TeX4ht/#QQ1-1-82
and see what happens.
   

Note that the page and the project was moved here after Eitan Gurari's
death: http://www.tug.org/tex4ht/

 

The tex4ht developers probably do not want to have LyX in the bugreport. Can I
easily get a list of instructions which are issued by LyX when Viewing HTML?

   
LyX just exports to LaTeX then runs htlatex on the exported sources. 
Assuming you are using htlatex as the LaTeX--HTML converter. (See the 
other message for that.) So you can just do Export--LaTeX and you have 
the LaTeX file you need for the report.


rh

Re: Broken HTML/OpenDocument Code Generation

[rgheck]

On 04/19/2010 12:53 PM, Rainer Dorsch wrote:

Am Monday 19 April 2010 16:48:21 schrieb rgheck:
   

Is there anything I am doing wrong?


   

I doubt it. tex4ht is pretty fragile, as people's experience here shows.
 

Is there a better way to generate HTML from LyX files?

   
Depends upon your needs. There are lots of options: html2latex is a very 
old one; elyxer is a newer one. All have their limitations.


LyX 2.0 will have native XHTML export and can be tested via the alpha 
releases. It has limitations, too, especially now, since it isn't done. 
But IMHO it is already competitive with the other options. One of its 
nicest features, which will appear shortly, will be that it will be very 
flexible about how math gets exported and even be able to fall back to 
exporting little pictures if it can't figure out how to do something better.


rh

Re: result of a first test with LyX 2.0alpha2

[rgheck]

On 04/19/2010 11:22 AM, Enrico Forestieri wrote:

On Mon, Apr 19, 2010 at 02:14:25AM +0200, Vincent van Ravesteijn wrote:

   

Uwe Stöhr schreef:
 

But I noticed another very annoying behaviour:

When I export a file as PDF LyX asks me if I want to replace the
existing PDF. This is OK, but replacing should be the default and
not keeping.
   

This has always been like that and I didn't change it. It is surprising
that this has never annoyed you and suddenly now it does.
Moreover, I think that this correct, as lyx should never overwrite a
file without permission.

   
So, if Abdel is right, we both misunderstood Uwe the same way. Abdel 
says he meant that the replace BUTTON should be the default.


rh

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

[rgheck]

On 04/19/2010 12:10 PM, Vincent van Ravesteijn wrote:




Better(?) fix for bug #6659: InsetInfo context menu disabled unless 
cursor immediately in front.


Much better indeed.
Year, I was about to complain ;-)


The problem was that I never expected that InsetInfo is a child class 
of InsetCollapsable. This feels wrong.


In a way, yes. But it's not clear what else it should be. Not 
InsetCommand, I wouldn't have thought. So it'd have to be a direct 
subclass of Inset, and I think Bo just wanted to reuse the drawing 
routines, etc, from InsetCollapsable.


rh

Re: Broken HTML/OpenDocument Code Generation

[rgheck]

On 04/19/2010 04:29 PM, Rainer Dorsch wrote:


Just for curiosity: will the native XHTML export support ERT sections too?

   
At the moment, ERT is ignored, since in many cases it will be LaTeX we 
don't know how to handle. But you can easily define a new custom inset 
that will be output verbatim. Actually, I should perhaps check on this. 
There's probably an issue about escaping  and .


There's also a question about what to do with the new InsetPreview. I 
haven't thought much about this.


If that doesn't answer the question, feel free to ask again.

rh

Re: result of a first test with LyX 2.0alpha2

[rgheck]

On 04/19/2010 02:54 AM, Abdelrazak Younes wrote:

On 04/19/2010 05:51 AM, Uwe Stöhr wrote:

Am 19.04.2010 02:14, schrieb Vincent van Ravesteijn:


When I export a file as PDF LyX asks me if I want to replace the
existing PDF. This is OK, but replacing should be the default and not
keeping.

Why don't you change this then if you think this behaviour is 'very
annoying' ?


This is not the annoying part. I can fix this quickly but want to 
hear what others say - and Richard said no.


Richard didn't understand what you meant I think :-)


Always possible

rh

Re: result of a first test with LyX 2.0alpha2

[rgheck]

On 04/19/2010 08:44 AM, Abdelrazak Younes wrote:

On 04/19/2010 01:41 PM, rgheck wrote:

On 04/19/2010 02:54 AM, Abdelrazak Younes wrote:

On 04/19/2010 05:51 AM, Uwe Stöhr wrote:

Am 19.04.2010 02:14, schrieb Vincent van Ravesteijn:


When I export a file as PDF LyX asks me if I want to replace the
existing PDF. This is OK, but replacing should be the default and 
not

keeping.


Why don't you change this then if you think this behaviour is 'very
annoying' ?


This is not the annoying part. I can fix this quickly but want to 
hear what others say - and Richard said no.


Richard didn't understand what you meant I think :-)


Always possible


Uwe was talking about the button which had the focus by default.


Oh, I see. I guess you can see what I thought he meant.

So, Uwe: I have no objection to making "replace" have default focus.

rh

Re: Broken HTML/OpenDocument Code Generation

[rgheck]

On 04/19/2010 10:01 AM, Rainer Dorsch wrote:

Hello,

I have a small LyX document, which shows a combination of a hyperlink and an
svg figure break html/opendocument generation:

The source documentation is here

http://bokomoko.de/~rd/lyxtest/

The output I get is here

http://bokomoko.de/~rd/lyxtest/output/lyx_tmpbuf0/test.html

I have a self-compiled version of LyX 1.6.5 and texlive and tex4ht from Debian
stable:

rdor...@paddy:~/tmp.nobackup/lyxtest$ aptitude show texlive|grep Version
Version: 2007.dfsg.2-1~lenny2
rdor...@paddy:~/tmp.nobackup/lyxtest$ aptitude show tex4ht|grep Version
Version: 20080701-2
rdor...@paddy:~/tmp.nobackup/lyxtest$

Is there anything I am doing wrong?

   

I doubt it. tex4ht is pretty fragile, as people's experience here shows.


Has anybody a newer version of tex4ht and tex and can verify if the problem is
already fixed (download two files, fire up lyx, and view->html)?

   
The last official release seems to have been the one you have. Perhaps 
you should report the bug here:

http://www.cse.ohio-state.edu/~gurari/TeX4ht/#QQ1-1-82
and see what happens.

rh

Re: Master vs Child Preamble, Etc

[rgheck]

On 04/19/2010 08:42 AM, Jean-Marc Lasgouttes wrote:

rgheck<rgh...@bobjweil.com>  writes:
   

Even better would be to use in both on input and output, and to let the user
change these params in the document dialog from within each child.
   

I would prefer that too.

   

I think I'm confused about what's meant by "input" and "output".


I thought about this, and in a way it would be easy: Buffer::params()
just has to return masterBuffer->params(). (Probably there are some
complications?) But then I wondered if this is right: When we write
the child, we'll write the master's params, since, in effect, the
child doesn't even have its own. Is that what we want to do?
 

When writing the child, we can use params_::write() directly. I think it
requires to be careful, but it is doable and desirable.

   
So I'm a bit puzzled here. The idea seemed to be that Document>Settings 
accessed the params of the master. But then what's to write for the 
child? You can't even get at those. As I said, I'm sure I'm just confused.


There's an odd circularity problem: We want to be able to set "Use 
Master Params" as a setting in the child. But then, how do you turn it 
off if Document>Settings always gives you the master?


rh

Re: Broken HTML/OpenDocument Code Generation

[rgheck]

On 04/19/2010 11:42 AM, Rainer Dorsch wrote:

Am Monday 19 April 2010 17:03:41 schrieb Jürgen Spitzmüller:
   

rgheck wrote:
 

The last official release seems to have been the one you have. Perhaps
you should report the bug here:
  http://www.cse.ohio-state.edu/~gurari/TeX4ht/#QQ1-1-82
and see what happens.
   

Note that the page and the project was moved here after Eitan Gurari's
death: http://www.tug.org/tex4ht/

 

The tex4ht developers probably do not want to have LyX in the bugreport. Can I
easily get a list of instructions which are issued by LyX when Viewing HTML?

   
LyX just exports to LaTeX then runs htlatex on the exported sources. 
Assuming you are using htlatex as the LaTeX-->HTML converter. (See the 
other message for that.) So you can just do Export-->LaTeX and you have 
the LaTeX file you need for the report.


rh

Re: Broken HTML/OpenDocument Code Generation

[rgheck]

On 04/19/2010 12:53 PM, Rainer Dorsch wrote:

Am Monday 19 April 2010 16:48:21 schrieb rgheck:
   

Is there anything I am doing wrong?


   

I doubt it. tex4ht is pretty fragile, as people's experience here shows.
 

Is there a better way to generate HTML from LyX files?

   
Depends upon your needs. There are lots of options: html2latex is a very 
old one; elyxer is a newer one. All have their limitations.


LyX 2.0 will have "native" XHTML export and can be tested via the alpha 
releases. It has limitations, too, especially now, since it isn't done. 
But IMHO it is already "competitive" with the other options. One of its 
nicest features, which will appear shortly, will be that it will be very 
flexible about how math gets exported and even be able to "fall back" to 
exporting little pictures if it can't figure out how to do something better.


rh

Re: result of a first test with LyX 2.0alpha2

[rgheck]

On 04/19/2010 11:22 AM, Enrico Forestieri wrote:

On Mon, Apr 19, 2010 at 02:14:25AM +0200, Vincent van Ravesteijn wrote:

   

Uwe Stöhr schreef:
 

But I noticed another very annoying behaviour:

When I export a file as PDF LyX asks me if I want to replace the
existing PDF. This is OK, but replacing should be the default and
not keeping.
   

This has always been like that and I didn't change it. It is surprising
that this has never annoyed you and suddenly now it does.
Moreover, I think that this correct, as lyx should never overwrite a
file without permission.

   
So, if Abdel is right, we both misunderstood Uwe the same way. Abdel 
says he meant that the replace BUTTON should be the default.


rh

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

[rgheck]

On 04/19/2010 12:10 PM, Vincent van Ravesteijn wrote:




Better(?) fix for bug #6659: InsetInfo context menu disabled unless 
cursor immediately in front.


Much better indeed.
Year, I was about to complain ;-)


The problem was that I never expected that InsetInfo is a child class 
of InsetCollapsable. This feels wrong.


In a way, yes. But it's not clear what else it should be. Not 
InsetCommand, I wouldn't have thought. So it'd have to be a direct 
subclass of Inset, and I think Bo just wanted to reuse the drawing 
routines, etc, from InsetCollapsable.


rh

Re: Broken HTML/OpenDocument Code Generation

[rgheck]

On 04/19/2010 04:29 PM, Rainer Dorsch wrote:


Just for curiosity: will the "native" XHTML export support ERT sections too?

   
At the moment, ERT is ignored, since in many cases it will be LaTeX we 
don't know how to handle. But you can easily define a new custom inset 
that will be output verbatim. Actually, I should perhaps check on this. 
There's probably an issue about escaping < and >.


There's also a question about what to do with the new InsetPreview. I 
haven't thought much about this.


If that doesn't answer the question, feel free to ask again.

rh

Re: latex-lab?

[rgheck]

On 04/17/2010 10:38 PM, xPol wrote:

rgheck wrote:

   

I'm still wondering what precisely people want here. Porting LyX to an
AJAX application would be possible, but not something we on the
development team have anything near the time to do. So let me ask what I
asked before: What is it that people want to be able to do that you
can't do via version control?
 

I think what authors of maths text want is that everybody can read,  copy
and paste maths expressions in every usual form by which text are exchanged
on the web: email, web page.  As with plain text, math text should be
rendered in those common containers and straightforwardly copied into and
from the lyx processor.

   
LyX already reads and writes LaTeX math expressions. E.g., try the 
following. Highlight and copy this:

2^x
Now go to LyX. Hit Ctrl-M to get a math thingy, and paste. It also works 
the other way. Highlight the math inset in LyX and copy. Now paste into 
whatever you like.


If you think it would be good also to be able to do this with MathML, 
that can easily be arranged, at least for output. Going from MathML to 
LaTeX is not something we presently have the ability to do, but maybe 
there is a converter somewhere we could adapt.


Richard

Re: Master vs Child Preamble, Etc

[rgheck]

On 04/18/2010 03:42 AM, Jürgen Spitzmüller wrote:

rgheck wrote:
   

Given the common questions about this kind of thing, I wonder if we
should have a per-document setting that would allow the user to specify
that the params for a certain document are to be taken from the master,
if there is one. I would guess that this would only be active on output.

Has anyone tried to implement this kind of thing?
 

I have pondered about it, but did not come to implement it.

   
Here's the thought, then. As I suggested, we use the master's params 
only on output. The complication is that the params can be accessed from 
so many places. But they are always accessed via Buffer::params(), so we 
just need to arrange for Buffer::params() to return 
masterBuffer()-params() when we're doing output. If we're using clones 
for output, then this is easy: Just check isClone(). If we're not---I 
guess people who compile themselves can disable this---then maybe we 
need to set a flag. Either way, not too bad.


Thoughts?

Richard

Restore Last Position Bug Fixed?

[rgheck]

Has the bug concerning restoration of last file position been fixed in 
trunk? I.e., if you have bookmarks, then the code that updates their 
location before closing causes the last file position to be set to 
wherever the last bookmark is.


rh

Re: Master vs Child Preamble, Etc

[rgheck]

On 04/18/2010 10:38 AM, Jürgen Spitzmüller wrote:

rgheck wrote:
   

Here's the thought, then. As I suggested, we use the master's params
only on output. The complication is that the params can be accessed from
so many places. But they are always accessed via Buffer::params(), so we
just need to arrange for Buffer::params() to return
masterBuffer()-params() when we're doing output. If we're using clones
for output, then this is easy: Just check isClone(). If we're not---I
guess people who compile themselves can disable this---then maybe we
need to set a flag. Either way, not too bad.

Thoughts?
 

Even better would be to use in both on input and output, and to let the user
change these params in the document dialog from within each child.

   


I thought about this, and in a way it would be easy: Buffer::params() 
just has to return masterBuffer-params(). (Probably there are some 
complications?) But then I wondered if this is right: When we write the 
child, we'll write the master's params, since, in effect, the child 
doesn't even have its own. Is that what we want to do?



And of course, the default should still be to use the child's own params, as 
long as
we are not compiling with master-buffer-[view|update].

   

Of course.

rh

Re: r34213 - lyx-devel/trunk/src

[rgheck]

On 04/18/2010 07:17 PM, Pavel Sanda wrote:



if (it == en) {
+   // debug code to try to figure out what's up.
+   LYXERR0(Failed to find marked arrow.\n
+   From:   from  , To:   
to);
+   dumpGraph();
 

if (lyxerr.debugging()) dumpGraph();
?

   
I'll remove the code at release if we don't find the problem by then. 
Right now, I'm hoping that anyone who sees this crash will see all the 
stuff that gets dumped and send it to me. I've been over and over this 
code and cannot see how we can assert here, though I've seen the crash 
myself. Possible that it's got to do with the cloning stuff.


rh

Re: result of a first test with LyX 2.0alpha2

[rgheck]

On 04/18/2010 07:19 PM, Uwe Stöhr wrote:

 but at least backtrace is possible?

No because I wasn't able to crash alpha2 the last hours :-)

But I noticed another very annoying behaviour:

When I export a file as PDF LyX asks me if I want to replace the 
existing PDF. This is OK, but replacing should be the default and not 
keeping.



No, on export we must ask.

Moreover LyX asks me after the first question if it should continue 
asking. No matter what I click in this dialog, LyX asks me the same 
again and again whenever I export a file as PDF. This is extremely 
annoying!



This is a bug.

rh

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

[rgheck]

On 04/18/2010 07:35 PM, v...@lyx.org wrote:

Author: vfr
Date: Mon Apr 19 01:35:59 2010
New Revision: 34215
URL: http://www.lyx.org/trac/changeset/34215

Log:
Fix bug #6659: InsetInfo context menu disabled unless cursor immediately in 
front.

   

Thanks, Vincent.

rh

Re: latex-lab?

[rgheck]

On 04/17/2010 10:38 PM, xPol wrote:

rgheck wrote:

   

I'm still wondering what precisely people want here. Porting LyX to an
AJAX application would be possible, but not something we on the
development team have anything near the time to do. So let me ask what I
asked before: What is it that people want to be able to do that you
can't do via version control?
 

I think what authors of maths text want is that everybody can read,  copy
and paste maths expressions in every usual form by which text are exchanged
on the web: email, web page.  As with plain text, math text should be
rendered in those common containers and straightforwardly copied into and
from the lyx processor.

   
LyX already reads and writes LaTeX math expressions. E.g., try the 
following. Highlight and copy this:

2^x
Now go to LyX. Hit Ctrl-M to get a math thingy, and paste. It also works 
the other way. Highlight the math inset in LyX and copy. Now paste into 
whatever you like.


If you think it would be good also to be able to do this with MathML, 
that can easily be arranged, at least for output. Going from MathML to 
LaTeX is not something we presently have the ability to do, but maybe 
there is a converter somewhere we could adapt.


Richard

Re: Master vs Child Preamble, Etc

[rgheck]

On 04/18/2010 03:42 AM, Jürgen Spitzmüller wrote:

rgheck wrote:
   

Given the common questions about this kind of thing, I wonder if we
should have a per-document setting that would allow the user to specify
that the params for a certain document are to be taken from the master,
if there is one. I would guess that this would only be active on output.

Has anyone tried to implement this kind of thing?
 

I have pondered about it, but did not come to implement it.

   
Here's the thought, then. As I suggested, we use the master's params 
only on output. The complication is that the params can be accessed from 
so many places. But they are always accessed via Buffer::params(), so we 
just need to arrange for Buffer::params() to return 
masterBuffer()->params() when we're doing output. If we're using clones 
for output, then this is easy: Just check isClone(). If we're not---I 
guess people who compile themselves can disable this---then maybe we 
need to set a flag. Either way, not too bad.


Thoughts?

Richard

Restore Last Position Bug Fixed?

[rgheck]

Has the bug concerning restoration of last file position been fixed in 
trunk? I.e., if you have bookmarks, then the code that updates their 
location before closing causes the last file position to be set to 
wherever the last bookmark is.


rh

Re: Master vs Child Preamble, Etc

[rgheck]

On 04/18/2010 10:38 AM, Jürgen Spitzmüller wrote:

rgheck wrote:
   

Here's the thought, then. As I suggested, we use the master's params
only on output. The complication is that the params can be accessed from
so many places. But they are always accessed via Buffer::params(), so we
just need to arrange for Buffer::params() to return
masterBuffer()->params() when we're doing output. If we're using clones
for output, then this is easy: Just check isClone(). If we're not---I
guess people who compile themselves can disable this---then maybe we
need to set a flag. Either way, not too bad.

Thoughts?
 

Even better would be to use in both on input and output, and to let the user
change these params in the document dialog from within each child.

   


I thought about this, and in a way it would be easy: Buffer::params() 
just has to return masterBuffer->params(). (Probably there are some 
complications?) But then I wondered if this is right: When we write the 
child, we'll write the master's params, since, in effect, the child 
doesn't even have its own. Is that what we want to do?



And of course, the default should still be to use the child's own params, as 
long as
we are not compiling with master-buffer-[view|update].

   

Of course.

rh

Re: r34213 - lyx-devel/trunk/src

[rgheck]

On 04/18/2010 07:17 PM, Pavel Sanda wrote:



if (it == en) {
+   // debug code to try to figure out what's up.
+   LYXERR0("Failed to find marked arrow.\n"
+   "From: "<<  from<<  ", To: "<<  
to);
+   dumpGraph();
 

if (lyxerr.debugging()) dumpGraph();
?

   
I'll remove the code at release if we don't find the problem by then. 
Right now, I'm hoping that anyone who sees this crash will see all the 
stuff that gets dumped and send it to me. I've been over and over this 
code and cannot see how we can assert here, though I've seen the crash 
myself. Possible that it's got to do with the cloning stuff.


rh

Re: result of a first test with LyX 2.0alpha2

[rgheck]

On 04/18/2010 07:19 PM, Uwe Stöhr wrote:

> but at least backtrace is possible?

No because I wasn't able to crash alpha2 the last hours :-)

But I noticed another very annoying behaviour:

When I export a file as PDF LyX asks me if I want to replace the 
existing PDF. This is OK, but replacing should be the default and not 
keeping.



No, on export we must ask.

Moreover LyX asks me after the first question if it should continue 
asking. No matter what I click in this dialog, LyX asks me the same 
again and again whenever I export a file as PDF. This is extremely 
annoying!



This is a bug.

rh

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

[rgheck]

On 04/18/2010 07:35 PM, v...@lyx.org wrote:

Author: vfr
Date: Mon Apr 19 01:35:59 2010
New Revision: 34215
URL: http://www.lyx.org/trac/changeset/34215

Log:
Fix bug #6659: InsetInfo context menu disabled unless cursor immediately in 
front.

   

Thanks, Vincent.

rh

Re: buffer new on tabbar double click

[rgheck]

On 04/17/2010 07:34 AM, Edwin Leuven wrote:

any objections to the attached?

   
If I'm reading it right, this happens only when you double click into an 
empty area of the tab bar, right? If so, fine with me.


rh

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

[rgheck]

On 04/17/2010 09:34 AM, rgh...@lyx.org wrote:

Author: rgheck
Date: Sat Apr 17 15:34:13 2010
New Revision: 34190
URL: http://www.lyx.org/trac/changeset/34190

Log:
Disable InsetInfo for VC when VC is not active.

   
It would probably be better to let the various backends tell us what 
they handle, but this is better than nothing.


rh


Modified:
lyx-devel/trunk/src/insets/InsetInfo.cpp

Modified: lyx-devel/trunk/src/insets/InsetInfo.cpp
==
--- lyx-devel/trunk/src/insets/InsetInfo.cppSat Apr 17 15:29:00 2010
(r34189)
+++ lyx-devel/trunk/src/insets/InsetInfo.cppSat Apr 17 15:34:13 2010
(r34190)
@@ -155,9 +155,11 @@
  {
string type;
string const name = trim(split(to_utf8(arg), type, ' '));
+
switch (nameTranslator().find(type)) {
case UNKNOWN_INFO:
return false;
+
case SHORTCUT_INFO:
case SHORTCUTS_INFO:
case MENU_INFO:
@@ -165,21 +167,29 @@
FuncRequest func = lyxaction.lookupFunc(name);
return func.action() != LFUN_UNKNOWN_ACTION;
}
+
case LYXRC_INFO: {
ostringstream oss;
lyxrc.write(oss, true, name);
return !oss.str().empty();
}
+
case PACKAGE_INFO:
case TEXTCLASS_INFO:
return true;
+
case BUFFER_INFO:
-   return name == name || name == path || name == class ||
-  name == vcs-revision || name == vcs-tree-revision ||
-  name == vcs-author || name == vcs-date || name == 
vcs-time;
+   if (name == name || name == path || name == class)
+   return true;
+   if (name == vcs-revision || name == vcs-tree-revision ||
+  name == vcs-author || name == vcs-date || name == 
vcs-time)
+   return buffer().lyxvc().inUse();
+   return false;
+
case LYX_INFO:
return name == version;
}
+
return false;
  }

   

InsetInfo Context Menu Problems

[rgheck]

The context menu seems to be completely disabled unless the cursor is 
directly in front of the InsetInfo.


rh

Re: latex-lab?

[rgheck]

On 04/17/2010 12:38 PM, xPol wrote:

Do you think that the latex-lab project, an  implementation of a web based
LaTeX editor for Google Docs, could be exploited to carry lyx on the web?
Here: http://code.google.com/p/latex-lab/

   
The idea behind this sort of thing could be adapted, but the LaTeX 
editor itself doesn't help us.


I'm still wondering what precisely people want here. Porting LyX to an 
AJAX application would be possible, but not something we on the 
development team have anything near the time to do. So let me ask what I 
asked before: What is it that people want to be able to do that you 
can't do via version control? If the answer is Edit a document 
simultaneously with someone on the other side of the planet, with both 
of us instantly seeing each other's changes, then I'd suggest learning 
about the LyX server and seeing if there isn't some way to adapt it to 
do the necessary work by tunnelling a connection over ssh.


Richard

Re: r34186 - in lyx-devel/trunk: lib/lyx2lyx src src/frontends/qt4 src/insets

[rgheck]

On 04/17/2010 02:16 PM, Enrico Forestieri wrote:

On Sat, Apr 17, 2010 at 03:04:41PM +0200, rgh...@lyx.org wrote:

   

Author: rgheck
Date: Sat Apr 17 15:04:41 2010
New Revision: 34186
URL: http://www.lyx.org/trac/changeset/34186

Log:
LyX version info for InsetInfo.
 

I am not able to load old documents anymore:

Traceback (most recent call last):
   File /usr/local/src/lyx/lyx-devel/lib/lyx2lyx/lyx2lyx, line 23, inmodule
 import LyX
   File /usr/local/src/lyx/lyx-devel/lib/lyx2lyx/LyX.py, line 91, inmodule
 convert = getattr(__import__(lyx_ + step), mode)
   File /usr/local/src/lyx/lyx-devel/lib/lyx2lyx/lyx_2_0.py, line 25, 
inmodule
 import lyx2lyx_version
ImportError: No module named lyx2lyx_version
Error: Conversion script failed

/home/ef/newfile3.lyx is from an older version of LyX, but the lyx2lyx script 
failed to convert it.

The problem seems to be that lyx2lyx_version.py gets generated in the
build dir, whereas python expects it in the source dir?

   
I'm not sure what the problem is. It works fine here (F12), though I 
haven't tried it except running from the build dir. Anybody else have an 
idea?


rh

Master vs Child Preamble, Etc

[rgheck]

Given the common questions about this kind of thing, I wonder if we 
should have a per-document setting that would allow the user to specify 
that the params for a certain document are to be taken from the master, 
if there is one. I would guess that this would only be active on output.


Has anyone tried to implement this kind of thing?

rh

Re: r34186 - in lyx-devel/trunk: lib/lyx2lyx src src/frontends/qt4 src/insets

[rgheck]

On 04/17/2010 05:19 PM, Enrico Forestieri wrote:

On Sat, Apr 17, 2010 at 03:30:10PM -0400, rgheck wrote:

   

On 04/17/2010 02:16 PM, Enrico Forestieri wrote:
 

On Sat, Apr 17, 2010 at 03:04:41PM +0200, rgh...@lyx.org wrote:

   

Author: rgheck
Date: Sat Apr 17 15:04:41 2010
New Revision: 34186
URL: http://www.lyx.org/trac/changeset/34186

Log:
LyX version info for InsetInfo.
 

I am not able to load old documents anymore:

Traceback (most recent call last):
   File /usr/local/src/lyx/lyx-devel/lib/lyx2lyx/lyx2lyx, line 23, inmodule
 import LyX
   File /usr/local/src/lyx/lyx-devel/lib/lyx2lyx/LyX.py, line 91, inmodule
 convert = getattr(__import__(lyx_ + step), mode)
   File /usr/local/src/lyx/lyx-devel/lib/lyx2lyx/lyx_2_0.py, line 25, 
inmodule
 import lyx2lyx_version
ImportError: No module named lyx2lyx_version
Error: Conversion script failed

/home/ef/newfile3.lyx is from an older version of LyX, but the lyx2lyx script 
failed to convert it.

The problem seems to be that lyx2lyx_version.py gets generated in the
build dir, whereas python expects it in the source dir?

   

I'm not sure what the problem is. It works fine here (F12), though I
haven't tried it except running from the build dir. Anybody else
have an idea?
 

The problem occurs only when running from the build dir and the only
solution I found is copying lyx2lyx_version.py to the source dir:

   cpbuilddir/lib/lyx2lyx/lyx2lyx_version.pysrcdir/lib/lyx2lyx/

   
What build system is this with? I should say I'm no expert on any of 
these. Is the issue that this file isn't being copied to somewhere it 
ought to be?


rh

Re: Crash when module not found

[rgheck]

On 04/17/2010 06:06 PM, BH wrote:

Stephan's build of LyX-2.0-alpha2 creates a new user's directory for
me. When I don't copy over my standard modules but try to open a file
that requires one, I get a crash.

   

I thought something like this might be about to happen. I've fixed it.

rh

Re: r34186 - in lyx-devel/trunk: lib/lyx2lyx src src/frontends/qt4 src/insets

[rgheck]

On 04/17/2010 07:03 PM, Enrico Forestieri wrote:


This is with autotools. The file will be copied to the right place but
only when installing. The problem occurs when you run lyx in place
(without installing it) and I am surprised that it works for you.

   

I'll check it with a fresh co.

rh

Re: r34186 - in lyx-devel/trunk: lib/lyx2lyx src src/frontends/qt4 src/insets

[rgheck]

On 04/17/2010 08:07 PM, Enrico Forestieri wrote:


Please, see lib/lyx2lyx/LyX.py for a workaround to the
import lyx2lyx_version problem when running from build directory.

   
I saw that before, but the sad thing is it would require replicating the 
hard-coded string in two places. I'm still thinking. For now, we can do 
something safe.


rh

Re: buffer new on tabbar double click

[rgheck]

On 04/17/2010 07:34 AM, Edwin Leuven wrote:

any objections to the attached?

   
If I'm reading it right, this happens only when you double click into an 
empty area of the tab bar, right? If so, fine with me.


rh

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

[rgheck]

On 04/17/2010 09:34 AM, rgh...@lyx.org wrote:

Author: rgheck
Date: Sat Apr 17 15:34:13 2010
New Revision: 34190
URL: http://www.lyx.org/trac/changeset/34190

Log:
Disable InsetInfo for VC when VC is not active.

   
It would probably be better to let the various backends tell us what 
they handle, but this is better than nothing.


rh


Modified:
lyx-devel/trunk/src/insets/InsetInfo.cpp

Modified: lyx-devel/trunk/src/insets/InsetInfo.cpp
==
--- lyx-devel/trunk/src/insets/InsetInfo.cppSat Apr 17 15:29:00 2010
(r34189)
+++ lyx-devel/trunk/src/insets/InsetInfo.cppSat Apr 17 15:34:13 2010
(r34190)
@@ -155,9 +155,11 @@
  {
string type;
string const name = trim(split(to_utf8(arg), type, ' '));
+
switch (nameTranslator().find(type)) {
case UNKNOWN_INFO:
return false;
+
case SHORTCUT_INFO:
case SHORTCUTS_INFO:
case MENU_INFO:
@@ -165,21 +167,29 @@
FuncRequest func = lyxaction.lookupFunc(name);
return func.action() != LFUN_UNKNOWN_ACTION;
}
+
case LYXRC_INFO: {
ostringstream oss;
lyxrc.write(oss, true, name);
return !oss.str().empty();
}
+
case PACKAGE_INFO:
case TEXTCLASS_INFO:
return true;
+
case BUFFER_INFO:
-   return name == "name" || name == "path" || name == "class" ||
-  name == "vcs-revision" || name == "vcs-tree-revision" ||
-  name == "vcs-author" || name == "vcs-date" || name == 
"vcs-time";
+   if (name == "name" || name == "path" || name == "class")
+   return true;
+   if (name == "vcs-revision" || name == "vcs-tree-revision" ||
+  name == "vcs-author" || name == "vcs-date" || name == 
"vcs-time")
+   return buffer().lyxvc().inUse();
+   return false;
+
case LYX_INFO:
return name == "version";
}
+
return false;
  }

   

InsetInfo Context Menu Problems

[rgheck]

The context menu seems to be completely disabled unless the cursor is 
directly in front of the InsetInfo.


rh

Re: latex-lab?

[rgheck]

On 04/17/2010 12:38 PM, xPol wrote:

Do you think that the latex-lab project, an  implementation of a web based
LaTeX editor for Google Docs, could be exploited to carry lyx on the web?
Here: http://code.google.com/p/latex-lab/

   
The idea behind this sort of thing could be adapted, but the LaTeX 
editor itself doesn't help us.


I'm still wondering what precisely people want here. Porting LyX to an 
AJAX application would be possible, but not something we on the 
development team have anything near the time to do. So let me ask what I 
asked before: What is it that people want to be able to do that you 
can't do via version control? If the answer is "Edit a document 
simultaneously with someone on the other side of the planet, with both 
of us instantly seeing each other's changes", then I'd suggest learning 
about the LyX server and seeing if there isn't some way to adapt it to 
do the necessary work by tunnelling a connection over ssh.


Richard

Re: r34186 - in lyx-devel/trunk: lib/lyx2lyx src src/frontends/qt4 src/insets

[rgheck]

On 04/17/2010 02:16 PM, Enrico Forestieri wrote:

On Sat, Apr 17, 2010 at 03:04:41PM +0200, rgh...@lyx.org wrote:

   

Author: rgheck
Date: Sat Apr 17 15:04:41 2010
New Revision: 34186
URL: http://www.lyx.org/trac/changeset/34186

Log:
LyX version info for InsetInfo.
 

I am not able to load old documents anymore:

Traceback (most recent call last):
   File "/usr/local/src/lyx/lyx-devel/lib/lyx2lyx/lyx2lyx", line 23, in
 import LyX
   File "/usr/local/src/lyx/lyx-devel/lib/lyx2lyx/LyX.py", line 91, in
 convert = getattr(__import__("lyx_" + step), mode)
   File "/usr/local/src/lyx/lyx-devel/lib/lyx2lyx/lyx_2_0.py", line 25, 
in
 import lyx2lyx_version
ImportError: No module named lyx2lyx_version
Error: Conversion script failed

/home/ef/newfile3.lyx is from an older version of LyX, but the lyx2lyx script 
failed to convert it.

The problem seems to be that lyx2lyx_version.py gets generated in the
build dir, whereas python expects it in the source dir?

   
I'm not sure what the problem is. It works fine here (F12), though I 
haven't tried it except running from the build dir. Anybody else have an 
idea?


rh

Master vs Child Preamble, Etc

[rgheck]

Given the common questions about this kind of thing, I wonder if we 
should have a per-document setting that would allow the user to specify 
that the params for a certain document are to be taken from the master, 
if there is one. I would guess that this would only be active on output.


Has anyone tried to implement this kind of thing?

rh

Re: r34186 - in lyx-devel/trunk: lib/lyx2lyx src src/frontends/qt4 src/insets

[rgheck]

On 04/17/2010 05:19 PM, Enrico Forestieri wrote:

On Sat, Apr 17, 2010 at 03:30:10PM -0400, rgheck wrote:

   

On 04/17/2010 02:16 PM, Enrico Forestieri wrote:
 

On Sat, Apr 17, 2010 at 03:04:41PM +0200, rgh...@lyx.org wrote:

   

Author: rgheck
Date: Sat Apr 17 15:04:41 2010
New Revision: 34186
URL: http://www.lyx.org/trac/changeset/34186

Log:
LyX version info for InsetInfo.
 

I am not able to load old documents anymore:

Traceback (most recent call last):
   File "/usr/local/src/lyx/lyx-devel/lib/lyx2lyx/lyx2lyx", line 23, in
 import LyX
   File "/usr/local/src/lyx/lyx-devel/lib/lyx2lyx/LyX.py", line 91, in
 convert = getattr(__import__("lyx_" + step), mode)
   File "/usr/local/src/lyx/lyx-devel/lib/lyx2lyx/lyx_2_0.py", line 25, 
in
 import lyx2lyx_version
ImportError: No module named lyx2lyx_version
Error: Conversion script failed

/home/ef/newfile3.lyx is from an older version of LyX, but the lyx2lyx script 
failed to convert it.

The problem seems to be that lyx2lyx_version.py gets generated in the
build dir, whereas python expects it in the source dir?

   

I'm not sure what the problem is. It works fine here (F12), though I
haven't tried it except running from the build dir. Anybody else
have an idea?
 

The problem occurs only when running from the build dir and the only
solution I found is copying lyx2lyx_version.py to the source dir:

   cp/lib/lyx2lyx/lyx2lyx_version.py/lib/lyx2lyx/

   
What build system is this with? I should say I'm no expert on any of 
these. Is the issue that this file isn't being copied to somewhere it 
ought to be?


rh

Re: Crash when module not found

[rgheck]

On 04/17/2010 06:06 PM, BH wrote:

Stephan's build of LyX-2.0-alpha2 creates a new user's directory for
me. When I don't copy over my standard modules but try to open a file
that requires one, I get a crash.

   

I thought something like this might be about to happen. I've fixed it.

rh

Re: r34186 - in lyx-devel/trunk: lib/lyx2lyx src src/frontends/qt4 src/insets

[rgheck]

On 04/17/2010 07:03 PM, Enrico Forestieri wrote:


This is with autotools. The file will be copied to the right place but
only when installing. The problem occurs when you run lyx in place
(without installing it) and I am surprised that it works for you.

   

I'll check it with a fresh co.

rh

Re: r34186 - in lyx-devel/trunk: lib/lyx2lyx src src/frontends/qt4 src/insets

[rgheck]

On 04/17/2010 08:07 PM, Enrico Forestieri wrote:


Please, see lib/lyx2lyx/LyX.py for a workaround to the
"import lyx2lyx_version" problem when running from build directory.

   
I saw that before, but the sad thing is it would require replicating the 
hard-coded string in two places. I'm still thinking. For now, we can do 
something safe.


rh

Re: r34149 - in lyx-devel/trunk: lib/ui src src/frontends/qt4 src/frontends/qt4/ui

[rgheck]

On 04/16/2010 10:26 AM, Pavel Sanda wrote:

sa...@lyx.org wrote:
   

Author: sanda
Date: Fri Apr 16 10:09:07 2010
New Revision: 34149
URL: http://www.lyx.org/trac/changeset/34149

Log:
Guify forward search.
No viewer set by default, which keeps context menu clean for uninterested users.
Settings are hinted at combobox.
 
   

+   dviCB-addItem(xdvi -sourceposition $$n:$$t $$o);
+   dviCB-addItem(yap -1 -s $$n$$t $$o);
+   pdfCB-addItem();
+   pdfCB-addItem(CMCDDE SUMATRA control 
[ForwardSearch(\\\$$o\\\,\\\$$t\\\,$$n,0,0,1)]);
 

anybody around using xpdf/evince/okular to check whether it supports commands 
for forard search?

   
The latter two seem to support going to a particular page, but nothing 
more complicated. That said, this

http://docs.kde.org/development/en/extragear-office/kile/quick_forward.html
suggests that maybe it is possible, though maybe that is just going to 
the page.


rh

Re: r34149 - in lyx-devel/trunk: lib/ui src src/frontends/qt4 src/frontends/qt4/ui

[rgheck]

On 04/16/2010 10:26 AM, Pavel Sanda wrote:

sa...@lyx.org wrote:
   

Author: sanda
Date: Fri Apr 16 10:09:07 2010
New Revision: 34149
URL: http://www.lyx.org/trac/changeset/34149

Log:
Guify forward search.
No viewer set by default, which keeps context menu clean for uninterested users.
Settings are hinted at combobox.
 
   

+   dviCB-addItem(xdvi -sourceposition $$n:$$t $$o);
+   dviCB-addItem(yap -1 -s $$n$$t $$o);
+   pdfCB-addItem();
+   pdfCB-addItem(CMCDDE SUMATRA control 
[ForwardSearch(\\\$$o\\\,\\\$$t\\\,$$n,0,0,1)]);
 

anybody around using xpdf/evince/okular to check whether it supports commands 
for forard search?

   

Well, with okular, I found this thread. I don't know what the status is:

http://www.mail-archive.com/okular-de...@kde.org/msg04051.html

rh

Re: r34149 - in lyx-devel/trunk: lib/ui src src/frontends/qt4 src/frontends/qt4/ui

[rgheck]

On 04/16/2010 10:26 AM, Pavel Sanda wrote:

sa...@lyx.org wrote:
   

Author: sanda
Date: Fri Apr 16 10:09:07 2010
New Revision: 34149
URL: http://www.lyx.org/trac/changeset/34149

Log:
Guify forward search.
No viewer set by default, which keeps context menu clean for uninterested users.
Settings are hinted at combobox.
 
   

+   dviCB->addItem("xdvi -sourceposition $$n:$$t $$o");
+   dviCB->addItem("yap -1 -s $$n$$t $$o");
+   pdfCB->addItem("");
+   pdfCB->addItem("CMCDDE SUMATRA control 
[ForwardSearch(\\\"$$o\\\",\\\"$$t\\\",$$n,0,0,1)]");
 

anybody around using xpdf/evince/okular to check whether it supports commands 
for forard search?

   
The latter two seem to support going to a particular page, but nothing 
more complicated. That said, this

http://docs.kde.org/development/en/extragear-office/kile/quick_forward.html
suggests that maybe it is possible, though maybe that is just going to 
the page.


rh

Re: r34149 - in lyx-devel/trunk: lib/ui src src/frontends/qt4 src/frontends/qt4/ui

[rgheck]

On 04/16/2010 10:26 AM, Pavel Sanda wrote:

sa...@lyx.org wrote:
   

Author: sanda
Date: Fri Apr 16 10:09:07 2010
New Revision: 34149
URL: http://www.lyx.org/trac/changeset/34149

Log:
Guify forward search.
No viewer set by default, which keeps context menu clean for uninterested users.
Settings are hinted at combobox.
 
   

+   dviCB->addItem("xdvi -sourceposition $$n:$$t $$o");
+   dviCB->addItem("yap -1 -s $$n$$t $$o");
+   pdfCB->addItem("");
+   pdfCB->addItem("CMCDDE SUMATRA control 
[ForwardSearch(\\\"$$o\\\",\\\"$$t\\\",$$n,0,0,1)]");
 

anybody around using xpdf/evince/okular to check whether it supports commands 
for forard search?

   

Well, with okular, I found this thread. I don't know what the status is:

http://www.mail-archive.com/okular-de...@kde.org/msg04051.html

rh

Re: Preferences panels

[rgheck]

On 04/14/2010 10:16 PM, Pavel Sanda wrote:

hi,

our tools-preferences-output panels are now completely unbalanced.
latex pane overflows with items, while date format and plain text
are orphans. what about joining these two into one general panel?

   

Sounds good.


Richard do you plan some xhtml setting and if so, how many -- instead
of merging we can let one for xhtml stuff...

   
Yes, there will be a few XHTML settings. Probably one check box (strict 
XHTML versus not so strict), one combo box (math output type), and one 
text field (scaling factor for math images).


Richard

Re: [Patch] #94 - LYX forward DVI search.

[rgheck]

On 04/14/2010 10:09 PM, Pavel Sanda wrote:

diff --git a/src/LyXAction.cpp b/src/LyXAction.cpp
index 053680a..32a2604 100644
--- a/src/LyXAction.cpp
+++ b/src/LyXAction.cpp
@@ -2825,6 +2825,23 @@ void LyXAction::init()
   */
{ LFUN_SERVER_GOTO_FILE_ROW, server-goto-file-row, ReadOnly | 
NoBuffer, System },
  /*!
+ * \var lyx::FuncCode lyx::LFUN_FORWARD_SEARCH
+ * \li Action: Sets the cursor position in the previewed (e.g. dvi) file based 
on the row
+   number in LyX window.
+ * \li Notion: The external program used for forward search call can be 
specified in
+   \\forward_search RC setting. By default its value is\n
+  xdvi -sourceposition $$n:$$t $$o\n
+  The values replaced in the call: $$n for row number, $$t for
+  exported temporary .tex file, $$o exported output file, either
+  dvi or pdf, depending on the argument of #LFUN_FORWARD_SEARCH.
+ * \li Syntax: forward-search [dvi|pdf]
+ * \li Params: By default dvi route is taken.
+ * \li Origin: sanda, 14 Apr 2010
+ * \endvar
+ */
   


Would it be possible somehow to set this based upon which viewer the 
user has selected? It seems a pain to have to configure the viewer and 
then also configure its forward search command. We'd have to have some 
map somewhere from possible viewers to commands


rh

Re: Preferences panels

[rgheck]

On 04/15/2010 11:06 AM, Pavel Sanda wrote:

Richard Heck wrote:
   

Yes, there will be a few XHTML settings. Probably one check box (strict
XHTML versus not so strict), one combo box (math output type), and one text
field (scaling factor for math images).
 

ok there is place for xhtml in general panel now.

   

OK. I shall eventually put it there.

rh

Re: Preferences panels

[rgheck]

On 04/14/2010 10:16 PM, Pavel Sanda wrote:

hi,

our tools->preferences->output panels are now completely unbalanced.
latex pane overflows with items, while "date format" and "plain text"
are orphans. what about joining these two into one "general" panel?

   

Sounds good.


Richard do you plan some xhtml setting and if so, how many -- instead
of merging we can let one for xhtml stuff...

   
Yes, there will be a few XHTML settings. Probably one check box (strict 
XHTML versus not so strict), one combo box (math output type), and one 
text field (scaling factor for math images).


Richard

Re: [Patch] #94 - LYX forward DVI search.

[rgheck]

On 04/14/2010 10:09 PM, Pavel Sanda wrote:

diff --git a/src/LyXAction.cpp b/src/LyXAction.cpp
index 053680a..32a2604 100644
--- a/src/LyXAction.cpp
+++ b/src/LyXAction.cpp
@@ -2825,6 +2825,23 @@ void LyXAction::init()
   */
{ LFUN_SERVER_GOTO_FILE_ROW, "server-goto-file-row", ReadOnly | 
NoBuffer, System },
  /*!
+ * \var lyx::FuncCode lyx::LFUN_FORWARD_SEARCH
+ * \li Action: Sets the cursor position in the previewed (e.g. dvi) file based 
on the row
+   number in LyX window.
+ * \li Notion: The external program used for forward search call can be 
specified in
+   \\forward_search RC setting. By default its value is\n
+  "xdvi -sourceposition $$n:$$t $$o"\n
+  The values replaced in the call: $$n for row number, $$t for
+  exported temporary .tex file, $$o exported output file, either
+  dvi or pdf, depending on the argument of #LFUN_FORWARD_SEARCH.
+ * \li Syntax: forward-search [dvi|pdf]
+ * \li Params: By default dvi route is taken.
+ * \li Origin: sanda, 14 Apr 2010
+ * \endvar
+ */
   


Would it be possible somehow to set this based upon which viewer the 
user has selected? It seems a pain to have to configure the viewer and 
then also configure its forward search command. We'd have to have some 
map somewhere from possible viewers to commands


rh

Re: Preferences panels

[rgheck]

On 04/15/2010 11:06 AM, Pavel Sanda wrote:

Richard Heck wrote:
   

Yes, there will be a few XHTML settings. Probably one check box (strict
XHTML versus not so strict), one combo box (math output type), and one text
field (scaling factor for math images).
 

ok there is place for xhtml in general panel now.

   

OK. I shall eventually put it there.

rh

Re: posible bug: url and percentage

[rgheck]

On 04/14/2010 03:10 AM, Guenter Milde wrote:

On 2010-04-13, Fox_Van wrote:
   


*FOOTNOTE[* Making R Packages Under Windows: A Tutorial. *URL[*
http://faculty.chicagobooth.edu/peter.rossi/research/bayes%20book/bayesm/Making%20R%20Packages%20Under%20Windows.pdf
]* ]*
 
When I removed the percentage symbols everything worked correctly. I

did not found any related ticket on trac.
 

If a string contains any %, #, or ^^, or ends with ``\``, it can't
be used in the argument to another command. The argument must not contain
unbalanced braces.

We need to escape #, \, and % if we use the URL in a command.

This is done with InsertHyperref but not with InsertURL
(tested with LyX 2.0)

   

This looks like bug 449, more or less.

rh

Re: r34130 - lyx-devel/trunk/src

[rgheck]

On 04/14/2010 07:54 AM, v...@lyx.org wrote:

Author: vfr
Date: Wed Apr 14 13:54:12 2010
New Revision: 34130
URL: http://www.lyx.org/trac/changeset/34130

Log:
Fix bug #6651: No error messages when module dependencies are not fulfilled.

We need to throw the ExceptionMessage's.

   
Can you tell me what happens when this exception gets thrown? (I have no 
idea why I didn't throw it.)


rh


Modified:
lyx-devel/trunk/src/TextClass.cpp

Modified: lyx-devel/trunk/src/TextClass.cpp
==
--- lyx-devel/trunk/src/TextClass.cpp   Tue Apr 13 20:56:28 2010(r34129)
+++ lyx-devel/trunk/src/TextClass.cpp   Wed Apr 14 13:54:12 2010(r34130)
@@ -1278,7 +1278,7 @@
this document but has not been 
found in the list of\n
available modules. If you recently 
installed it, you\n
probably need to reconfigure 
LyX.\n), from_utf8(modName));
-   ExceptionMessage(WarningException,_(Module not 
available),
+   throw ExceptionMessage(WarningException,_(Module not 
available),
msg + _(Some layouts may not be 
available.));
continue;
}
@@ -1287,7 +1287,7 @@
bformat(_(The module %1$s requires 
a package that is\n
not available in your LaTeX 
installation. LaTeX output\n
may not be possible.\n), 
from_utf8(modName));
-   ExceptionMessage(WarningException, _(Package not 
available), msg);
+   throw ExceptionMessage(WarningException, _(Package not 
available), msg);
}
FileName layout_file = libFileSearch(layouts, 
lm-getFilename());
if (!doc_class.read(layout_file, TextClass::MODULE)) {
   

Re: r34130 - lyx-devel/trunk/src

[rgheck]

On 04/14/2010 08:11 AM, Vincent van Ravesteijn - TNW wrote:

Author: vfr
Date: Wed Apr 14 13:54:12 2010
New Revision: 34130
URL: http://www.lyx.org/trac/changeset/34130

Log:
Fix bug #6651: No error messages when module dependencies are not
   

fulfilled.
   

We need to throw the ExceptionMessage's.


   

Can you tell me what happens when this exception gets thrown? (I have
no idea why I didn't throw it.)
 

The user get's a message box with a warning that he might not generate
any output. (or do you mean something else ?).

   
OK. I'll check this later. I'm guessing that maybe the output routine 
aborts, in which case the message should be changed.



You did throw it in one of the three cases in the function.

   
Brain freeze, then. I think I also didn't understand exceptions very 
well back then.


rh

Re: r34130 - lyx-devel/trunk/src

[rgheck]

On 04/14/2010 08:45 AM, Vincent van Ravesteijn - TNW wrote:


   

Can you tell me what happens when this exception gets thrown? (I
 

have
   

no idea why I didn't throw it.)

 

The user get's a message box with a warning that he might not
   

generate
   

any output. (or do you mean something else ?).


   

OK. I'll check this later. I'm guessing that maybe the
output routine aborts, in which case the message should
be changed.
 

We are not outputting anything yet. It's just when you press Add, you
get a warning that you might not get decent output later on. The module
just gets added and nothing special happens further.

   

Ahh, OK. Sorry, I thought it was in the output routine.

rh

Re: posible bug: url and percentage

[rgheck]

On 04/14/2010 03:10 AM, Guenter Milde wrote:

On 2010-04-13, Fox_Van wrote:
   


*FOOTNOTE[* Making R Packages Under Windows: A Tutorial. *URL[*
http://faculty.chicagobooth.edu/peter.rossi/research/bayes%20book/bayesm/Making%20R%20Packages%20Under%20Windows.pdf
]* ]*
 
When I removed the percentage symbols everything worked correctly. I

did not found any related ticket on trac.
 

If a string contains any "%", "#", or "^^", or ends with ``\``, it can't
be used in the argument to another command. The argument must not contain
unbalanced braces.

We need to escape #, \, and % if we use the URL in a command.

This is done with Insert>Hyperref but not with Insert>URL
(tested with LyX 2.0)

   

This looks like bug 449, more or less.

rh

Re: r34130 - lyx-devel/trunk/src

[rgheck]

On 04/14/2010 07:54 AM, v...@lyx.org wrote:

Author: vfr
Date: Wed Apr 14 13:54:12 2010
New Revision: 34130
URL: http://www.lyx.org/trac/changeset/34130

Log:
Fix bug #6651: No error messages when module dependencies are not fulfilled.

We need to throw the ExceptionMessage's.

   
Can you tell me what happens when this exception gets thrown? (I have no 
idea why I didn't throw it.)


rh


Modified:
lyx-devel/trunk/src/TextClass.cpp

Modified: lyx-devel/trunk/src/TextClass.cpp
==
--- lyx-devel/trunk/src/TextClass.cpp   Tue Apr 13 20:56:28 2010(r34129)
+++ lyx-devel/trunk/src/TextClass.cpp   Wed Apr 14 13:54:12 2010(r34130)
@@ -1278,7 +1278,7 @@
"this document but has not been 
found in the list of\n"
"available modules. If you recently 
installed it, you\n"
"probably need to reconfigure 
LyX.\n"), from_utf8(modName));
-   ExceptionMessage(WarningException,_("Module not 
available"),
+   throw ExceptionMessage(WarningException,_("Module not 
available"),
msg + _("Some layouts may not be 
available."));
continue;
}
@@ -1287,7 +1287,7 @@
bformat(_("The module %1$s requires 
a package that is\n"
"not available in your LaTeX 
installation. LaTeX output\n"
"may not be possible.\n"), 
from_utf8(modName));
-   ExceptionMessage(WarningException, _("Package not 
available"), msg);
+   throw ExceptionMessage(WarningException, _("Package not 
available"), msg);
}
FileName layout_file = libFileSearch("layouts", 
lm->getFilename());
if (!doc_class.read(layout_file, TextClass::MODULE)) {
   

Re: r34130 - lyx-devel/trunk/src

[rgheck]

On 04/14/2010 08:11 AM, Vincent van Ravesteijn - TNW wrote:

Author: vfr
Date: Wed Apr 14 13:54:12 2010
New Revision: 34130
URL: http://www.lyx.org/trac/changeset/34130

Log:
Fix bug #6651: No error messages when module dependencies are not
   

fulfilled.
   

We need to throw the ExceptionMessage's.


   

Can you tell me what happens when this exception gets thrown? (I have
no idea why I didn't throw it.)
 

The user get's a message box with a warning that he might not generate
any output. (or do you mean something else ?).

   
OK. I'll check this later. I'm guessing that maybe the output routine 
aborts, in which case the message should be changed.



You did throw it in one of the three cases in the function.

   
Brain freeze, then. I think I also didn't understand exceptions very 
well back then.


rh

Re: r34130 - lyx-devel/trunk/src

[rgheck]

On 04/14/2010 08:45 AM, Vincent van Ravesteijn - TNW wrote:


   

Can you tell me what happens when this exception gets thrown? (I
 

have
   

no idea why I didn't throw it.)

 

The user get's a message box with a warning that he might not
   

generate
   

any output. (or do you mean something else ?).


   

OK. I'll check this later. I'm guessing that maybe the
output routine aborts, in which case the message should
be changed.
 

We are not outputting anything yet. It's just when you press Add, you
get a warning that you might not get decent output later on. The module
just gets added and nothing special happens further.

   

Ahh, OK. Sorry, I thought it was in the output routine.

rh

Re: LyX/Mac Maintainer

[rgheck]

On 04/11/2010 10:30 PM, BH wrote:

Stephen Witt has been doing some great things for LyX/Mac. Given that
I have not had time or expertise to really advance LyX/Mac, and given
his abilities and enthusiasm, I have asked him if he would like to
take over as LyX/Mac maintainer. He has agreed.

For now, at least, the plan is for Stephen to take over the
LyX/Mac-2.0.0 release but leave at least the 1.6.6 release to me.
(We'll see what happens for 1.6.7.)

I've given Stephen the XCode source for LyX-installer.app. As I've
indicated before, I think we ought to do away with a separate
installer in favor of a script that can get run when LyX is launched.
But I'll leave the decision of what to do with it up to Stephen. (If
the installer persists, though, it should go into the svn repository.)

As I told Stephen, I'll still be around on the devel and users list,
still compiling recent trunk and branch, still pestering people to fix
Mac and other bugs, etc. And, of course, I'll still be using and
benefiting from LyX itself, without which I'd now find it very hard to
do any serious work.

So thanks, Stephen, for your good work so far and for the
contributions I'm sure you'll make in the future.

   
And thanks, Bennett, for your work as LyX/Mac maintainer. We'll thank 
you for the other stuff you mentioned later. ;-)


rh

Re: r34120 - lyx-devel/trunk/src

[rgheck]

On 04/12/2010 11:31 AM, Pavel Sanda wrote:

Vincent van Ravesteijn - TNW wrote:
   

-   : action_(LFUN_NOACTION), origin_(o), x_(0), y_(0),
+   : argument_(0), action_(LFUN_NOACTION), origin_(o), x_(0),
   

y_(0),
 
   

What's the rationale about initializing a docstring with 0 ? (Does it
even compile ?)
 

hrmpf, i only wanted to add something for the place of argument_. now this 
patch is buggy,
maybe even the next one i'm commiting right now... ;)
i want to have response from the reporter.

the whole thing is strange. since crash came from destructor and the only
thing really _changed_ in Richard's patch was the sequence of initialization -
my guess was it could be related because of missing argument.

   
I've tried restoring the initialization order. Otherwise, yes, it is 
VERY strange. Note that this comes from LyX.cpp:531:

lyx::dispatch(FuncRequest(LFUN_WINDOW_NEW, geometryArg));
So the constructor was actually this one:
FuncRequest::FuncRequest(FuncCode act, string const  arg, Origin o)
: argument_(from_utf8(arg)), action_(act), origin_(o), x_(0), 
y_(0),

  button_(mouse_button::none)
{}
which initializes argument_ just fine.

Apparently, you guess didn't help, so I've reverted it. Now he can just 
try the patch that changes back the initialization order. I've also 
suggested he try a fresh checkout.


rh

Re: r34120 - lyx-devel/trunk/src

[rgheck]

On 04/12/2010 02:25 PM, Pavel Sanda wrote:

Vincent van Ravesteijn - TNW wrote:
   

ehh, i thought from the one without argument, no?

FuncRequest? (this=0x8c0111c, act=lyx::LFUN_UNKNOWN_ACTION,
o=lyx::FuncRequest::INTERNAL) at FuncRequest?.cpp:39
   

Please read further:

#11 0x081a00c8 in static_initialization_and_destruction_0 ()
at FuncRequest?.cpp:28

This is your 0 initialization hack.
 

no that backtrace is from the tree, which doesn't contain 0 hack anymore.
anyway Richard hit the nail on the head in between - the problem was most
probably due to the linking with old object files after autotools update
and fresh checkout works...

   
We should perhaps add this to our bug reporting comments: If you are 
seeing the bug in checkouts from svn, then you might want to try a fresh 
checkout.


Richard

Re: LyX/Mac Maintainer

[rgheck]

On 04/11/2010 10:30 PM, BH wrote:

Stephen Witt has been doing some great things for LyX/Mac. Given that
I have not had time or expertise to really advance LyX/Mac, and given
his abilities and enthusiasm, I have asked him if he would like to
take over as LyX/Mac maintainer. He has agreed.

For now, at least, the plan is for Stephen to take over the
LyX/Mac-2.0.0 release but leave at least the 1.6.6 release to me.
(We'll see what happens for 1.6.7.)

I've given Stephen the XCode source for LyX-installer.app. As I've
indicated before, I think we ought to do away with a separate
installer in favor of a script that can get run when LyX is launched.
But I'll leave the decision of what to do with it up to Stephen. (If
the installer persists, though, it should go into the svn repository.)

As I told Stephen, I'll still be around on the devel and users list,
still compiling recent trunk and branch, still pestering people to fix
Mac and other bugs, etc. And, of course, I'll still be using and
benefiting from LyX itself, without which I'd now find it very hard to
do any serious work.

So thanks, Stephen, for your good work so far and for the
contributions I'm sure you'll make in the future.

   
And thanks, Bennett, for your work as LyX/Mac maintainer. We'll thank 
you for the other stuff you mentioned later. ;-)


rh

Re: r34120 - lyx-devel/trunk/src

[rgheck]

On 04/12/2010 11:31 AM, Pavel Sanda wrote:

Vincent van Ravesteijn - TNW wrote:
   

-   : action_(LFUN_NOACTION), origin_(o), x_(0), y_(0),
+   : argument_(0), action_(LFUN_NOACTION), origin_(o), x_(0),
   

y_(0),
 
   

What's the rationale about initializing a docstring with 0 ? (Does it
even compile ?)
 

hrmpf, i only wanted to add something for the place of argument_. now this 
patch is buggy,
maybe even the next one i'm commiting right now... ;)
i want to have response from the reporter.

the whole thing is strange. since crash came from destructor and the only
thing really _changed_ in Richard's patch was the sequence of initialization -
my guess was it could be related because of missing argument.

   
I've tried restoring the initialization order. Otherwise, yes, it is 
VERY strange. Note that this comes from LyX.cpp:531:

lyx::dispatch(FuncRequest(LFUN_WINDOW_NEW, geometryArg));
So the constructor was actually this one:
FuncRequest::FuncRequest(FuncCode act, string const & arg, Origin o)
: argument_(from_utf8(arg)), action_(act), origin_(o), x_(0), 
y_(0),

  button_(mouse_button::none)
{}
which initializes argument_ just fine.

Apparently, you guess didn't help, so I've reverted it. Now he can just 
try the patch that changes back the initialization order. I've also 
suggested he try a fresh checkout.


rh

Re: r34120 - lyx-devel/trunk/src

[rgheck]

On 04/12/2010 02:25 PM, Pavel Sanda wrote:

Vincent van Ravesteijn - TNW wrote:
   

ehh, i thought from the one without argument, no?

FuncRequest? (this=0x8c0111c, act=lyx::LFUN_UNKNOWN_ACTION,
o=lyx::FuncRequest::INTERNAL) at FuncRequest?.cpp:39
   

Please read further:

#11 0x081a00c8 in static_initialization_and_destruction_0 ()
at FuncRequest?.cpp:28

This is your 0 initialization hack.
 

no that backtrace is from the tree, which doesn't contain 0 hack anymore.
anyway Richard hit the nail on the head in between - the problem was most
probably due to the linking with old object files after autotools update
and fresh checkout works...

   
We should perhaps add this to our bug reporting comments: If you are 
seeing the bug in checkouts from svn, then you might want to try a fresh 
checkout.


Richard

Re: r34107 - lyx-devel/trunk/src

[rgheck]

On 04/09/2010 07:55 PM, Enrico Forestieri wrote:

On Sat, Apr 10, 2010 at 01:10:55AM +0200, Vincent van Ravesteijn wrote:

   

Jean-Marc Lasgouttes schreef:
 

Le 9 avr. 10 à 21:03, rgh...@lyx.org a écrit :
   

Log:
Mark new files dirty. Otherwise, you can't save them, and maybe you want
to do that right away.
 

The rationale was that one should be ale to close the file
immediately without
a yes/no dialog, AFAIR. But I understand your concern too.

JMarc
   

I don't like this too.
 

Same here. You can always save them through File-SaveAs, and given that
File-Save behaves the same as File-SaveAs for new files...

   

OK. You win. ;-)

rh

Re: r34107 - lyx-devel/trunk/src

[rgheck]

On 04/09/2010 07:55 PM, Enrico Forestieri wrote:

On Sat, Apr 10, 2010 at 01:10:55AM +0200, Vincent van Ravesteijn wrote:

   

Jean-Marc Lasgouttes schreef:
 

Le 9 avr. 10 à 21:03, rgh...@lyx.org a écrit :
   

Log:
Mark new files dirty. Otherwise, you can't save them, and maybe you want
to do that right away.
 

The rationale was that one should be ale to close the file
immediately without
a yes/no dialog, AFAIR. But I understand your concern too.

JMarc
   

I don't like this too.
 

Same here. You can always save them through File->SaveAs, and given that
File->Save behaves the same as File->SaveAs for new files...

   

OK. You win. ;-)

rh