Re: r33318 - lyx-devel/trunk/src

[Jean-Marc Lasgouttes]

Tommaso Cucinotta tommaso.cucino...@sssup.it writes:
 However, I have to go through all the code, especially with
 ignore-format off, because I noticed some misbehaviour (probably some
 white-spaces more/less in the textual exports of insets -- w.r.t. a
 few months ago).

You mean that your code is sensitive to every change we make to latex
export? Yikes!

JMarc

Re: XML?

[Guenter Milde]

On 2010-02-03, Pavel Sanda wrote:
 Guenter Milde wrote:
 This is why I would greatly welcome improved support for external
 editing of the lyx source:

 * open file of current buffer in a configurable application,
   reload buffer once this application is closed.

 i feel this is task for only very advanced users and we shouldn't
 promote editing lyx file directly in our gui.
 as for your usecase, try: vc_command DR my-editor $$p/$$i

Thanks for this tip. 

However, trying this in the minibuffer of my LyX 1.6.5, with a lyx file
from my home dir, I did get no reaction from LyX (except mirroring the
command in the status bar) and the line 

 Das Verzeichnis ist nicht lesbar.
 
(The directory cannot be read.) in the .xsession-errors file

 * open a lyx file in LyX and jump to a specified place/line, so that I
   can easily go to `grep` results or the place I have been editing in
   my valued text editor.

 not easy to do as discussed in bugzilla.

I know, but still desirable.

Günter

Re: [patch] bug 6503: Including self as child document crashes branch

[Jean-Marc Lasgouttes]

Jürgen Spitzmüller sp...@lyx.org writes:

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

 This crash is caused by an infinite loop in Encodings::initMath, which 
 recursively calls itself if a document includes itself (we already issue a 
 warning about that, but in the given case, LyX crashes before the warning 
 can be issued).

 The fix is obviously to test whether child and parent are identical. I see 
 two ways of doing this: either directly in the function (patch a) or 
 upstream in Buffer::isChildren (patch b).

I have difficulties to understand the implications of the second patch.
OTOH I always prefer this kind of solution that patching at the place
where the crash occurs.

JMarc

Re: XML?

[Guenter Milde]

On 2010-02-02, Tommaso Cucinotta wrote:
 Guenter Milde wrote:

 However, grep for a phrase in a set of lyx documents
 (all papers of the last 3 years, say) is still a valid case.

 sure, that's something at which grep is surely unbeatable and faster.

Now combine this with locate to search the whole system:

  grep my-pattern `locate *path-pattern*lyx`

...

 Anyway, I think an XML file-format would almost certainly preserve the
 grep ability, and within certain boundaries I guess also a
 regex-based replace.

I even think a properly written XML can be easier to parse/grep, e.g.
by inlining inline tags like::


  Some 
  \begin_inset ERT
  status open
  
  \begin_layout Plain Layout
  
  {
  \end_layout
  
  \end_inset
  
  silly
  \begin_inset ERT
  status open
  
  \begin_layout Plain Layout
  
  }
  \end_layout
  
  \end_inset
  
   text.
  \end_layout

with::

  Some ERT status='open'{/ERTsillyERT status='open'{/ERT text.

Günter

Re: [patch] bug 6503: Including self as child document crashes branch

[Jürgen Spitzmüller]

Jean-Marc Lasgouttes wrote:

 I have difficulties to understand the implications of the second patch.

the function buffer::isChild(buf) checks if buf is a child of the current 
buffer by reading the children_position cache. However, in weird situations 
such as the bug's scenario, it can happen that the buffer itself is 
registered as its child (see the weird scenario the bug report uses to 
achieve this; I don't see how this can be completely avoided).

So, since a buffer cannot be its own child really, the second patch always 
returns false for isChildren if buf and the buffer are identical, 
notwithstanding if buf is registered as a child or not.

 OTOH I always prefer this kind of solution that patching at the place
 where the crash occurs.

I tend towards this as well. I just think there might be other scenarios 
which could be avoided by a more general approach.

Jürgen

line breaks in variable width table columns

[Guenter Milde]

This came up in the users list, but boils down to a feature request:

  It would be nice if LyX could interpret a Ctrl-Enter in a variable-width
  table cell as insert the content in a \shortstack with a line-break at
  this place.

On 2010-01-28, Guenter Milde wrote:
 On 2010-01-27, Uwe Stöhr wrote:
 Vincent schrieb:

I have to set the table column widths [...], and then, possibly,
Ctrl+Enter will make the new line anyway.

 Yes, you have to set a column width :). Don't ask me why.

 This is LaTeX. There is no other way because otherwise the width cannot 
 be calculated at which the line break should occur.

 But this is a technical restriction. A fixed witdth is required for
 automatic line wrapping. With manual line-breaks the column width can be
 calculated from the maximal line length.

 However, LaTeX does not allow manual line-breaks in a table cell.

 A workaround is to use the \shortstack macro (currently as ERT).
 This would lead to e.g. the following LaTeX source:

   \begin{tabular}{|c|p{3cm}|}
   \hline 
   \shortstack{not so\\short\\stack}  fixed\\
   width\tabularnewline
   \hline
   \end{tabular}

 The vertical alignment needs some improvement, but generally this works.

Günter

Re: [patch] bug 6503: Including self as child document crashes branch

[Jean-Marc Lasgouttes]

Jürgen Spitzmüller sp...@lyx.org writes:
 the function buffer::isChild(buf) checks if buf is a child of the current 
 buffer by reading the children_position cache. However, in weird situations 
 such as the bug's scenario, it can happen that the buffer itself is 
 registered as its child (see the weird scenario the bug report uses to 
 achieve this; I don't see how this can be completely avoided).

My problem is to know what happens when this bad child is here without
being here. I would prefer a mechanism to have the isnet inhibit itself
in such case (like the BROKEN references or branches), but I understand
it may be much work for an obscure problem.

JMarc

Re: [patch] bug 6503: Including self as child document crashes branch

[Jürgen Spitzmüller]

Jean-Marc Lasgouttes wrote:

 My problem is to know what happens when this bad child is here without
 being here. I would prefer a mechanism to have the isnet inhibit itself
 in such case (like the BROKEN references or branches), but I understand
 it may be much work for an obscure problem.

I'm not sure if I understand your concern, but if you have a recursive 
include, you get this warning of view/export:

Attempted to include file crash.lyx in itself! Ignoring inclusion.

Jürgen

Re: [patch] bug 6503: Including self as child document crashes branch

[John McCabe-Dansted]

On 2/3/10, Jürgen Spitzmüller sp...@lyx.org wrote:
 I tend towards this as well. I just think there might be other scenarios
 which could be avoided by a more general approach.

A more general approach may also fix other bugs resulting from loops such as:
  #6505: A is parent document of B is parent of A ... Crash!

-- 
John C. McCabe-Dansted

Re: [patch] bug 6503: Including self as child document crashes branch

[Jean-Marc Lasgouttes]

Jürgen Spitzmüller sp...@lyx.org writes:
 I'm not sure if I understand your concern, but if you have a recursive 
 include, you get this warning of view/export:

 Attempted to include file crash.lyx in itself! Ignoring inclusion.

But then there is this bug too:
http://www.lyx.org/trac/ticket/6505

Every include inset could assess by itself whether it is correct (by
checking the chain of its ascendants) and act as a dummy inset if
something is wrong.

JMarc

Re: [patch] bug 6503: Including self as child document crashes branch

[Jürgen Spitzmüller]

John McCabe-Dansted wrote:

 A more general approach may also fix other bugs resulting from loops such
 as: #6505: A is parent document of B is parent of A ... Crash!

Could you test that?

Jürgen

Re: [patch] bug 6503: Including self as child document crashes branch

[Jürgen Spitzmüller]

Jean-Marc Lasgouttes wrote:

 Every include inset could assess by itself whether it is correct (by
 checking the chain of its ascendants) and act as a dummy inset if
 something is wrong.

patches are welcome.

Jürgen

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

[Abdelrazak Younes]

On 02/02/2010 07:57 PM, Peter Kümmel wrote:

Andre Poenitz wrote:
   

On Tue, Feb 02, 2010 at 02:53:58PM +0100, Peter Kümmel wrote:
 

Am Sonntag, den 31.01.2010, 14:29 +0100 schrieb Andre Poenitz:
   

How do we proceed now ?
   

I think it's time to use signal/slots, this time in the right direction.
The buffer emits a message, possibly with an indication that it is
temporarily and the view (or the server...) connects to it.

Andre'
 

Does this also mean currently we have no clear Model/View design?
   

Sort of.

Right now the Gui is basically signaling the Core to change and the
Core pushes changes to the Gui. Which is pretty wrong.
 

You mean the core knows the gui and calls gui-only functions to
update the view? This would be indeed wrong.

Where there attempts to fix this design? Or was the design OK
in good old times and then somehow became wrong? Haven't Abdel
tried to cleanup this?
   


Yes, but it's not finished yet because we had fondamental disagreement 
on that issue, with JMarc mainly :-P basically this is about the 
dispatch machinery. Buffer and BufferView are already mostly fine here 
as they are using pseudo signal (see GuiDelegate and WorkAreaManager); 
it would be easy to switch to real Qt signal here. We also need to make 
those Alert calls real signals intead this mix up we have now.


As far as dispatch is concerned, my goal was to make GuiApp::dispatch() 
the first entry in the dispatch machinery instead of LyXFunc::dispatch() 
which should basically disappear... At the end, all the virtual 
interface in src/frontend/ should disappear too.




Shouldn't we do a cleanup/redesign at such places?
   


We should yes.

Abdel.

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

[Jean-Marc Lasgouttes]

Abdelrazak Younes you...@lyx.org writes:
 As far as dispatch is concerned, my goal was to make
 GuiApp::dispatch() the first entry in the dispatch machinery instead
 of LyXFunc::dispatch() which should basically disappear... At the end,
 all the virtual interface in src/frontend/ should disappear too.

I could not care less about where is the main entry point as long as
there is a main entry point and everybody is not directly invoking
individual dispatch function.

About putting it in GuiApp, why not, although most of the code there is
non-gui code. What could/should probably move is the default: case of
the big switch. 

Note that, with my latest changes, LyXFunc only has two member variables
left (those for saving cursor x/y). I would propose to move these
variables into Cursor (savedX, savedY). Would somebody object to that?

Then there would not be a LyXFunc object anymore, but functions (or
static members).

JMarc

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

[Peter Kümmel]

Jean-Marc Lasgouttes wrote:
 Abdelrazak Younes you...@lyx.org writes:
 As far as dispatch is concerned, my goal was to make
 GuiApp::dispatch() the first entry in the dispatch machinery instead
 of LyXFunc::dispatch() which should basically disappear... At the end,
 all the virtual interface in src/frontend/ should disappear too.
 
 I could not care less about where is the main entry point as long as
 there is a main entry point and everybody is not directly invoking
 individual dispatch function.
 
 About putting it in GuiApp, why not, although most of the code there is
 non-gui code. What could/should probably move is the default: case of
 the big switch. 

Originally it was the Model-View-Controller pattern, so isn't a
controller the perfect candidate for the cental dispatcher?

 
 Note that, with my latest changes, LyXFunc only has two member variables
 left (those for saving cursor x/y). I would propose to move these
 variables into Cursor (savedX, savedY). Would somebody object to that?
 
 Then there would not be a LyXFunc object anymore, but functions (or
 static members).
 
 JMarc
 

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

[Peter Kümmel]

Peter Kümmel wrote:
 
 Originally it was the Model-View-Controller pattern, so isn't a
 controller the perfect candidate for the central dispatcher?
 

Wouldn't it be best to completely unlink the model and view like in
attached image, found as figue 4-6 in
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/CocoaDesignPatterns.html

Peter
inline: cocoa_mvc.png

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

[Abdelrazak Younes]

On 02/03/2010 12:17 PM, Peter Kümmel wrote:

Peter Kümmel wrote:
   

Originally it was the Model-View-Controller pattern, so isn't a
controller the perfect candidate for the central dispatcher?

 


If we proceed as I suggested then that would be the result indeed:

model: everything in src/, src/inset/ and src/math/

view: all the different dialogs, including GuiView

controller: GuiApp mainly, but also GuiView::dispatch(), as well Dialog, 
GuiDialog and DialogView classes.



Wouldn't it be best to completely unlink the model and view like in
attached image, found as figue 4-6 in
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/CocoaDesignPatterns.html
   


At this point, this is becoming academic. What is especially important 
is that the model is free of any GUI code. Then we can always cleanup 
progressively the source code to have clearer separation between the 
views and the controllers, but that is of lesser importance.


Abdel

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

[Abdelrazak Younes]

On 02/03/2010 11:50 AM, Jean-Marc Lasgouttes wrote:

Abdelrazak Younesyou...@lyx.org  writes:
   

As far as dispatch is concerned, my goal was to make
GuiApp::dispatch() the first entry in the dispatch machinery instead
of LyXFunc::dispatch() which should basically disappear... At the end,
all the virtual interface in src/frontend/ should disappear too.
 

I could not care less about where is the main entry point as long as
there is a main entry point and everybody is not directly invoking
individual dispatch function.
   


Good we agree on that point at least.


About putting it in GuiApp, why not, although most of the code there is
non-gui code.


Some of this code will probably integrate back the non-gui code in forms 
of helper functions or methods. This is similar to what we did when I 
created GuiView::dispatch(), I move out a lot of code there and then a 
lot of code did return back to src/.




  What could/should probably move is the default: case of
the big switch.
   


Yes.


Note that, with my latest changes, LyXFunc only has two member variables
left (those for saving cursor x/y). I would propose to move these
variables into Cursor (savedX, savedY). Would somebody object to that?
   


Not from me. But I think there is already something similar in Cursor 
(Cursor saves its pre and post dispatch() state IIRC).



Then there would not be a LyXFunc object anymore, but functions (or
static members).
   


Yes.

Abdel.

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

[Jean-Marc Lasgouttes]

Abdelrazak Younes you...@lyx.org writes:

 Note that, with my latest changes, LyXFunc only has two member variables
 left (those for saving cursor x/y). I would propose to move these
 variables into Cursor (savedX, savedY). Would somebody object to that?


 Not from me. But I think there is already something similar in Cursor
 (Cursor saves its pre and post dispatch() state IIRC).

Yes, but it saves it in the LyXFunc object.

JMarc

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

[Jean-Marc Lasgouttes]

Abdelrazak Younes you...@lyx.org writes:
 If we proceed as I suggested then that would be the result indeed:

 model: everything in src/, src/inset/ and src/math/

 view: all the different dialogs, including GuiView

 controller: GuiApp mainly, but also GuiView::dispatch(), as well
 Dialog, GuiDialog and DialogView classes.

The controller could live in the frontends/ directory, and the view in
frontends/qt4 :)

JMarc

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

[Peter Kümmel]

Abdelrazak Younes wrote:
 On 02/03/2010 12:17 PM, Peter Kümmel wrote:
 Peter Kümmel wrote:

 Originally it was the Model-View-Controller pattern, so isn't a
 controller the perfect candidate for the central dispatcher?

  
 
 If we proceed as I suggested then that would be the result indeed:
 
 model: everything in src/, src/inset/ and src/math/

Here I would move model relevant code from src to src/model,
then the binary would become a smaller project which onlx
links to the essential parts.

I would also introduce shared libraries which help to avoild
circular dependencies between the libraries, especially when building
Dlls on Windows, but maybe there is also a GCC flag to forbid such
dependencies .

 
 view: all the different dialogs, including GuiView
 
 controller: GuiApp mainly, but also GuiView::dispatch(), as well Dialog, 
 GuiDialog and DialogView classes.

I would not distribute the controller functionality to several classes.

 
 Wouldn't it be best to completely unlink the model and view like in
 attached image, found as figue 4-6 in
 http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/CocoaDesignPatterns.html

 
 At this point, this is becoming academic. What is especially important 
 is that the model is free of any GUI code. Then we can always cleanup 
 progressively the source code to have clearer separation between the 
 views and the controllers, but that is of lesser importance.

Having several views (GUI/non-GUI) it is better to also send model's
notifications through the controller.

 
 Abdel
 

Re: r33302 - lyx-devel/trunk/src

[Jean-Marc Lasgouttes]

Vincent van Ravesteijn - TNW v.f.vanraveste...@tudelft.nl writes:
 I wouldn't handle LFUN_REGEXP_MODE twice in one function. That's prone
 to cause confusion later (I don't really understand the others that are
 handled twice).

Would the attached patch make sense to both of you?

 More important, I'm still not sure why we forbid the REGEXP_MODE in
 ERTs. Why does LyX crash ? 

I propose that we leave this (insets in pass_thru environments) for
later.

Note that more improvements are needed to handle both pass_thru layouts
and isPassThru insets (which are not the same thing).

JMarc

Re: r33302 - lyx-devel/trunk/src

[Jean-Marc Lasgouttes]

Jean-Marc Lasgouttes lasgout...@lyx.org writes:

 Vincent van Ravesteijn - TNW v.f.vanraveste...@tudelft.nl writes:
 I wouldn't handle LFUN_REGEXP_MODE twice in one function. That's prone
 to cause confusion later (I don't really understand the others that are
 handled twice).

 Would the attached patch make sense to both of you?

 More important, I'm still not sure why we forbid the REGEXP_MODE in
 ERTs. Why does LyX crash ? 

 I propose that we leave this (insets in pass_thru environments) for
 later.

 Note that more improvements are needed to handle both pass_thru layouts
 and isPassThru insets (which are not the same thing).

 JMarc

As usual.

svndiff

Index: src/insets/InsetText.cpp
===
--- src/insets/InsetText.cpp	(révision 33318)
+++ src/insets/InsetText.cpp	(copie de travail)
@@ -298,17 +298,6 @@ bool InsetText::getStatus(Cursor  cur, 
 	FuncStatus  status) const
 {
 	switch (cmd.action) {
-	case LFUN_LAYOUT:
-		status.setEnabled(!forcePlainLayout());
-		return true;
-
-	case LFUN_LAYOUT_PARAGRAPH:
-	case LFUN_PARAGRAPH_PARAMS:
-	case LFUN_PARAGRAPH_PARAMS_APPLY:
-	case LFUN_PARAGRAPH_UPDATE:
-		status.setEnabled(allowParagraphCustomization());
-		return true;
-
 	case LFUN_INSET_DISSOLVE: {
 		bool const main_inset = buffer().inset() == this;
 		bool const target_inset = cmd.argument().empty() 
Index: src/BufferView.cpp
===
--- src/BufferView.cpp	(révision 33318)
+++ src/BufferView.cpp	(copie de travail)
@@ -1024,11 +1024,6 @@ bool BufferView::getStatus(FuncRequest c
 		flag.setEnabled(true);
 		break;
 
-	case LFUN_REGEXP_MODE:
-		flag.setEnabled(buffer().isInternal()  !cur.inRegexped()
- cur.inset().lyxCode() != ERT_CODE);
-		break;
-
 	case LFUN_LABEL_COPY_AS_REF: {
 		// if there is an inset at cursor, see whether it
 		// handles the lfun
Index: src/Text3.cpp
===
--- src/Text3.cpp	(révision 33318)
+++ src/Text3.cpp	(copie de travail)
@@ -2393,6 +2393,11 @@ bool Text::getStatus(Cursor  cur, FuncR
 		code = MATH_HULL_CODE;
 		break;
 
+	case LFUN_REGEXP_MODE:
+		code = MATH_HULL_CODE;
+		enable = cur.buffer()-isInternal()  !cur.inRegexped();
+		break;
+
 	case LFUN_INSET_MODIFY:
 		// We need to disable this, because we may get called for a
 		// tabular cell via
@@ -2403,31 +2408,38 @@ bool Text::getStatus(Cursor  cur, FuncR
 
 	case LFUN_FONT_EMPH:
 		flag.setOnOff(fontinfo.emph() == FONT_ON);
+		enable = !cur.inset().getLayout().isPassThru();
 		break;
 
 	case LFUN_FONT_ITAL:
 		flag.setOnOff(fontinfo.shape() == ITALIC_SHAPE);
+		enable = !cur.inset().getLayout().isPassThru();
 		break;
 
 	case LFUN_FONT_NOUN:
 		flag.setOnOff(fontinfo.noun() == FONT_ON);
+		enable = !cur.inset().getLayout().isPassThru();
 		break;
 
 	case LFUN_FONT_BOLD:
 	case LFUN_FONT_BOLDSYMBOL:
 		flag.setOnOff(fontinfo.series() == BOLD_SERIES);
+		enable = !cur.inset().getLayout().isPassThru();
 		break;
 
 	case LFUN_FONT_SANS:
 		flag.setOnOff(fontinfo.family() == SANS_FAMILY);
+		enable = !cur.inset().getLayout().isPassThru();
 		break;
 
 	case LFUN_FONT_ROMAN:
 		flag.setOnOff(fontinfo.family() == ROMAN_FAMILY);
+		enable = !cur.inset().getLayout().isPassThru();
 		break;
 
 	case LFUN_FONT_TYPEWRITER:
 		flag.setOnOff(fontinfo.family() == TYPEWRITER_FAMILY);
+		enable = !cur.inset().getLayout().isPassThru();
 		break;
 
 	case LFUN_CUT:
@@ -2559,6 +2571,47 @@ bool Text::getStatus(Cursor  cur, FuncR
 		enable = theSpellChecker();
 		break;
 
+	case LFUN_LAYOUT:
+		enable = !cur.inset().forcePlainLayout();
+		break;
+		
+	case LFUN_LAYOUT_PARAGRAPH:
+	case LFUN_PARAGRAPH_PARAMS:
+	case LFUN_PARAGRAPH_PARAMS_APPLY:
+	case LFUN_PARAGRAPH_UPDATE:
+		enable = cur.inset().allowParagraphCustomization();
+		break;
+
+	// FIXME: why are accent lfuns forbidden with pass_thru layouts?
+	case LFUN_ACCENT_ACUTE:
+	case LFUN_ACCENT_BREVE:
+	case LFUN_ACCENT_CARON:
+	case LFUN_ACCENT_CEDILLA:
+	case LFUN_ACCENT_CIRCLE:
+	case LFUN_ACCENT_CIRCUMFLEX:
+	case LFUN_ACCENT_DOT:
+	case LFUN_ACCENT_GRAVE:
+	case LFUN_ACCENT_HUNGARIAN_UMLAUT:
+	case LFUN_ACCENT_MACRON:
+	case LFUN_ACCENT_OGONEK:
+	case LFUN_ACCENT_TIE:
+	case LFUN_ACCENT_TILDE:
+	case LFUN_ACCENT_UMLAUT:
+	case LFUN_ACCENT_UNDERBAR:
+	case LFUN_ACCENT_UNDERDOT:
+	case LFUN_FONT_DEFAULT:
+	case LFUN_FONT_FRAK:
+	case LFUN_FONT_SIZE:
+	case LFUN_FONT_STATE:
+	case LFUN_FONT_UNDERLINE:
+	case LFUN_FONT_STRIKEOUT:
+	case LFUN_FONT_UULINE:
+	case LFUN_FONT_UWAVE:
+	case LFUN_TEXTSTYLE_APPLY:
+	case LFUN_TEXTSTYLE_UPDATE:
+		enable = !cur.inset().getLayout().isPassThru();
+		break;
+
 	case LFUN_WORD_DELETE_FORWARD:
 	case LFUN_WORD_DELETE_BACKWARD:
 	case LFUN_LINE_DELETE:
@@ -2588,6 +2641,15 @@ bool Text::getStatus(Cursor  cur, FuncR
 	case LFUN_WORD_LEFT_SELECT:
 	case LFUN_WORD_SELECT:
 	case LFUN_SECTION_SELECT:
+	case LFUN_BUFFER_BEGIN:
+	case LFUN_BUFFER_END:
+	case 

RE: [patch] bug 6503: Including self as child document crashes branch

[Vincent van Ravesteijn - TNW]

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

This crash is caused by an infinite loop in Encodings::initMath,
which recursively calls itself if a document includes itself
(we already issue a warning about that, but in the given case,
LyX crashes before the warning can be issued).


First, Encodings::initMath should get the children like this. Please, use 
buffer-getChildren() for that. 

Now, we can avoid that getChildren() returns a list including itself.

Vincent

RE: [patch] bug 6503: Including self as child document crashes branch

[Jürgen Spitzmüller]

Vincent van Ravesteijn - TNW wrote:

 First, Encodings::initMath should get the children like this. Please, use
 buffer-getChildren() for that.
 
 Now, we can avoid that getChildren() returns a list including itself.

In other words, patch b?

Jürgen

RE: [patch] bug 6503: Including self as child document crashes branch

[Vincent van Ravesteijn - TNW]

 
 First, Encodings::initMath should get the children like this. Please, 
 use
 buffer-getChildren() for that.
 
 Now, we can avoid that getChildren() returns a list including itself.

In other words, patch b?


No, I refrain from words that other people might understand.

I mean you shouldn't use the isChild function from Encoding::initMath. 

To fix the bugs, we should check for recursive includes when the InsetInclude 
changes (that's now done for document including itself; this should thus be 
checked for all relatives (bug 6305)), _and_ when the filename of the buffer 
changes (bug 6303).

Just like Jmarc I don't like the ad-hoc approach of patch a, but neither the 
ad-hoc approach of patch b :).. Checking only for the simple recursive case in 
the isChild function, because some function somewhere uses a homegrown method 
to get all children does not pass my ad-hoc-test.

First the isChild function shouldn't be used, second I don't expect this 
behaviour of the isChild function. If A includes A, I expect A-isChild(A) to 
return true. As stated above, instead we should avoid having a situation that A 
includes A.

Vincent

RE: [patch] bug 6503: Including self as child document crashes branch

[Jürgen Spitzmüller]

Vincent van Ravesteijn - TNW wrote:

 I mean you shouldn't use the isChild function from Encoding::initMath.

To clarify: this is not my code. Anyway, you mean this?

Index: src/Encoding.cpp 
   
=== 
   
--- src/Encoding.cpp(Revision 33282)
+++ src/Encoding.cpp(Arbeitskopie)
@@ -554,11 +554,10 @@
it-initUnicodeMath();

// Check children
-   BufferList::iterator bit = theBufferList().begin();
-   BufferList::iterator const bend = theBufferList().end();
-   for (; bit != bend; ++bit)
-   if (buffer.isChild(*bit))
-   initUnicodeMath(**bit, false);
+   std::vectorBuffer * clist = buffer.getChildren();
+   for (vectorBuffer *::const_iterator cit = clist.begin();
+cit != clist.end(); ++cit)
+   initUnicodeMath(**cit, false);
 #endif
 }


 To fix the bugs, we should check for recursive includes when the
 InsetInclude changes (that's now done for document including itself; this
 should thus be checked for all relatives (bug 6305)), and when the
 filename of the buffer changes (bug 6303).

I see. I don't have time to do that, though.

Jürgen

RE: [patch] bug 6503: Including self as child document crashes branch

[Vincent van Ravesteijn - TNW]

 
 I mean you shouldn't use the isChild function from
 Encoding::initMath.

 To clarify: this is not my code. Anyway, you mean this?

Yes, of course I know it's not your code. And yes, this is what I mean. 

 To fix the bugs, we should check for recursive includes when the 
 InsetInclude changes (that's now done for document including itself; 
 this should thus be checked for all relatives (bug 6305)), and when 
 the filename of the buffer changes (bug 6303).

I see. I don't have time to do that, though.

If you now put in the constraint that Buffer::getChildren cannot return the 
buffer itself as one of its children, then you fixed the problem you were 
trying to fix. If that's what you was planning to do.

Vincent

RE: [patch] bug 6503: Including self as child document crashes branch

[Vincent van Ravesteijn - TNW]

 
But then there is this bug too:
http://www.lyx.org/trac/ticket/6505


That's already known for a long time, but in the past we decided it was not 
worth fixing it. See bug #1474.

Vincent

RE: OpenDocument export [was Re: too long]

[Rob Oakes]

Hi Ethan,

The DocBook import/export actually seems to work pretty well.  It is, 
unfortunately, a subset of the full docbook spec, however.  I haven't hit the 
technical limitations, but I've seen a number of complaints on behalf of others.

For the open source writing book I am writing, I've been trying to find a 
robust way of exchanging documents and collecting edits from non-LaTeX/LyX 
users.  The OpenOffice DocBook support appears to be the best option for simple 
text based documents.  Apparently, everything goes to hell once Mathematics and 
images get added.  I haven't done much first hand-experimentation, however.

I eventually gave up trying to round trip documents to Microsoft Word.  Getting 
LyX output into a format that can be read by Word is only half the battle.  
Trying to incorporate changes made by others is an even bigger struggle and it 
just isn't worth it. 

Cheers,

Rob

-Original Message-
From: Ethan Metsger [mailto:emets...@obj-sys.com] 
Sent: Wednesday, February 03, 2010 8:45 AM
To: Lyx Users
Subject: OpenDocument export [was Re: too long]

On Tue, 02 Feb 2010 20:19:54 -0500, Waluyo Adi Siswanto was.u...@gmail.com 
wrote:

 I am using Ubuntu(Ubuntu 8.10 and LyX 1.6.5) and I can export to 
 OpenDocument easily  (from FileExportOpenDocument) and it creates 
 *,odt. When I open this file using OpenOffice and if I double click 
 the equations created by LyX it will be in OpenOffice equation, all 
 equations can be edited and continued in OpenOffice without any 
 problems.

I can confirm this works out of the box on Ubuntu Karmic.  Whether it works on 
more complicated documents, I don't know.  I also note that OO.org has a LaTeX 
exporter, but regretfully cannot import LaTeX.  It's supposed to support 
DocBook imports, but I haven't tried it.

Best,

Ethan
(emets...@obj-sys.com)

RE: [patch] bug 6503: Including self as child document crashes branch

[Jürgen Spitzmüller]

Vincent van Ravesteijn - TNW wrote:

 If you now put in the constraint that Buffer::getChildren cannot return
 the buffer itself as one of its children, then you fixed the problem you
 were trying to fix. If that's what you was planning to do.

Yes, this would be the attached (which even fixes, AFAICS, the problem with 
A includes B includes C includes A).

But I understood that you (and JMarc) were rather proposing something more 
smart.

JürgenIndex: src/Encoding.cpp
===
--- src/Encoding.cpp	(Revision 33282)
+++ src/Encoding.cpp	(Arbeitskopie)
@@ -554,11 +554,10 @@
 		it-initUnicodeMath();
 
 	// Check children
-	BufferList::iterator bit = theBufferList().begin();
-	BufferList::iterator const bend = theBufferList().end();
-	for (; bit != bend; ++bit)
-		if (buffer.isChild(*bit))
-			initUnicodeMath(**bit, false);
+	std::vectorBuffer * clist = buffer.getChildren();
+	for (vectorBuffer *::const_iterator cit = clist.begin();
+	 cit != clist.end(); ++cit) 
+		initUnicodeMath(**cit, false);
 #endif
 }
 
Index: src/Buffer.cpp
===
--- src/Buffer.cpp	(Revision 33282)
+++ src/Buffer.cpp	(Arbeitskopie)
@@ -1816,12 +1816,17 @@
 	Impl::BufferPositionMap::iterator end = d-children_positions.end();
 	for (; it != end; ++it) {
 		Buffer * child = const_castBuffer *(it-first);
-		clist.push_back(child);
+		// ignore recursive includes
+		if (child != this)
+			clist.push_back(child);
 		// there might be grandchildren
 		std::vectorBuffer * glist = child-getChildren();
 		for (vectorBuffer *::const_iterator git = glist.begin();
-		 git != glist.end(); ++git)
-			clist.push_back(*git);
+		 git != glist.end(); ++git) {
+			// ignore recursive includes
+			if (*git != this)
+clist.push_back(*git);
+		}
 	}
 	return clist;
 }

RE: #6507: Underscores lead to corrupted label names in display-mode text box

[Matthew]

Any idea when this might be fixed?  The comments in #2872 imply that the cause 
and fix are both known.

Thanks!



-Original Message-
From: LyX Ticket Tracker [mailto:t...@lyx.org] 
Sent: Wednesday, February 03, 2010 12:07 AM
To: pruchek+...@gmail.com; lasgout...@lyx.org
Subject: Re: #6507: Underscores lead to corrupted label names in display-mode 
text box

#6507: Underscores lead to corrupted label names in display-mode text box
-+--
 Reporter:  pruchek  |Owner:  lasgouttes
 Type:  defect   |   Status:  closed
 Priority:  normal   |Milestone:
Component:  general  |  Version:  1.6.5 
 Severity:  normal   |   Resolution:  duplicate 
 Keywords:   |  
-+--
Changes (by spitz):

  * status:  new = closed
  * resolution:  = duplicate


Comment:

 this is #2872.

-- 
Ticket URL: http://www.lyx.org/trac/ticket/6507#comment:1
The LyX Project http://www.lyx.org/
LyX -- The Document Processor

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

[Peter Kümmel]

Peter Kümmel wrote:
 Peter Kümmel wrote:
 Originally it was the Model-View-Controller pattern, so isn't a
 controller the perfect candidate for the central dispatcher?

 
 Wouldn't it be best to completely unlink the model and view like in
 attached image, found as figue 4-6 in
 http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/CocoaDesignPatterns.html

Diving a little bit deeper into the Apple's docs I must admit:
Documentation at it's best!
Such docu I miss for Qt, most there is a extended doxygen API
description only, no big-picture is given any where.

By the way, being again off-topic-on-the wrong-list:
Are there plans to create a Qt Interface Builder
which exports .qib files?

Peter

Re: How I can add a new button to the tool bar?

[Uwe Stöhr]

durocortorum73-gm...@yahoo.fr schrieb:


I attach to this mail the current Tango-ified LyX icons. They are probably not 
interesting on Windows platform as Tango is mostly a linux thing.


I don't think that the OS matters here. The most important thing is that 
you know what the button stands for.



As I said, at present, my main issue for distribution is the mixing of several licenses. I do not know under 
which license the whole may be distributed. I have done a significant work (in terms of hours) to shrink 22 and 
24 pixels icons to fit in 20, while preserving the aspect, and sometimes I did some pixel work (pdf, 
ps, dvi words, outline icons, footnote  margin note icons). I have no issue in 
putting my contribution under any license that would be compatible with the original ones.


LyX in general only accepts the GPL version 2 or later (and Creative 
commons (needs to be discussed first on the lyx-devel list)).



A little text file explains the history of most icons. I tried to use Tango 
icons mainly, they are public domain. The part I took from gimp can be easily 
redone (and will be for consistency I think). I also provide some xcf files for 
icons that have common parts.


Your work is impressive but perhaps too much. The current LyX icons are 
known by the users and thus shouldn't be changed if possible.
I see the problem you mentioned that icons with 24x24 pixels look 
blurred and I think we should only fix these icons and make them 20x20 
icons.


Your icons are nevertheless very nice and we should have a discussion 
about them. I therefore propose to upload them to our Wiki:

http://wiki.lyx.org/LyX/Icons

I'm forwarding this to the lyx-devel list.

regards Uwe

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

[Andre Poenitz]

On Wed, Feb 03, 2010 at 06:27:06PM +0100, Peter Kümmel wrote:
 Peter Kümmel wrote:
  Peter Kümmel wrote:
  Originally it was the Model-View-Controller pattern, so isn't a
  controller the perfect candidate for the central dispatcher?
 
  
  Wouldn't it be best to completely unlink the model and view like in
  attached image, found as figue 4-6 in
  http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/CocoaDesignPatterns.html
 
 Diving a little bit deeper into the Apple's docs I must admit:
 Documentation at it's best!
 Such docu I miss for Qt, most there is a extended doxygen API
 description only, no big-picture is given any where.
 
 By the way, being again off-topic-on-the wrong-list:
 Are there plans to create a Qt Interface Builder
 which exports .qib files?

What's a .qib file?  I only find http://filext.com/file-extension/QIP
which seems unrelated.

Andre'

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

[Andre Poenitz]

On Wed, Feb 03, 2010 at 12:40:04PM +0100, Peter Kümmel wrote:
 I would also introduce shared libraries which help to avoild
 circular dependencies between the libraries, especially when building
 Dlls on Windows, but maybe there is also a GCC flag to forbid such
 dependencies .

Linking with --no-undefined --allow-shlib-undefined might do the trick.

Andre'

Re: How I can add a new button to the tool bar?

[Edwin Leuven]

Uwe Stöhr wrote:

The current LyX icons are known by the users and thus shouldn't be
changed if possible.


the  current icons are also known by the users to be butt-ugly and give 
a very amateurish first impression (so i've been told)


personally i'd change them in an instant for something consistent and 
better looking.



Your icons are nevertheless very nice and we should have a discussion
 about them. I therefore propose to upload them to our Wiki: 
http://wiki.lyx.org/LyX/Icons


please do

Re: How I can add a new button to the tool bar?

[Edwin Leuven]

ps. and what would be a better occasion to change the icons than a 2.0 
release?!

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

[Peter Kümmel]

Andre Poenitz wrote:
 On Wed, Feb 03, 2010 at 06:27:06PM +0100, Peter Kümmel wrote:
 Peter Kümmel wrote:
 Peter Kümmel wrote:
 Originally it was the Model-View-Controller pattern, so isn't a
 controller the perfect candidate for the central dispatcher?

 Wouldn't it be best to completely unlink the model and view like in
 attached image, found as figue 4-6 in
 http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/CocoaDesignPatterns.html
 Diving a little bit deeper into the Apple's docs I must admit:
 Documentation at it's best!
 Such docu I miss for Qt, most there is a extended doxygen API
 description only, no big-picture is given any where.

 By the way, being again off-topic-on-the wrong-list:
 Are there plans to create a Qt Interface Builder
 which exports .qib files?
 
 What's a .qib file?  I only find http://filext.com/file-extension/QIP
 which seems unrelated.
 
 Andre'
 

.qib is analog to .nib NeXT Interface Builder.
The Interface Builder of the Mac still uses the .nib extension;
they still follow their NS ideology: NSObject, NSString, ...

Peter

Re: How I can add a new button to the tool bar?

[Joost Verburg]

On 2/3/2010 1:32 PM, Edwin Leuven wrote:

the current icons are also known by the users to be butt-ugly and give a
very amateurish first impression (so i've been told)

personally i'd change them in an instant for something consistent and
better looking.


+1

The current icons look old and are somewhat confusing. Having modern and 
consistent icons would be a great thing!


Joost

Re: [patch] bug 6503: Including self as child document crashes branch

[Vincent van Ravesteijn]

Jürgen Spitzmüller schreef:

Vincent van Ravesteijn - TNW wrote:

  

If you now put in the constraint that Buffer::getChildren cannot return
the buffer itself as one of its children, then you fixed the problem you
were trying to fix. If that's what you was planning to do.



Yes, this would be the attached (which even fixes, AFAICS, the problem with 
A includes B includes C includes A).
  


No I don't think that will fixed. If A would collect all grandchildren 
in one vector without duplication and executes the function for them, 
then it's not a problem, but now A.do() calls B.do() which gets all 
children of B and calls C.do() which calls A.do() again.
But I understood that you (and JMarc) were rather proposing something more 
smart.
  


The smart is to check for this before starting a master-child relation.

Vincent

about the libintl version in the LyX windows installer

[Uwe Stöhr]

Hello Joost,

good to see that you are still active with LyX.
As you might know, the Windows version of LyX suffers from of a buggy version of libintl (intl.dll). 
This is the reason why you for example cannot switch the menu language from within LyX. JMarc once 
identified the bug as bug in the libintl version we are using for LyX on Windows and you tried to 
compile a more recent version of libintl for Windows but failed.


I now made a new attempt to overcome this problem. I found an up to date windows version of gettext 
including libintl:

http://www.gtk.org/download-windows.html

I also found other Windows sources of gettext 0.17 for Windows and could compile the intl.dll from 
the sources. The problem is that my compiled intl.dll won't link with your LyX Windows package and 
all my attempts to change the source code to make it link failed. Can you therefore please have a 
look if you are able to use gettext 0.17 for you LyX Windows bundle?


I can also send you a zip-file containing the libintl sources and an MSVC 
project file if you like.

many thanks in advance and regards
Uwe

Re: XML?

[Pavel Sanda]

Guenter Milde wrote:
 Thanks for this tip. 
 
 However, trying this in the minibuffer of my LyX 1.6.5, with a lyx file
 from my home dir, I did get no reaction from LyX (except mirroring the
 command in the status bar) and the line 
 
  Das Verzeichnis ist nicht lesbar.
  
 (The directory cannot be read.) in the .xsession-errors file

rtfm ;) i wrote it from my cache only.
vc_command DR $$p my-editor $$i

pavel

Re: r33318 - lyx-devel/trunk/src

[Jean-Marc Lasgouttes]

Tommaso Cucinotta  writes:
> However, I have to go through all the code, especially with
> ignore-format off, because I noticed some misbehaviour (probably some
> white-spaces more/less in the textual exports of insets -- w.r.t. a
> few months ago).

You mean that your code is sensitive to every change we make to latex
export? Yikes!

JMarc

Re: XML?

[Guenter Milde]

On 2010-02-03, Pavel Sanda wrote:
> Guenter Milde wrote:
>> This is why I would greatly welcome improved support for external
>> editing of the lyx source:

>> * open file of current buffer in a configurable application,
>>   reload buffer once this application is closed.

> i feel this is task for only very advanced users and we shouldn't
> promote editing lyx file directly in our gui.
> as for your usecase, try: vc_command DR "my-editor $$p/$$i"

Thanks for this tip. 

However, trying this in the minibuffer of my LyX 1.6.5, with a lyx file
from my home dir, I did get no reaction from LyX (except mirroring the
command in the status bar) and the line 

 Das Verzeichnis ist nicht lesbar.
 
(The directory cannot be read.) in the .xsession-errors file

>> * open a lyx file in LyX and jump to a specified place/line, so that I
>>   can easily go to `grep` results or the place I have been editing in
>>   my valued text editor.

> not easy to do as discussed in bugzilla.

I know, but still desirable.

Günter

Re: [patch] bug 6503: Including self as child document crashes branch

[Jean-Marc Lasgouttes]

Jürgen Spitzmüller  writes:

> http://www.lyx.org/trac/ticket/6503
>
> This crash is caused by an infinite loop in Encodings::initMath, which 
> recursively calls itself if a document includes itself (we already issue a 
> warning about that, but in the given case, LyX crashes before the warning 
> can be issued).
>
> The fix is obviously to test whether child and parent are identical. I see 
> two ways of doing this: either directly in the function (patch a) or 
> upstream in Buffer::isChildren (patch b).

I have difficulties to understand the implications of the second patch.
OTOH I always prefer this kind of solution that patching at the place
where the crash occurs.

JMarc

Re: XML?

[Guenter Milde]

On 2010-02-02, Tommaso Cucinotta wrote:
> Guenter Milde wrote:

>> However, grep for a phrase in a set of lyx documents
>> (all papers of the last 3 years, say) is still a valid case.

> sure, that's something at which grep is surely unbeatable and faster.

Now combine this with locate to search the whole system:

  grep my-pattern `locate *path-pattern*lyx`

...

> Anyway, I think an XML file-format would almost certainly preserve the
> "grep" ability, and within certain boundaries I guess also a
> regex-based replace.

I even think a properly written XML can be easier to parse/grep, e.g.
by inlining inline tags like::


  Some 
  \begin_inset ERT
  status open
  
  \begin_layout Plain Layout
  
  {
  \end_layout
  
  \end_inset
  
  silly
  \begin_inset ERT
  status open
  
  \begin_layout Plain Layout
  
  }
  \end_layout
  
  \end_inset
  
   text.
  \end_layout

with::

  Some {silly{ text.

Günter

Re: [patch] bug 6503: Including self as child document crashes branch

[Jürgen Spitzmüller]

Jean-Marc Lasgouttes wrote:

> I have difficulties to understand the implications of the second patch.

the function buffer::isChild(buf) checks if buf is a child of the current 
buffer by reading the children_position cache. However, in weird situations 
such as the bug's scenario, it can happen that the buffer itself is 
registered as its child (see the weird scenario the bug report uses to 
achieve this; I don't see how this can be completely avoided).

So, since a buffer cannot be its own child really, the second patch always 
returns false for isChildren if buf and the buffer are identical, 
notwithstanding if buf is registered as a child or not.

> OTOH I always prefer this kind of solution that patching at the place
> where the crash occurs.

I tend towards this as well. I just think there might be other scenarios 
which could be avoided by a more general approach.

Jürgen

line breaks in variable width table columns

[Guenter Milde]

This came up in the users list, but boils down to a feature request:

  It would be nice if LyX could interpret a Ctrl-Enter in a variable-width
  table cell as "insert the content in a \shortstack with a line-break at
  this place".

On 2010-01-28, Guenter Milde wrote:
> On 2010-01-27, Uwe Stöhr wrote:
>> Vincent schrieb:

I have to "set" the table column widths [...], and then, possibly,
Ctrl+Enter will make the new line anyway.

>>> Yes, you have to set a column width :). Don't ask me why.

>> This is LaTeX. There is no other way because otherwise the width cannot 
>> be calculated at which the line break should occur.

> But this is a technical restriction. A fixed witdth is required for
> automatic line wrapping. With manual line-breaks the column width can be
> calculated from the maximal line length.

> However, LaTeX does not allow manual line-breaks in a table cell.

> A workaround is to use the \shortstack macro (currently as ERT).
> This would lead to e.g. the following LaTeX source:

>   \begin{tabular}{|c|p{3cm}|}
>   \hline 
>   \shortstack{not so\\short\\stack} & fixed\\
>   width\tabularnewline
>   \hline
>   \end{tabular}

> The vertical alignment needs some improvement, but generally this works.

Günter

Re: [patch] bug 6503: Including self as child document crashes branch

[Jean-Marc Lasgouttes]

Jürgen Spitzmüller  writes:
> the function buffer::isChild(buf) checks if buf is a child of the current 
> buffer by reading the children_position cache. However, in weird situations 
> such as the bug's scenario, it can happen that the buffer itself is 
> registered as its child (see the weird scenario the bug report uses to 
> achieve this; I don't see how this can be completely avoided).

My problem is to know what happens when this bad child is here without
being here. I would prefer a mechanism to have the isnet inhibit itself
in such case (like the BROKEN references or branches), but I understand
it may be much work for an obscure problem.

JMarc

Re: [patch] bug 6503: Including self as child document crashes branch

[Jürgen Spitzmüller]

Jean-Marc Lasgouttes wrote:

> My problem is to know what happens when this bad child is here without
> being here. I would prefer a mechanism to have the isnet inhibit itself
> in such case (like the BROKEN references or branches), but I understand
> it may be much work for an obscure problem.

I'm not sure if I understand your concern, but if you have a recursive 
include, you get this warning of view/export:

"Attempted to include file crash.lyx in itself! Ignoring inclusion."

Jürgen

Re: [patch] bug 6503: Including self as child document crashes branch

[John McCabe-Dansted]

On 2/3/10, Jürgen Spitzmüller  wrote:
> I tend towards this as well. I just think there might be other scenarios
> which could be avoided by a more general approach.

A more general approach may also fix other bugs resulting from loops such as:
  #6505: A is parent document of B is parent of A ... Crash!

-- 
John C. McCabe-Dansted

Re: [patch] bug 6503: Including self as child document crashes branch

[Jean-Marc Lasgouttes]

Jürgen Spitzmüller  writes:
> I'm not sure if I understand your concern, but if you have a recursive 
> include, you get this warning of view/export:
>
> "Attempted to include file crash.lyx in itself! Ignoring inclusion."

But then there is this bug too:
http://www.lyx.org/trac/ticket/6505

Every include inset could assess by itself whether it is correct (by
checking the chain of its ascendants) and act as a dummy inset if
something is wrong.

JMarc

Re: [patch] bug 6503: Including self as child document crashes branch

[Jürgen Spitzmüller]

John McCabe-Dansted wrote:

> A more general approach may also fix other bugs resulting from loops such
> as: #6505: A is parent document of B is parent of A ... Crash!

Could you test that?

Jürgen

Re: [patch] bug 6503: Including self as child document crashes branch

[Jürgen Spitzmüller]

Jean-Marc Lasgouttes wrote:

> Every include inset could assess by itself whether it is correct (by
> checking the chain of its ascendants) and act as a dummy inset if
> something is wrong.

patches are welcome.

Jürgen

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

[Abdelrazak Younes]

On 02/02/2010 07:57 PM, Peter Kümmel wrote:

Andre Poenitz wrote:
   

On Tue, Feb 02, 2010 at 02:53:58PM +0100, Peter Kümmel wrote:
 

Am Sonntag, den 31.01.2010, 14:29 +0100 schrieb Andre Poenitz:
   

How do we proceed now ?
   

I think it's time to use signal/slots, this time in the right direction.
The buffer emits a message, possibly with an indication that it is
temporarily and the view (or the server...) connects to it.

Andre'
 

Does this also mean currently we have no clear Model/View design?
   

Sort of.

Right now the Gui is basically signaling the Core to change and the
Core pushes changes to the Gui. Which is pretty wrong.
 

You mean the core knows the gui and calls gui-only functions to
update the view? This would be indeed wrong.

Where there attempts to fix this design? Or was the design OK
in good old times and then somehow became wrong? Haven't Abdel
tried to cleanup this?
   


Yes, but it's not finished yet because we had fondamental disagreement 
on that issue, with JMarc mainly :-P basically this is about the 
dispatch machinery. Buffer and BufferView are already mostly fine here 
as they are using pseudo signal (see GuiDelegate and WorkAreaManager); 
it would be easy to switch to real Qt signal here. We also need to make 
those Alert calls real signals intead this mix up we have now.


As far as dispatch is concerned, my goal was to make GuiApp::dispatch() 
the first entry in the dispatch machinery instead of LyXFunc::dispatch() 
which should basically disappear... At the end, all the virtual 
interface in "src/frontend/" should disappear too.




Shouldn't we do a cleanup/redesign at such places?
   


We should yes.

Abdel.

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

[Jean-Marc Lasgouttes]

Abdelrazak Younes  writes:
> As far as dispatch is concerned, my goal was to make
> GuiApp::dispatch() the first entry in the dispatch machinery instead
> of LyXFunc::dispatch() which should basically disappear... At the end,
> all the virtual interface in "src/frontend/" should disappear too.

I could not care less about where is the main entry point as long as
there is a main entry point and everybody is not directly invoking
individual dispatch function.

About putting it in GuiApp, why not, although most of the code there is
non-gui code. What could/should probably move is the default: case of
the big switch. 

Note that, with my latest changes, LyXFunc only has two member variables
left (those for saving cursor x/y). I would propose to move these
variables into Cursor (savedX, savedY). Would somebody object to that?

Then there would not be a LyXFunc object anymore, but functions (or
static members).

JMarc

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

[Peter Kümmel]

Jean-Marc Lasgouttes wrote:
> Abdelrazak Younes  writes:
>> As far as dispatch is concerned, my goal was to make
>> GuiApp::dispatch() the first entry in the dispatch machinery instead
>> of LyXFunc::dispatch() which should basically disappear... At the end,
>> all the virtual interface in "src/frontend/" should disappear too.
> 
> I could not care less about where is the main entry point as long as
> there is a main entry point and everybody is not directly invoking
> individual dispatch function.
> 
> About putting it in GuiApp, why not, although most of the code there is
> non-gui code. What could/should probably move is the default: case of
> the big switch. 

Originally it was the Model-View-Controller pattern, so isn't a
controller the perfect candidate for the cental dispatcher?

> 
> Note that, with my latest changes, LyXFunc only has two member variables
> left (those for saving cursor x/y). I would propose to move these
> variables into Cursor (savedX, savedY). Would somebody object to that?
> 
> Then there would not be a LyXFunc object anymore, but functions (or
> static members).
> 
> JMarc
> 

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

[Peter Kümmel]

Peter Kümmel wrote:
> 
> Originally it was the Model-View-Controller pattern, so isn't a
> controller the perfect candidate for the central dispatcher?
> 

Wouldn't it be best to completely unlink the model and view like in
attached image, found as figue 4-6 in
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/CocoaDesignPatterns.html

Peter
<>

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

[Abdelrazak Younes]

On 02/03/2010 12:17 PM, Peter Kümmel wrote:

Peter Kümmel wrote:
   

Originally it was the Model-View-Controller pattern, so isn't a
controller the perfect candidate for the central dispatcher?

 


If we proceed as I suggested then that would be the result indeed:

model: everything in src/, src/inset/ and src/math/

view: all the different dialogs, including GuiView

controller: GuiApp mainly, but also GuiView::dispatch(), as well Dialog, 
GuiDialog and DialogView classes.



Wouldn't it be best to completely unlink the model and view like in
attached image, found as figue 4-6 in
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/CocoaDesignPatterns.html
   


At this point, this is becoming academic. What is especially important 
is that the model is free of any GUI code. Then we can always cleanup 
progressively the source code to have clearer separation between the 
views and the controllers, but that is of lesser importance.


Abdel

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

[Abdelrazak Younes]

On 02/03/2010 11:50 AM, Jean-Marc Lasgouttes wrote:

Abdelrazak Younes  writes:
   

As far as dispatch is concerned, my goal was to make
GuiApp::dispatch() the first entry in the dispatch machinery instead
of LyXFunc::dispatch() which should basically disappear... At the end,
all the virtual interface in "src/frontend/" should disappear too.
 

I could not care less about where is the main entry point as long as
there is a main entry point and everybody is not directly invoking
individual dispatch function.
   


Good we agree on that point at least.


About putting it in GuiApp, why not, although most of the code there is
non-gui code.


Some of this code will probably integrate back the non-gui code in forms 
of helper functions or methods. This is similar to what we did when I 
created GuiView::dispatch(), I move out a lot of code there and then a 
lot of code did return back to src/.




  What could/should probably move is the default: case of
the big switch.
   


Yes.


Note that, with my latest changes, LyXFunc only has two member variables
left (those for saving cursor x/y). I would propose to move these
variables into Cursor (savedX, savedY). Would somebody object to that?
   


Not from me. But I think there is already something similar in Cursor 
(Cursor saves its pre and post dispatch() state IIRC).



Then there would not be a LyXFunc object anymore, but functions (or
static members).
   


Yes.

Abdel.

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

[Jean-Marc Lasgouttes]

Abdelrazak Younes  writes:

>> Note that, with my latest changes, LyXFunc only has two member variables
>> left (those for saving cursor x/y). I would propose to move these
>> variables into Cursor (savedX, savedY). Would somebody object to that?
>>
>
> Not from me. But I think there is already something similar in Cursor
> (Cursor saves its pre and post dispatch() state IIRC).

Yes, but it saves it in the LyXFunc object.

JMarc

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

[Jean-Marc Lasgouttes]

Abdelrazak Younes  writes:
> If we proceed as I suggested then that would be the result indeed:
>
> model: everything in src/, src/inset/ and src/math/
>
> view: all the different dialogs, including GuiView
>
> controller: GuiApp mainly, but also GuiView::dispatch(), as well
> Dialog, GuiDialog and DialogView classes.

The controller could live in the frontends/ directory, and the view in
frontends/qt4 :)

JMarc

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

[Peter Kümmel]

Abdelrazak Younes wrote:
> On 02/03/2010 12:17 PM, Peter Kümmel wrote:
>> Peter Kümmel wrote:
>>
>>> Originally it was the Model-View-Controller pattern, so isn't a
>>> controller the perfect candidate for the central dispatcher?
>>>
>>>  
> 
> If we proceed as I suggested then that would be the result indeed:
> 
> model: everything in src/, src/inset/ and src/math/

Here I would move model relevant code from src to src/model,
then the binary would become a smaller project which onlx
links to the essential parts.

I would also introduce shared libraries which help to avoild
circular dependencies between the libraries, especially when building
Dlls on Windows, but maybe there is also a GCC flag to forbid such
dependencies .

> 
> view: all the different dialogs, including GuiView
> 
> controller: GuiApp mainly, but also GuiView::dispatch(), as well Dialog, 
> GuiDialog and DialogView classes.

I would not distribute the controller functionality to several classes.

> 
>> Wouldn't it be best to completely unlink the model and view like in
>> attached image, found as figue 4-6 in
>> http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/CocoaDesignPatterns.html
>>
> 
> At this point, this is becoming academic. What is especially important 
> is that the model is free of any GUI code. Then we can always cleanup 
> progressively the source code to have clearer separation between the 
> views and the controllers, but that is of lesser importance.

Having several views (GUI/non-GUI) it is better to also send model's
notifications through the controller.

> 
> Abdel
> 

Re: r33302 - lyx-devel/trunk/src

[Jean-Marc Lasgouttes]

"Vincent van Ravesteijn - TNW"  writes:
> I wouldn't handle LFUN_REGEXP_MODE twice in one function. That's prone
> to cause confusion later (I don't really understand the others that are
> handled twice).

Would the attached patch make sense to both of you?

> More important, I'm still not sure why we forbid the REGEXP_MODE in
> ERTs. Why does LyX crash ? 

I propose that we leave this (insets in pass_thru environments) for
later.

Note that more improvements are needed to handle both pass_thru layouts
and isPassThru insets (which are not the same thing).

JMarc

Re: r33302 - lyx-devel/trunk/src

[Jean-Marc Lasgouttes]

Jean-Marc Lasgouttes  writes:

> "Vincent van Ravesteijn - TNW"  writes:
>> I wouldn't handle LFUN_REGEXP_MODE twice in one function. That's prone
>> to cause confusion later (I don't really understand the others that are
>> handled twice).
>
> Would the attached patch make sense to both of you?
>
>> More important, I'm still not sure why we forbid the REGEXP_MODE in
>> ERTs. Why does LyX crash ? 
>
> I propose that we leave this (insets in pass_thru environments) for
> later.
>
> Note that more improvements are needed to handle both pass_thru layouts
> and isPassThru insets (which are not the same thing).
>
> JMarc

As usual.

svndiff

Index: src/insets/InsetText.cpp
===
--- src/insets/InsetText.cpp	(révision 33318)
+++ src/insets/InsetText.cpp	(copie de travail)
@@ -298,17 +298,6 @@ bool InsetText::getStatus(Cursor & cur, 
 	FuncStatus & status) const
 {
 	switch (cmd.action) {
-	case LFUN_LAYOUT:
-		status.setEnabled(!forcePlainLayout());
-		return true;
-
-	case LFUN_LAYOUT_PARAGRAPH:
-	case LFUN_PARAGRAPH_PARAMS:
-	case LFUN_PARAGRAPH_PARAMS_APPLY:
-	case LFUN_PARAGRAPH_UPDATE:
-		status.setEnabled(allowParagraphCustomization());
-		return true;
-
 	case LFUN_INSET_DISSOLVE: {
 		bool const main_inset = ().inset() == this;
 		bool const target_inset = cmd.argument().empty() 
Index: src/BufferView.cpp
===
--- src/BufferView.cpp	(révision 33318)
+++ src/BufferView.cpp	(copie de travail)
@@ -1024,11 +1024,6 @@ bool BufferView::getStatus(FuncRequest c
 		flag.setEnabled(true);
 		break;
 
-	case LFUN_REGEXP_MODE:
-		flag.setEnabled(buffer().isInternal() && !cur.inRegexped()
-&& cur.inset().lyxCode() != ERT_CODE);
-		break;
-
 	case LFUN_LABEL_COPY_AS_REF: {
 		// if there is an inset at cursor, see whether it
 		// handles the lfun
Index: src/Text3.cpp
===
--- src/Text3.cpp	(révision 33318)
+++ src/Text3.cpp	(copie de travail)
@@ -2393,6 +2393,11 @@ bool Text::getStatus(Cursor & cur, FuncR
 		code = MATH_HULL_CODE;
 		break;
 
+	case LFUN_REGEXP_MODE:
+		code = MATH_HULL_CODE;
+		enable = cur.buffer()->isInternal() && !cur.inRegexped();
+		break;
+
 	case LFUN_INSET_MODIFY:
 		// We need to disable this, because we may get called for a
 		// tabular cell via
@@ -2403,31 +2408,38 @@ bool Text::getStatus(Cursor & cur, FuncR
 
 	case LFUN_FONT_EMPH:
 		flag.setOnOff(fontinfo.emph() == FONT_ON);
+		enable = !cur.inset().getLayout().isPassThru();
 		break;
 
 	case LFUN_FONT_ITAL:
 		flag.setOnOff(fontinfo.shape() == ITALIC_SHAPE);
+		enable = !cur.inset().getLayout().isPassThru();
 		break;
 
 	case LFUN_FONT_NOUN:
 		flag.setOnOff(fontinfo.noun() == FONT_ON);
+		enable = !cur.inset().getLayout().isPassThru();
 		break;
 
 	case LFUN_FONT_BOLD:
 	case LFUN_FONT_BOLDSYMBOL:
 		flag.setOnOff(fontinfo.series() == BOLD_SERIES);
+		enable = !cur.inset().getLayout().isPassThru();
 		break;
 
 	case LFUN_FONT_SANS:
 		flag.setOnOff(fontinfo.family() == SANS_FAMILY);
+		enable = !cur.inset().getLayout().isPassThru();
 		break;
 
 	case LFUN_FONT_ROMAN:
 		flag.setOnOff(fontinfo.family() == ROMAN_FAMILY);
+		enable = !cur.inset().getLayout().isPassThru();
 		break;
 
 	case LFUN_FONT_TYPEWRITER:
 		flag.setOnOff(fontinfo.family() == TYPEWRITER_FAMILY);
+		enable = !cur.inset().getLayout().isPassThru();
 		break;
 
 	case LFUN_CUT:
@@ -2559,6 +2571,47 @@ bool Text::getStatus(Cursor & cur, FuncR
 		enable = theSpellChecker();
 		break;
 
+	case LFUN_LAYOUT:
+		enable = !cur.inset().forcePlainLayout();
+		break;
+		
+	case LFUN_LAYOUT_PARAGRAPH:
+	case LFUN_PARAGRAPH_PARAMS:
+	case LFUN_PARAGRAPH_PARAMS_APPLY:
+	case LFUN_PARAGRAPH_UPDATE:
+		enable = cur.inset().allowParagraphCustomization();
+		break;
+
+	// FIXME: why are accent lfuns forbidden with pass_thru layouts?
+	case LFUN_ACCENT_ACUTE:
+	case LFUN_ACCENT_BREVE:
+	case LFUN_ACCENT_CARON:
+	case LFUN_ACCENT_CEDILLA:
+	case LFUN_ACCENT_CIRCLE:
+	case LFUN_ACCENT_CIRCUMFLEX:
+	case LFUN_ACCENT_DOT:
+	case LFUN_ACCENT_GRAVE:
+	case LFUN_ACCENT_HUNGARIAN_UMLAUT:
+	case LFUN_ACCENT_MACRON:
+	case LFUN_ACCENT_OGONEK:
+	case LFUN_ACCENT_TIE:
+	case LFUN_ACCENT_TILDE:
+	case LFUN_ACCENT_UMLAUT:
+	case LFUN_ACCENT_UNDERBAR:
+	case LFUN_ACCENT_UNDERDOT:
+	case LFUN_FONT_DEFAULT:
+	case LFUN_FONT_FRAK:
+	case LFUN_FONT_SIZE:
+	case LFUN_FONT_STATE:
+	case LFUN_FONT_UNDERLINE:
+	case LFUN_FONT_STRIKEOUT:
+	case LFUN_FONT_UULINE:
+	case LFUN_FONT_UWAVE:
+	case LFUN_TEXTSTYLE_APPLY:
+	case LFUN_TEXTSTYLE_UPDATE:
+		enable = !cur.inset().getLayout().isPassThru();
+		break;
+
 	case LFUN_WORD_DELETE_FORWARD:
 	case LFUN_WORD_DELETE_BACKWARD:
 	case LFUN_LINE_DELETE:
@@ -2588,6 +2641,15 @@ bool Text::getStatus(Cursor & cur, FuncR
 	case LFUN_WORD_LEFT_SELECT:
 	case LFUN_WORD_SELECT:
 	case LFUN_SECTION_SELECT:
+	case LFUN_BUFFER_BEGIN:

RE: [patch] bug 6503: Including self as child document crashes branch

[Vincent van Ravesteijn - TNW]

>http://www.lyx.org/trac/ticket/6503
>
>This crash is caused by an infinite loop in Encodings::initMath,
>which recursively calls itself if a document includes itself
>(we already issue a warning about that, but in the given case,
>LyX crashes before the warning can be issued).
>

First, Encodings::initMath should get the children like this. Please, use 
buffer->getChildren() for that. 

Now, we can avoid that getChildren() returns a list including itself.

Vincent

RE: [patch] bug 6503: Including self as child document crashes branch

[Jürgen Spitzmüller]

Vincent van Ravesteijn - TNW wrote:

> First, Encodings::initMath should get the children like this. Please, use
> buffer->getChildren() for that.
> 
> Now, we can avoid that getChildren() returns a list including itself.

In other words, patch b?

Jürgen

RE: [patch] bug 6503: Including self as child document crashes branch

[Vincent van Ravesteijn - TNW]

 
>> First, Encodings::initMath should get the children like this. Please, 
>> use
>> buffer->getChildren() for that.
>> 
>> Now, we can avoid that getChildren() returns a list including itself.
>
>In other words, patch b?
>

No, I refrain from words that other people might understand.

I mean you shouldn't use the isChild function from Encoding::initMath. 

To fix the bugs, we should check for recursive includes when the InsetInclude 
changes (that's now done for document including itself; this should thus be 
checked for all relatives (bug 6305)), _and_ when the filename of the buffer 
changes (bug 6303).

Just like Jmarc I don't like the ad-hoc approach of patch a, but neither the 
ad-hoc approach of patch b :).. Checking only for the simple recursive case in 
the isChild function, because some function somewhere uses a homegrown method 
to get all children does not pass my ad-hoc-test.

First the isChild function shouldn't be used, second I don't expect this 
behaviour of the isChild function. If A includes A, I expect A->isChild(A) to 
return true. As stated above, instead we should avoid having a situation that A 
includes A.

Vincent

RE: [patch] bug 6503: Including self as child document crashes branch

[Jürgen Spitzmüller]

Vincent van Ravesteijn - TNW wrote:

> I mean you shouldn't use the isChild function from Encoding::initMath.

To clarify: this is not my code. Anyway, you mean this?

Index: src/Encoding.cpp 
   
=== 
   
--- src/Encoding.cpp(Revision 33282)
+++ src/Encoding.cpp(Arbeitskopie)
@@ -554,11 +554,10 @@
it->initUnicodeMath();

// Check children
-   BufferList::iterator bit = theBufferList().begin();
-   BufferList::iterator const bend = theBufferList().end();
-   for (; bit != bend; ++bit)
-   if (buffer.isChild(*bit))
-   initUnicodeMath(**bit, false);
+   std::vector clist = buffer.getChildren();
+   for (vector::const_iterator cit = clist.begin();
+cit != clist.end(); ++cit)
+   initUnicodeMath(**cit, false);
 #endif
 }


> To fix the bugs, we should check for recursive includes when the
> InsetInclude changes (that's now done for document including itself; this
> should thus be checked for all relatives (bug 6305)), and when the
> filename of the buffer changes (bug 6303).

I see. I don't have time to do that, though.

Jürgen

RE: [patch] bug 6503: Including self as child document crashes branch

[Vincent van Ravesteijn - TNW]

 
>> I mean you shouldn't use the isChild function from
>> Encoding::initMath.
>
> To clarify: this is not my code. Anyway, you mean this?

Yes, of course I know it's not your code. And yes, this is what I mean. 

>> To fix the bugs, we should check for recursive includes when the 
>> InsetInclude changes (that's now done for document including itself; 
>> this should thus be checked for all relatives (bug 6305)), and when 
>> the filename of the buffer changes (bug 6303).
>
>I see. I don't have time to do that, though.

If you now put in the constraint that Buffer::getChildren cannot return the 
buffer itself as one of its children, then you fixed the problem you were 
trying to fix. If that's what you was planning to do.

Vincent

RE: [patch] bug 6503: Including self as child document crashes branch

[Vincent van Ravesteijn - TNW]

 
>But then there is this bug too:
>http://www.lyx.org/trac/ticket/6505
>

That's already known for a long time, but in the past we decided it was not 
worth fixing it. See bug #1474.

Vincent

RE: OpenDocument export [was Re: too long]

[Rob Oakes]

Hi Ethan,

The DocBook import/export actually seems to work pretty well.  It is, 
unfortunately, a subset of the full docbook spec, however.  I haven't hit the 
technical limitations, but I've seen a number of complaints on behalf of others.

For the open source writing book I am writing, I've been trying to find a 
robust way of exchanging documents and collecting edits from non-LaTeX/LyX 
users.  The OpenOffice DocBook support appears to be the best option for simple 
text based documents.  Apparently, everything goes to hell once Mathematics and 
images get added.  I haven't done much first hand-experimentation, however.

I eventually gave up trying to round trip documents to Microsoft Word.  Getting 
LyX output into a format that can be read by Word is only half the battle.  
Trying to incorporate changes made by others is an even bigger struggle and it 
just isn't worth it. 

Cheers,

Rob

-Original Message-
From: Ethan Metsger [mailto:emets...@obj-sys.com] 
Sent: Wednesday, February 03, 2010 8:45 AM
To: Lyx Users
Subject: OpenDocument export [was Re: too long]

On Tue, 02 Feb 2010 20:19:54 -0500, Waluyo Adi Siswanto  
wrote:

> I am using Ubuntu(Ubuntu 8.10 and LyX 1.6.5) and I can export to 
> OpenDocument easily  (from File>Export>OpenDocument) and it creates 
> *,odt. When I open this file using OpenOffice and if I double click 
> the equations created by LyX it will be in OpenOffice equation, all 
> equations can be edited and continued in OpenOffice without any 
> problems.

I can confirm this works out of the box on Ubuntu Karmic.  Whether it works on 
more complicated documents, I don't know.  I also note that OO.org has a LaTeX 
exporter, but regretfully cannot import LaTeX.  It's supposed to support 
DocBook imports, but I haven't tried it.

Best,

Ethan
(emets...@obj-sys.com)

RE: [patch] bug 6503: Including self as child document crashes branch

[Jürgen Spitzmüller]

Vincent van Ravesteijn - TNW wrote:

> If you now put in the constraint that Buffer::getChildren cannot return
> the buffer itself as one of its children, then you fixed the problem you
> were trying to fix. If that's what you was planning to do.

Yes, this would be the attached (which even fixes, AFAICS, the problem with 
A includes B includes C includes A).

But I understood that you (and JMarc) were rather proposing something more 
smart.

JürgenIndex: src/Encoding.cpp
===
--- src/Encoding.cpp	(Revision 33282)
+++ src/Encoding.cpp	(Arbeitskopie)
@@ -554,11 +554,10 @@
 		it->initUnicodeMath();
 
 	// Check children
-	BufferList::iterator bit = theBufferList().begin();
-	BufferList::iterator const bend = theBufferList().end();
-	for (; bit != bend; ++bit)
-		if (buffer.isChild(*bit))
-			initUnicodeMath(**bit, false);
+	std::vector clist = buffer.getChildren();
+	for (vector::const_iterator cit = clist.begin();
+	 cit != clist.end(); ++cit) 
+		initUnicodeMath(**cit, false);
 #endif
 }
 
Index: src/Buffer.cpp
===
--- src/Buffer.cpp	(Revision 33282)
+++ src/Buffer.cpp	(Arbeitskopie)
@@ -1816,12 +1816,17 @@
 	Impl::BufferPositionMap::iterator end = d->children_positions.end();
 	for (; it != end; ++it) {
 		Buffer * child = const_cast(it->first);
-		clist.push_back(child);
+		// ignore recursive includes
+		if (child != this)
+			clist.push_back(child);
 		// there might be grandchildren
 		std::vector glist = child->getChildren();
 		for (vector::const_iterator git = glist.begin();
-		 git != glist.end(); ++git)
-			clist.push_back(*git);
+		 git != glist.end(); ++git) {
+			// ignore recursive includes
+			if (*git != this)
+clist.push_back(*git);
+		}
 	}
 	return clist;
 }

RE: #6507: Underscores lead to corrupted label names in display-mode text box

[Matthew]

Any idea when this might be fixed?  The comments in #2872 imply that the cause 
and fix are both known.

Thanks!



-Original Message-
From: LyX Ticket Tracker [mailto:t...@lyx.org] 
Sent: Wednesday, February 03, 2010 12:07 AM
To: pruchek+...@gmail.com; lasgout...@lyx.org
Subject: Re: #6507: Underscores lead to corrupted label names in display-mode 
text box

#6507: Underscores lead to corrupted label names in display-mode text box
-+--
 Reporter:  pruchek  |Owner:  lasgouttes
 Type:  defect   |   Status:  closed
 Priority:  normal   |Milestone:
Component:  general  |  Version:  1.6.5 
 Severity:  normal   |   Resolution:  duplicate 
 Keywords:   |  
-+--
Changes (by spitz):

  * status:  new => closed
  * resolution:  => duplicate


Comment:

 this is #2872.

-- 
Ticket URL: 
The LyX Project 
LyX -- The Document Processor

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

[Peter Kümmel]

Peter Kümmel wrote:
> Peter Kümmel wrote:
>> Originally it was the Model-View-Controller pattern, so isn't a
>> controller the perfect candidate for the central dispatcher?
>>
> 
> Wouldn't it be best to completely unlink the model and view like in
> attached image, found as figue 4-6 in
> http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/CocoaDesignPatterns.html

Diving a little bit deeper into the Apple's docs I must admit:
Documentation at it's best!
Such docu I miss for Qt, most there is a extended doxygen API
description only, no big-picture is given any where.

By the way, being again off-topic-on-the wrong-list:
Are there plans to create a "Qt Interface Builder"
which exports .qib files?

Peter

Re: How I can add a new button to the tool bar?

[Uwe Stöhr]

durocortorum73-gm...@yahoo.fr schrieb:


I attach to this mail the current Tango-ified LyX icons. They are probably not 
interesting on Windows platform as Tango is mostly a linux thing.


I don't think that the OS matters here. The most important thing is that 
you know what the button stands for.



As I said, at present, my main issue for distribution is the mixing of several licenses. I do not know under 
which license the whole may be distributed. I have done a significant work (in terms of hours) to shrink 22 and 
24 pixels icons to fit in 20, while preserving the aspect, and sometimes I did some pixel work ("pdf", 
"ps", "dvi" words, outline icons, footnote & margin note icons). I have no issue in 
putting my contribution under any license that would be compatible with the original ones.


LyX in general only accepts the GPL version 2 or later (and Creative 
commons (needs to be discussed first on the lyx-devel list)).



A little text file explains the history of most icons. I tried to use Tango 
icons mainly, they are public domain. The part I took from gimp can be easily 
redone (and will be for consistency I think). I also provide some xcf files for 
icons that have common parts.


Your work is impressive but perhaps too much. The current LyX icons are 
known by the users and thus shouldn't be changed if possible.
I see the problem you mentioned that icons with 24x24 pixels look 
blurred and I think we should only fix these icons and make them 20x20 
icons.


Your icons are nevertheless very nice and we should have a discussion 
about them. I therefore propose to upload them to our Wiki:

http://wiki.lyx.org/LyX/Icons

I'm forwarding this to the lyx-devel list.

regards Uwe

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

[Andre Poenitz]

On Wed, Feb 03, 2010 at 06:27:06PM +0100, Peter Kümmel wrote:
> Peter Kümmel wrote:
> > Peter Kümmel wrote:
> >> Originally it was the Model-View-Controller pattern, so isn't a
> >> controller the perfect candidate for the central dispatcher?
> >>
> > 
> > Wouldn't it be best to completely unlink the model and view like in
> > attached image, found as figue 4-6 in
> > http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/CocoaDesignPatterns.html
> 
> Diving a little bit deeper into the Apple's docs I must admit:
> Documentation at it's best!
> Such docu I miss for Qt, most there is a extended doxygen API
> description only, no big-picture is given any where.
> 
> By the way, being again off-topic-on-the wrong-list:
> Are there plans to create a "Qt Interface Builder"
> which exports .qib files?

What's a .qib file?  I only find http://filext.com/file-extension/QIP
which seems unrelated.

Andre'

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

[Andre Poenitz]

On Wed, Feb 03, 2010 at 12:40:04PM +0100, Peter Kümmel wrote:
> I would also introduce shared libraries which help to avoild
> circular dependencies between the libraries, especially when building
> Dlls on Windows, but maybe there is also a GCC flag to forbid such
> dependencies .

Linking with --no-undefined --allow-shlib-undefined might do the trick.

Andre'

Re: How I can add a new button to the tool bar?

[Edwin Leuven]

Uwe Stöhr wrote:

The current LyX icons are known by the users and thus shouldn't be
changed if possible.


the  current icons are also known by the users to be butt-ugly and give 
a very amateurish first impression (so i've been told)


personally i'd change them in an instant for something consistent and 
better looking.



Your icons are nevertheless very nice and we should have a discussion
 about them. I therefore propose to upload them to our Wiki: 
http://wiki.lyx.org/LyX/Icons


please do

Re: How I can add a new button to the tool bar?

[Edwin Leuven]

ps. and what would be a better occasion to change the icons than a 2.0 
release?!

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

[Peter Kümmel]

Andre Poenitz wrote:
> On Wed, Feb 03, 2010 at 06:27:06PM +0100, Peter Kümmel wrote:
>> Peter Kümmel wrote:
>>> Peter Kümmel wrote:
 Originally it was the Model-View-Controller pattern, so isn't a
 controller the perfect candidate for the central dispatcher?

>>> Wouldn't it be best to completely unlink the model and view like in
>>> attached image, found as figue 4-6 in
>>> http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/CocoaDesignPatterns.html
>> Diving a little bit deeper into the Apple's docs I must admit:
>> Documentation at it's best!
>> Such docu I miss for Qt, most there is a extended doxygen API
>> description only, no big-picture is given any where.
>>
>> By the way, being again off-topic-on-the wrong-list:
>> Are there plans to create a "Qt Interface Builder"
>> which exports .qib files?
> 
> What's a .qib file?  I only find http://filext.com/file-extension/QIP
> which seems unrelated.
> 
> Andre'
> 

.qib is analog to .nib "NeXT Interface Builder".
The Interface Builder of the Mac still uses the .nib extension;
they still follow their "NS ideology": NSObject, NSString, ...

Peter

Re: How I can add a new button to the tool bar?

[Joost Verburg]

On 2/3/2010 1:32 PM, Edwin Leuven wrote:

the current icons are also known by the users to be butt-ugly and give a
very amateurish first impression (so i've been told)

personally i'd change them in an instant for something consistent and
better looking.


+1

The current icons look old and are somewhat confusing. Having modern and 
consistent icons would be a great thing!


Joost

Re: [patch] bug 6503: Including self as child document crashes branch

[Vincent van Ravesteijn]

Jürgen Spitzmüller schreef:

Vincent van Ravesteijn - TNW wrote:

  

If you now put in the constraint that Buffer::getChildren cannot return
the buffer itself as one of its children, then you fixed the problem you
were trying to fix. If that's what you was planning to do.



Yes, this would be the attached (which even fixes, AFAICS, the problem with 
A includes B includes C includes A).
  


No I don't think that will fixed. If A would collect all grandchildren 
in one vector without duplication and executes the function for them, 
then it's not a problem, but now A.do() calls B.do() which gets all 
children of B and calls C.do() which calls A.do() again.
But I understood that you (and JMarc) were rather proposing something more 
smart.
  


The "smart" is to check for this before starting a master-child relation.

Vincent

about the libintl version in the LyX windows installer

[Uwe Stöhr]

Hello Joost,

good to see that you are still active with LyX.
As you might know, the Windows version of LyX suffers from of a buggy version of libintl (intl.dll). 
This is the reason why you for example cannot switch the menu language from within LyX. JMarc once 
identified the bug as bug in the libintl version we are using for LyX on Windows and you tried to 
compile a more recent version of libintl for Windows but failed.


I now made a new attempt to overcome this problem. I found an up to date windows version of gettext 
including libintl:

http://www.gtk.org/download-windows.html

I also found other Windows sources of gettext 0.17 for Windows and could compile the intl.dll from 
the sources. The problem is that my compiled intl.dll won't link with your LyX Windows package and 
all my attempts to change the source code to make it link failed. Can you therefore please have a 
look if you are able to use gettext 0.17 for you LyX Windows bundle?


I can also send you a zip-file containing the libintl sources and an MSVC 
project file if you like.

many thanks in advance and regards
Uwe

Re: XML?

[Pavel Sanda]

Guenter Milde wrote:
> Thanks for this tip. 
> 
> However, trying this in the minibuffer of my LyX 1.6.5, with a lyx file
> from my home dir, I did get no reaction from LyX (except mirroring the
> command in the status bar) and the line 
> 
>  Das Verzeichnis ist nicht lesbar.
>  
> (The directory cannot be read.) in the .xsession-errors file

rtfm ;) i wrote it from my cache only.
vc_command DR $$p "my-editor $$i"

pavel