Re: r37353 - lyx-devel/trunk/lib/lyx2lyx

[Jean-Marc Lasgouttes]

Le vendredi 11 février 2011, Richard Heck rgh...@comcast.net a écrit :
 I would have taken a shot, but I'm not sure what we want to do. In 
 particular: Should PassThru layouts allow paragraph customization at all? It 
 seems kind of contrary to what they are. This would not prevent you from 
 centering stuff. Perhaps the module should have a custom centering inset.

My idéal is that everything that is 'outside' the insertion is allowed
(centering is in, but noindent is not). Or I could just skip the reset
for now.

I am not clear about what we really want to achieve, but alignment
should just work.

JMarc

Re: [patch] Re: Cjk Lyx 1.4

[Jürgen Spitzmüller]

Jürgen Spitzmüller wrote:
 We could also merge the uiflags into the flags, but I feel that the two
 should  be separated internally.

After thinking a bit more, I think it's OK to use flags_ for all. The patch is 
now really small. I'll commit the attached if I get no objections. 

Jürgen
Index: src/Format.h
===
--- src/Format.h	(Revision 37596)
+++ src/Format.h	(Arbeitskopie)
@@ -33,7 +33,9 @@
 		/// Some formats are both (e.g. pdf), they have this flag set.
 		document = 1,
 		/// Set if this format can contain vector graphics.
-		vector = 2
+		vector = 2,
+		/// This format should  appear in the File  Export menu
+		export_menu = 4
 	};
 	///
 	Format(std::string const  n, std::string const  e, std::string const  p,
@@ -76,6 +78,8 @@
 	bool vectorFormat() const { return flags_  vector; }
 	///
 	void setFlags(int v) { flags_ = v; }
+	///
+	bool inExportMenu() const { return flags_  export_menu; }
 private:
 	/// Internal name. Needs to be unique.
 	std::string name_;
Index: src/frontends/qt4/GuiPrefs.cpp
===
--- src/frontends/qt4/GuiPrefs.cpp	(Revision 37596)
+++ src/frontends/qt4/GuiPrefs.cpp	(Arbeitskopie)
@@ -1830,6 +1830,8 @@
 		this, SLOT(setFlags()));
 	connect(vectorCB, SIGNAL(clicked()),
 		this, SLOT(setFlags()));
+	connect(exportMenuCB, SIGNAL(clicked()),
+		this, SLOT(setFlags()));
 	connect(formatsCB-lineEdit(), SIGNAL(editingFinished()),
 		this, SLOT(updatePrettyname()));
 	connect(formatsCB-lineEdit(), SIGNAL(textEdited(QString)),
@@ -1927,6 +1929,8 @@
 		toqstr(l10n_shortcut(f.prettyname(), f.shortcut(;
 	documentCB-setChecked((f.documentFormat()));
 	vectorCB-setChecked((f.vectorFormat()));
+	exportMenuCB-setChecked((f.inExportMenu()));
+	exportMenuCB-setEnabled((f.documentFormat()));
 	updateViewers();
 	updateEditors();
 }
@@ -1939,7 +1943,10 @@
 		flags |= Format::document;
 	if (vectorCB-isChecked())
 		flags |= Format::vector;
+	if (exportMenuCB-isChecked())
+		flags |= Format::export_menu;
 	currentFormat().setFlags(flags);
+	exportMenuCB-setEnabled(documentCB-isChecked());
 	changed();
 }
 
Index: src/frontends/qt4/ui/PrefFileformatsUi.ui
===
--- src/frontends/qt4/ui/PrefFileformatsUi.ui	(Revision 37596)
+++ src/frontends/qt4/ui/PrefFileformatsUi.ui	(Arbeitskopie)
@@ -23,7 +23,7 @@
  /property
 /widget
/item
-   item row=0 column=1 colspan=2
+   item row=0 column=1
 widget class=QComboBox name=formatsCB
  property name=editable
   booltrue/bool
@@ -61,13 +61,23 @@
 /widget
/item
item row=2 column=1 colspan=2
+widget class=QCheckBox name=exportMenuCB
+ property name=toolTip
+  stringCheck this to show the current format in the File gt; Export menu/string
+ /property
+ property name=text
+  stringShoamp;w in export menu/string
+ /property
+/widget
+   /item
+   item row=3 column=1 colspan=2
 widget class=QCheckBox name=vectorCB
  property name=text
   stringVector amp;graphics format/string
  /property
 /widget
/item
-   item row=3 column=0
+   item row=4 column=0
 widget class=QLabel name=formatLA
  property name=text
   stringSamp;hort Name:/string
@@ -77,10 +87,10 @@
  /property
 /widget
/item
-   item row=3 column=1 colspan=2
+   item row=4 column=1 colspan=2
 widget class=QLineEdit name=formatED/
/item
-   item row=4 column=0
+   item row=5 column=0
 widget class=QLabel name=extensionLA
  property name=text
   stringEamp;xtension:/string
@@ -90,43 +100,43 @@
  /property
 /widget
/item
-   item row=4 column=1 colspan=2
+   item row=5 column=1 colspan=2
 widget class=QLineEdit name=extensionED/
/item
-   item row=5 column=0
-widget class=QLabel name=shortcutLA
+   item row=6 column=0
+widget class=QLabel name=editorLA
  property name=text
-  stringShortcamp;ut:/string
+  stringEdamp;itor:/string
  /property
  property name=buddy
-  cstringshortcutED/cstring
+  cstringeditorCO/cstring
  /property
 /widget
/item
-   item row=5 column=1 colspan=2
-widget class=QLineEdit name=shortcutED/
-   /item
-   item row=6 column=0
-widget class=QLabel name=editorLA
+   item row=7 column=0
+widget class=QLabel name=shortcutLA
  property name=text
-  stringEdamp;itor:/string
+  stringShortcamp;ut:/string
  /property
  property name=buddy
-  cstringeditorCO/cstring
+  cstringshortcutED/cstring
  /property
 /widget
/item
-   item row=6 column=1
+   item row=7 column=1 colspan=2
+widget class=QLineEdit name=shortcutED/
+   /item
+   item row=8 column=1
 widget class=QComboBox name=editorCO
  property name=sizeAdjustPolicy
   enumQComboBox::AdjustToContents/enum
  /property
 /widget
/item
-   item row=6 column=2 colspan=2
+   

More gcc 4.6 compile issues

[Orion Poplawski]

I've been working on getting lyx 2.0.0beta4 compiled for fedora rawhide with
gcc 4.6.  Latest compile failure that doesn't have an obvious (to me) proper
solution is:

insets/InsetCommandParams.cpp: In function 'const lyx::ParamInfo
lyx::findInfo(lyx::InsetCode, const string)':
insets/InsetCommandParams.cpp:87:25: error: uninitialized const 'pi' 
[-fpermissive]
insets/InsetCommandParams.h:32:7: note: 'const class lyx::ParamInfo' has no
user-provided default constructor
make[4]: *** [InsetCommandParams.o] Error 1

Jakub Jelinek's notes are:

uninitialized const
struct A { int a; A (); };
struct B : public A { };
const B b;

now gets an error:
error: uninitialized const ‘b’ [-fpermissive]
note: ‘const struct B’ has no user-provided default constructor

This is related to http://gcc.gnu.org/PR43890, B above doesn't
have a user provided default ctor, so either an initializer
needs to be provided, or the default ctor needs to be added.


Also, my additional gcc46 fixes to beta4 are:

--- lyx-2.0.0beta4/src/support/weighted_btree.h.gcc46   2010-03-10
23:50:42.0 -0700
+++ lyx-2.0.0beta4/src/support/weighted_btree.h 
@@ -29,6 +29,7 @@
 // *** Required Headers from the STL
 
 #include algorithm
+#include cstddef
 #include functional
 #include istream
 #include ostream
--- lyx-2.0.0beta4/src/mathed/MathData.hgcc46   2011-02-11 16:59:22.231577506
+++ lyx-2.0.0beta4/src/mathed/MathData.h2011-02-12 09:11:02.038643751
@@ -22,6 +22,7 @@
 
 #include support/strfwd.h
 
+#include cstddef
 #include vector
 
 

Re: Wiki Approve URL Password

[Pavel Sanda]

Kristle Chester wrote:
 Would someone please email me the wiki approve url password so I can
 approve the link for sffms lyx layouts on github? Thanks.

sent privately
p

Re: [patch] Controlling newlines on export

[Enrico Forestieri]

On Thu, Feb 10, 2011 at 10:02:18PM +0100, Pavel Sanda wrote:

 Enrico, could you have possibly look on bug #7186 when you are after
 forw/rev search now? thats much worse issue and i have really no time
 on it

Fixed at r37602.

-- 
Enrico

Re: r37602 - in lyx-devel/trunk/src: . frontends/qt4

[Pavel Sanda]

for...@lyx.org wrote:
 Author: forenr
 Date: Sat Feb 12 21:24:09 2011
 New Revision: 37602
 URL: http://www.lyx.org/trac/changeset/37602
 
 Log:
 Fix bug #7186 (Forward Search not working for Child Documents)

thanks for fixing it.

 // FIXME: There is a possibility of concurrent access to texrow
 // here from the main GUI thread that should be securized.
 d-cloned_buffer_-d-texrow = d-texrow;

can you be bit more verbose about the scenario?
you fear the situation when we copy the object and writing on it at the same 
time?
this shouldn't happen since GUI iirc only reads from this object and we write 
there
only when exporting to latex. we allow only 1 export thread, and since this 
copying
happen in the same thread we can't run write-read in parallel at this point.

but from this would follow that there is completely different problematic point
at latex export which was already there...

pavel

Re: r37602 - in lyx-devel/trunk/src: . frontends/qt4

[Enrico Forestieri]

On Sat, Feb 12, 2011 at 10:03:30PM +0100, Pavel Sanda wrote:

  // FIXME: There is a possibility of concurrent access to texrow
  // here from the main GUI thread that should be securized.
  d-cloned_buffer_-d-texrow = d-texrow;
 
 can you be bit more verbose about the scenario?
 you fear the situation when we copy the object and writing on it at
 the same time? this shouldn't happen since GUI iirc only reads from
 this object and we write there only when exporting to latex. we allow
 only 1 export thread, and since this copying happen in the same thread
 we can't run write-read in parallel at this point.

1. Preview pdf
2. File-export-DVI (at the same time)

What happens, then?

 but from this would follow that there is completely different
 problematic point at latex export which was already there...

What do you mean?

-- 
Enrico

Re: r37602 - in lyx-devel/trunk/src: . frontends/qt4

[Pavel Sanda]

Enrico Forestieri wrote:
 On Sat, Feb 12, 2011 at 10:03:30PM +0100, Pavel Sanda wrote:
 
   // FIXME: There is a possibility of concurrent access to texrow
   // here from the main GUI thread that should be securized.
   d-cloned_buffer_-d-texrow = d-texrow;
  
  can you be bit more verbose about the scenario?
  you fear the situation when we copy the object and writing on it at
  the same time? this shouldn't happen since GUI iirc only reads from
  this object and we write there only when exporting to latex. we allow
  only 1 export thread, and since this copying happen in the same thread
  we can't run write-read in parallel at this point.
 
 1. Preview pdf
 2. File-export-DVI (at the same time)
 
 What happens, then?

seeing view toolbar disabled while previewing i believed this is not possible,
but looking now it is...
i just get strange pdflatex error when trying your scenario...

  but from this would follow that there is completely different
  problematic point at latex export which was already there...
 
 What do you mean?

view-pdf
forward-search (at the same time)

pavel

Re: r37602 - in lyx-devel/trunk/src: . frontends/qt4

[Enrico Forestieri]

On Sat, Feb 12, 2011 at 09:24:10PM +0100, for...@lyx.org wrote:

 Author: forenr
 Date: Sat Feb 12 21:24:09 2011
 New Revision: 37602
 URL: http://www.lyx.org/trac/changeset/37602

 Log:
 Fix bug #7186 (Forward Search not working for Child Documents)
[...]
 - dviCB-addItem(xdvi -sourceposition $$n:$$t $$o);
 + dviCB-addItem(xdvi -sourceposition '$$n:\\ $$t' $$o);
   dviCB-addItem(yap -1 -s $$n$$t $$o);
   dviCB-addItem(okular --unique $$o#src:$$n$$t);
   dviCB-addItem(synctex view -i $$n:0:$$t -o $$o -x \evince -p 
 %{page+1} $$o\);

When initiating a forward search from a child document, the child file
name has to be passed as the $t parameter. As the child is copied to the
temp dir, it has a mangled name beginning with a number. So, there's an
ambiguity when using $$n$$t as done above ($n is the row number), which
I solved for xdvi. I cannot see how to solve this ambiguity for yap and
don't know how to do it for okular. This means that forward search still
does not work for child documents when using yap or okular, unless
someone using okular knows how to fix it (I fear there's no hope for yap).

--
Enrico

books on c++ to get started

[xuwang wangxu]

Hi,

I have looked here http://www.lyx.org/DeveloperResources

But I have questions specific to myself:

My only programming experience is with Perl (I know... strange one start
with). I would say that I am an intermediate programmer in Perl. I also have
a few years experience with R, and feel comfortable with it's OOP style. I
would like to start learning C++ and someday contribute to LyX. The books on
the developer resources seem too advanced for me. I do learn from books, so
although I would appreciate advice regarding online resources, I am
particularly interested in books. Price is not too much of a concern. I am
mainly interested in C++ programming on Linux, if that makes a difference.

The two beginning C++ books I'm considering getting are:
Accelerated C++: Practical Programming by Example
or
C++ Primer Plus (Prata)

And after that, I guess I should learn the STL? I would thus focus on
Generic Programming and the STL: Using and Extending the C++ Standard
Template Library
or
The C++ Standard Library: A Tutorial and Reference

Also, how important is it to get a book published in the last 10 years? Does
it matter that most of the STL books I see were published 10 years ago?
Thank you for any advice,

Xu Wang

Re: More gcc 4.6 compile issues

[Pavel Sanda]

Orion Poplawski wrote:
 I've been working on getting lyx 2.0.0beta4 compiled for fedora rawhide with
 gcc 4.6.  Latest compile failure that doesn't have an obvious (to me) proper
 solution is:
 
 insets/InsetCommandParams.cpp: In function 'const lyx::ParamInfo
 lyx::findInfo(lyx::InsetCode, const string)':
 insets/InsetCommandParams.cpp:87:25: error: uninitialized const 'pi' 
 [-fpermissive]
 insets/InsetCommandParams.h:32:7: note: 'const class lyx::ParamInfo' has no
 user-provided default constructor
 make[4]: *** [InsetCommandParams.o] Error 1

please try the current tree (or patch from 
http://www.lyx.org/trac/changeset/37603)

pavel

Re: r37604 - in lyx-devel/trunk/src: mathed support

[Pavel Sanda]

sa...@lyx.org wrote:
 Author: sanda
 Date: Sat Feb 12 23:10:56 2011
 New Revision: 37604
 URL: http://www.lyx.org/trac/changeset/37604
 
 Log:
 Rest of gcc 4.6 issues from Orion Poplawski.

this and previous should go to branch as well
pavel

Re: r37602 - in lyx-devel/trunk/src: . frontends/qt4

[Enrico Forestieri]

On Sat, Feb 12, 2011 at 11:34:21PM +0100, Enrico Forestieri wrote:

 On Sat, Feb 12, 2011 at 09:24:10PM +0100, for...@lyx.org wrote:
 
  Author: forenr
  Date: Sat Feb 12 21:24:09 2011
  New Revision: 37602
  URL: http://www.lyx.org/trac/changeset/37602
 
  Log:
  Fix bug #7186 (Forward Search not working for Child Documents)
 [...]
  - dviCB-addItem(xdvi -sourceposition $$n:$$t $$o);
  + dviCB-addItem(xdvi -sourceposition '$$n:\\ $$t' $$o);
dviCB-addItem(yap -1 -s $$n$$t $$o);
dviCB-addItem(okular --unique $$o#src:$$n$$t);
dviCB-addItem(synctex view -i $$n:0:$$t -o $$o -x \evince -p 
  %{page+1} $$o\);
 
 When initiating a forward search from a child document, the child file
 name has to be passed as the $t parameter. As the child is copied to the
 temp dir, it has a mangled name beginning with a number. So, there's an
 ambiguity when using $$n$$t as done above ($n is the row number), which
 I solved for xdvi. I cannot see how to solve this ambiguity for yap and
 don't know how to do it for okular. This means that forward search still
 does not work for child documents when using yap or okular, unless
 someone using okular knows how to fix it (I fear there's no hope for yap).

I fixed the issue for yap (despite its poor documentation), so only the
command for okular needs to be revised.

-- 
Enrico

Re: hebrew support in lyx 2.0?

[Pavel Sanda]

Richman Reuven wrote:
 hi, i can't seem to find any info on possible changes of hebrew support
 in the new version (2.0), was there something supposed to happen? (i'd
 gladly test it if i knew what to look for)

by the way, the hebrew translation of user interface is going to be killed for 
2.0
if nobody sends updated .po files. consider to help with keeping it up-to-date
if you have some spare time.

http://www.lyx.org/I18n-trunk
http://www.lyx.org/trac/browser/lyx-devel/trunk/README.localization

pavel

Re: [patch] Re: Cjk Lyx 1.4

[Richard Heck]

On 02/12/2011 07:06 AM, Jürgen Spitzmüller wrote:

Jürgen Spitzmüller wrote:

We could also merge the uiflags into the flags, but I feel that the two
should  be separated internally.

After thinking a bit more, I think it's OK to use flags_ for all. The patch is
now really small. I'll commit the attached if I get no objections.

So, one last question, which arose as I was thinking what should be done 
here for prefs2prefs. I take it that the default, at present, is for 
things NOT to appear in the export menu, and that only if we have 
menu=export will it. I do not understand what we're trying to accomplish 
quite well enough to know what the right choice is here. But whichever 
one it is, the question remains: What if anything needs to be done in 
prefs2prefs, so that (e.g.) customized formats appear in the right 
place? Or can we even tell?


Richard

Re: r37353 - lyx-devel/trunk/lib/lyx2lyx

[Jean-Marc Lasgouttes]

Le vendredi 11 février 2011, Richard Heck  a écrit :
> I would have taken a shot, but I'm not sure what we want to do. In 
> particular: Should PassThru layouts allow paragraph customization at all? It 
> seems kind of contrary to what they are. This would not prevent you from 
> centering stuff. Perhaps the module should have a custom "centering" inset.

My idéal is that everything that is 'outside' the insertion is allowed
(centering is in, but noindent is not). Or I could just skip the reset
for now.

I am not clear about what we really want to achieve, but alignment
should just work.

JMarc

Re: [patch] Re: Cjk Lyx 1.4

[Jürgen Spitzmüller]

Jürgen Spitzmüller wrote:
> We could also merge the uiflags into the flags, but I feel that the two
> should  be separated internally.

After thinking a bit more, I think it's OK to use flags_ for all. The patch is 
now really small. I'll commit the attached if I get no objections. 

Jürgen
Index: src/Format.h
===
--- src/Format.h	(Revision 37596)
+++ src/Format.h	(Arbeitskopie)
@@ -33,7 +33,9 @@
 		/// Some formats are both (e.g. pdf), they have this flag set.
 		document = 1,
 		/// Set if this format can contain vector graphics.
-		vector = 2
+		vector = 2,
+		/// This format should  appear in the File > Export menu
+		export_menu = 4
 	};
 	///
 	Format(std::string const & n, std::string const & e, std::string const & p,
@@ -76,6 +78,8 @@
 	bool vectorFormat() const { return flags_ & vector; }
 	///
 	void setFlags(int v) { flags_ = v; }
+	///
+	bool inExportMenu() const { return flags_ & export_menu; }
 private:
 	/// Internal name. Needs to be unique.
 	std::string name_;
Index: src/frontends/qt4/GuiPrefs.cpp
===
--- src/frontends/qt4/GuiPrefs.cpp	(Revision 37596)
+++ src/frontends/qt4/GuiPrefs.cpp	(Arbeitskopie)
@@ -1830,6 +1830,8 @@
 		this, SLOT(setFlags()));
 	connect(vectorCB, SIGNAL(clicked()),
 		this, SLOT(setFlags()));
+	connect(exportMenuCB, SIGNAL(clicked()),
+		this, SLOT(setFlags()));
 	connect(formatsCB->lineEdit(), SIGNAL(editingFinished()),
 		this, SLOT(updatePrettyname()));
 	connect(formatsCB->lineEdit(), SIGNAL(textEdited(QString)),
@@ -1927,6 +1929,8 @@
 		toqstr(l10n_shortcut(f.prettyname(), f.shortcut(;
 	documentCB->setChecked((f.documentFormat()));
 	vectorCB->setChecked((f.vectorFormat()));
+	exportMenuCB->setChecked((f.inExportMenu()));
+	exportMenuCB->setEnabled((f.documentFormat()));
 	updateViewers();
 	updateEditors();
 }
@@ -1939,7 +1943,10 @@
 		flags |= Format::document;
 	if (vectorCB->isChecked())
 		flags |= Format::vector;
+	if (exportMenuCB->isChecked())
+		flags |= Format::export_menu;
 	currentFormat().setFlags(flags);
+	exportMenuCB->setEnabled(documentCB->isChecked());
 	changed();
 }
 
Index: src/frontends/qt4/ui/PrefFileformatsUi.ui
===
--- src/frontends/qt4/ui/PrefFileformatsUi.ui	(Revision 37596)
+++ src/frontends/qt4/ui/PrefFileformatsUi.ui	(Arbeitskopie)
@@ -23,7 +23,7 @@
  
 

-   
+   
 
  
   true
@@ -61,13 +61,23 @@
 


+
+ 
+  Check this to show the current format in the File  Export menu
+ 
+ 
+  Show in export menu
+ 
+
+   
+   
 
  
   Vector graphics format
  
 

-   
+   
 
  
   Short Name:
@@ -77,10 +87,10 @@
  
 

-   
+   
 

-   
+   
 
  
   Extension:
@@ -90,43 +100,43 @@
  
 

-   
+   
 

-   
-
+   
+
  
-  Shortcut:
+  Editor:
  
  
-  shortcutED
+  editorCO
  
 

-   
-
-   
-   
-
+   
+
  
-  Editor:
+  Shortcut:
  
  
-  editorCO
+  shortcutED
  
 

-   
+   
+
+   
+   
 
  
   QComboBox::AdjustToContents
  
 

-   
+   
 

-   
+   
 
  
   Viewer:
@@ -136,17 +146,17 @@
  
 

-   
+   
 
  
   QComboBox::AdjustToContents
  
 

-   
+   
 

-   
+   
 
  
   Copier:
@@ -156,10 +166,10 @@
  
 

-   
+   
 

-   
+   
 
  
   Specify the default output format when using (PDF)LaTeX
@@ -200,7 +210,7 @@
  
 

-   
+   
 
  
   Qt::Vertical
Index: src/frontends/qt4/Menus.cpp
===
--- src/frontends/qt4/Menus.cpp	(Revision 37596)
+++ src/frontends/qt4/Menus.cpp	(Arbeitskopie)
@@ -1055,7 +1055,7 @@
 continue;
 			}
 		case MenuItem::ExportFormats:
-			if (!(*fit)->documentFormat())
+			if (!(*fit)->inExportMenu())
 continue;
 			break;
 		default:
Index: src/LyXRC.cpp
===
--- src/LyXRC.cpp	(Revision 37596)
+++ src/LyXRC.cpp	(Arbeitskopie)
@@ -1090,6 +1090,8 @@
 	flgs |= Format::document;
 else if (flag == "vector")
 	flgs |= Format::vector;
+else if (flag == "menu=export")
+	flgs |= Format::export_menu;
 else
 	LYXERR0("Ignoring unknown flag `"
 	   << flag << "' for format `"
Index: lib/configure.py
===
--- lib/configure.py	(Revision 37596)
+++ lib/configure.py	(Arbeitskopie)
@@ -498,19 +498,19 @@
 \Format asciiimage asc"Plain text (image)" "" ""	"%%"	""
 \Format asciixfig  asc"Plain text (Xfig output)"   "" ""	"%%"	""
 \Format dateouttmp"date (output)" "" ""	"%%"	""

More gcc 4.6 compile issues

[Orion Poplawski]

I've been working on getting lyx 2.0.0beta4 compiled for fedora rawhide with
gcc 4.6.  Latest compile failure that doesn't have an obvious (to me) proper
solution is:

insets/InsetCommandParams.cpp: In function 'const lyx::ParamInfo&
lyx::findInfo(lyx::InsetCode, const string&)':
insets/InsetCommandParams.cpp:87:25: error: uninitialized const 'pi' 
[-fpermissive]
insets/InsetCommandParams.h:32:7: note: 'const class lyx::ParamInfo' has no
user-provided default constructor
make[4]: *** [InsetCommandParams.o] Error 1

Jakub Jelinek's notes are:

uninitialized const
struct A { int a; A (); };
struct B : public A { };
const B b;

now gets an error:
error: uninitialized const ‘b’ [-fpermissive]
note: ‘const struct B’ has no user-provided default constructor

This is related to http://gcc.gnu.org/PR43890, B above doesn't
have a user provided default ctor, so either an initializer
needs to be provided, or the default ctor needs to be added.


Also, my additional gcc46 fixes to beta4 are:

--- lyx-2.0.0beta4/src/support/weighted_btree.h.gcc46   2010-03-10
23:50:42.0 -0700
+++ lyx-2.0.0beta4/src/support/weighted_btree.h 
@@ -29,6 +29,7 @@
 // *** Required Headers from the STL
 
 #include 
+#include 
 #include 
 #include 
 #include 
--- lyx-2.0.0beta4/src/mathed/MathData.hgcc46   2011-02-11 16:59:22.231577506
+++ lyx-2.0.0beta4/src/mathed/MathData.h2011-02-12 09:11:02.038643751
@@ -22,6 +22,7 @@
 
 #include "support/strfwd.h"
 
+#include 
 #include 
 
 

Re: Wiki Approve URL Password

[Pavel Sanda]

Kristle Chester wrote:
> Would someone please email me the wiki approve url password so I can
> approve the link for sffms lyx layouts on github? Thanks.

sent privately
p

Re: [patch] Controlling newlines on export

[Enrico Forestieri]

On Thu, Feb 10, 2011 at 10:02:18PM +0100, Pavel Sanda wrote:

> Enrico, could you have possibly look on bug #7186 when you are after
> forw/rev search now? thats much worse issue and i have really no time
> on it

Fixed at r37602.

-- 
Enrico

Re: r37602 - in lyx-devel/trunk/src: . frontends/qt4

[Pavel Sanda]

for...@lyx.org wrote:
> Author: forenr
> Date: Sat Feb 12 21:24:09 2011
> New Revision: 37602
> URL: http://www.lyx.org/trac/changeset/37602
> 
> Log:
> Fix bug #7186 (Forward Search not working for Child Documents)

thanks for fixing it.

> // FIXME: There is a possibility of concurrent access to texrow
> // here from the main GUI thread that should be securized.
> d->cloned_buffer_->d->texrow = d->texrow;

can you be bit more verbose about the scenario?
you fear the situation when we copy the object and writing on it at the same 
time?
this shouldn't happen since GUI iirc only reads from this object and we write 
there
only when exporting to latex. we allow only 1 export thread, and since this 
copying
happen in the same thread we can't run write-read in parallel at this point.

but from this would follow that there is completely different problematic point
at latex export which was already there...

pavel

Re: r37602 - in lyx-devel/trunk/src: . frontends/qt4

[Enrico Forestieri]

On Sat, Feb 12, 2011 at 10:03:30PM +0100, Pavel Sanda wrote:

> > // FIXME: There is a possibility of concurrent access to texrow
> > // here from the main GUI thread that should be securized.
> > d->cloned_buffer_->d->texrow = d->texrow;
> 
> can you be bit more verbose about the scenario?
> you fear the situation when we copy the object and writing on it at
> the same time? this shouldn't happen since GUI iirc only reads from
> this object and we write there only when exporting to latex. we allow
> only 1 export thread, and since this copying happen in the same thread
> we can't run write-read in parallel at this point.

1. Preview pdf
2. File->export->DVI (at the same time)

What happens, then?

> but from this would follow that there is completely different
> problematic point at latex export which was already there...

What do you mean?

-- 
Enrico

Re: r37602 - in lyx-devel/trunk/src: . frontends/qt4

[Pavel Sanda]

Enrico Forestieri wrote:
> On Sat, Feb 12, 2011 at 10:03:30PM +0100, Pavel Sanda wrote:
> 
> > > // FIXME: There is a possibility of concurrent access to texrow
> > > // here from the main GUI thread that should be securized.
> > > d->cloned_buffer_->d->texrow = d->texrow;
> > 
> > can you be bit more verbose about the scenario?
> > you fear the situation when we copy the object and writing on it at
> > the same time? this shouldn't happen since GUI iirc only reads from
> > this object and we write there only when exporting to latex. we allow
> > only 1 export thread, and since this copying happen in the same thread
> > we can't run write-read in parallel at this point.
> 
> 1. Preview pdf
> 2. File->export->DVI (at the same time)
> 
> What happens, then?

seeing view toolbar disabled while previewing i believed this is not possible,
but looking now it is...
i just get strange pdflatex error when trying your scenario...

> > but from this would follow that there is completely different
> > problematic point at latex export which was already there...
> 
> What do you mean?

view->pdf
forward-search (at the same time)

pavel

Re: r37602 - in lyx-devel/trunk/src: . frontends/qt4

[Enrico Forestieri]

On Sat, Feb 12, 2011 at 09:24:10PM +0100, for...@lyx.org wrote:

> Author: forenr
> Date: Sat Feb 12 21:24:09 2011
> New Revision: 37602
> URL: http://www.lyx.org/trac/changeset/37602
>
> Log:
> Fix bug #7186 (Forward Search not working for Child Documents)
[...]
> - dviCB->addItem("xdvi -sourceposition $$n:$$t $$o");
> + dviCB->addItem("xdvi -sourceposition '$$n:\\ $$t' $$o");
>   dviCB->addItem("yap -1 -s $$n$$t $$o");
>   dviCB->addItem("okular --unique $$o#src:$$n$$t");
>   dviCB->addItem("synctex view -i $$n:0:$$t -o $$o -x \"evince -p 
> %{page+1} $$o\"");

When initiating a forward search from a child document, the child file
name has to be passed as the $t parameter. As the child is copied to the
temp dir, it has a mangled name beginning with a number. So, there's an
ambiguity when using $$n$$t as done above ($n is the row number), which
I solved for xdvi. I cannot see how to solve this ambiguity for yap and
don't know how to do it for okular. This means that forward search still
does not work for child documents when using yap or okular, unless
someone using okular knows how to fix it (I fear there's no hope for yap).

--
Enrico

books on c++ to get started

[xuwang wangxu]

Hi,

I have looked here http://www.lyx.org/DeveloperResources

But I have questions specific to myself:

My only programming experience is with Perl (I know... strange one start
with). I would say that I am an intermediate programmer in Perl. I also have
a few years experience with R, and feel comfortable with it's OOP style. I
would like to start learning C++ and someday contribute to LyX. The books on
the developer resources seem too advanced for me. I do learn from books, so
although I would appreciate advice regarding online resources, I am
particularly interested in books. Price is not too much of a concern. I am
mainly interested in C++ programming on Linux, if that makes a difference.

The two beginning C++ books I'm considering getting are:
Accelerated C++: Practical Programming by Example
or
C++ Primer Plus (Prata)

And after that, I guess I should learn the STL? I would thus focus on
Generic Programming and the STL: Using and Extending the C++ Standard
Template Library
or
The C++ Standard Library: A Tutorial and Reference

Also, how important is it to get a book published in the last 10 years? Does
it matter that most of the STL books I see were published 10 years ago?
Thank you for any advice,

Xu Wang

Re: More gcc 4.6 compile issues

[Pavel Sanda]

Orion Poplawski wrote:
> I've been working on getting lyx 2.0.0beta4 compiled for fedora rawhide with
> gcc 4.6.  Latest compile failure that doesn't have an obvious (to me) proper
> solution is:
> 
> insets/InsetCommandParams.cpp: In function 'const lyx::ParamInfo&
> lyx::findInfo(lyx::InsetCode, const string&)':
> insets/InsetCommandParams.cpp:87:25: error: uninitialized const 'pi' 
> [-fpermissive]
> insets/InsetCommandParams.h:32:7: note: 'const class lyx::ParamInfo' has no
> user-provided default constructor
> make[4]: *** [InsetCommandParams.o] Error 1

please try the current tree (or patch from 
http://www.lyx.org/trac/changeset/37603)

pavel

Re: r37604 - in lyx-devel/trunk/src: mathed support

[Pavel Sanda]

sa...@lyx.org wrote:
> Author: sanda
> Date: Sat Feb 12 23:10:56 2011
> New Revision: 37604
> URL: http://www.lyx.org/trac/changeset/37604
> 
> Log:
> Rest of gcc 4.6 issues from Orion Poplawski.

this and previous should go to branch as well
pavel

Re: r37602 - in lyx-devel/trunk/src: . frontends/qt4

[Enrico Forestieri]

On Sat, Feb 12, 2011 at 11:34:21PM +0100, Enrico Forestieri wrote:

> On Sat, Feb 12, 2011 at 09:24:10PM +0100, for...@lyx.org wrote:
> 
> > Author: forenr
> > Date: Sat Feb 12 21:24:09 2011
> > New Revision: 37602
> > URL: http://www.lyx.org/trac/changeset/37602
> >
> > Log:
> > Fix bug #7186 (Forward Search not working for Child Documents)
> [...]
> > - dviCB->addItem("xdvi -sourceposition $$n:$$t $$o");
> > + dviCB->addItem("xdvi -sourceposition '$$n:\\ $$t' $$o");
> >   dviCB->addItem("yap -1 -s $$n$$t $$o");
> >   dviCB->addItem("okular --unique $$o#src:$$n$$t");
> >   dviCB->addItem("synctex view -i $$n:0:$$t -o $$o -x \"evince -p 
> > %{page+1} $$o\"");
> 
> When initiating a forward search from a child document, the child file
> name has to be passed as the $t parameter. As the child is copied to the
> temp dir, it has a mangled name beginning with a number. So, there's an
> ambiguity when using $$n$$t as done above ($n is the row number), which
> I solved for xdvi. I cannot see how to solve this ambiguity for yap and
> don't know how to do it for okular. This means that forward search still
> does not work for child documents when using yap or okular, unless
> someone using okular knows how to fix it (I fear there's no hope for yap).

I fixed the issue for yap (despite its poor documentation), so only the
command for okular needs to be revised.

-- 
Enrico

Re: hebrew support in lyx 2.0?

[Pavel Sanda]

Richman Reuven wrote:
> hi, i can't seem to find any info on possible changes of hebrew support
> in the new version (2.0), was there something supposed to happen? (i'd
> gladly test it if i knew what to look for)

by the way, the hebrew translation of user interface is going to be killed for 
2.0
if nobody sends updated .po files. consider to help with keeping it up-to-date
if you have some spare time.

http://www.lyx.org/I18n-trunk
http://www.lyx.org/trac/browser/lyx-devel/trunk/README.localization

pavel

Re: [patch] Re: Cjk Lyx 1.4

[Richard Heck]

On 02/12/2011 07:06 AM, Jürgen Spitzmüller wrote:

Jürgen Spitzmüller wrote:

We could also merge the uiflags into the flags, but I feel that the two
should  be separated internally.

After thinking a bit more, I think it's OK to use flags_ for all. The patch is
now really small. I'll commit the attached if I get no objections.

So, one last question, which arose as I was thinking what should be done 
here for prefs2prefs. I take it that the default, at present, is for 
things NOT to appear in the export menu, and that only if we have 
menu=export will it. I do not understand what we're trying to accomplish 
quite well enough to know what the right choice is here. But whichever 
one it is, the question remains: What if anything needs to be done in 
prefs2prefs, so that (e.g.) customized formats appear in the right 
place? Or can we even tell?


Richard