Re: 2.2

[Liviu Andronic]

On Wed, May 13, 2015 at 10:42 AM, Jean-Marc Lasgouttes
lasgout...@lyx.org wrote:

 Hi there,

 The ritual question: what is still needed for 2.2?

 I guess we are still waiting for some python 3.3 goodness from José, but
 what else?

 It seems to me that publishing a beta version soon is very desirable.
 Consider that for 2.1 we had 8 months between first beta and 2.1 release.

Should we go ahead with #6692?
http://www.lyx.org/trac/ticket/6692

There seems to be user demand, and the implementation feels little
intrusive. I think we would like to test the changed menus a bit
before the betas arrive and the feature freeze kicks in.

Along with the above, #6783 would deserve attention (it seems like an easy fix):
http://www.lyx.org/trac/ticket/6783


Liviu


 Vincent, are you still our release manager, or are your other management
 duties still interfering? I like the way you force us to fix every detail
 before release, I think this is needed.

 JMarc




-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: Re: [LyX/master] Fix build with GNU libstdc++ C++11 ABI

[José Matos]

On Tuesday 12 May 2015 21:32:23 Georg Baum wrote:
 Thanks to you and Kornel for testing.
 
 José, depending on how urgent this is you can now either include a local 
 patch in fedora or wait for LyX 2.1.4.
 
 
 Georg

Thank you Georg,
this fix is for rawhide, that is planned to be released as Fedora 23, 
on November. Even with our schedule 2.1.4 should be out at that time (and 
hopefully 2.2.0 as well). :-) :-D

Fedora 22 that will be released this month ships with gcc 5.1 but with 
the old ABI so it is not affected.

Again thank you for you thoroughly fix.

Regards, 
-- 
José Abílio

2.2

[Jean-Marc Lasgouttes]

Hi there,

The ritual question: what is still needed for 2.2?

I guess we are still waiting for some python 3.3 goodness from José, but 
what else?


It seems to me that publishing a beta version soon is very desirable. 
Consider that for 2.1 we had 8 months between first beta and 2.1 release.


Vincent, are you still our release manager, or are your other management 
duties still interfering? I like the way you force us to fix every 
detail before release, I think this is needed.


JMarc

Re: 2.2

[Jürgen Spitzmüller]

2015-05-13 10:42 GMT+02:00 Jean-Marc Lasgouttes:


 Hi there,

 The ritual question: what is still needed for 2.2?

 I guess we are still waiting for some python 3.3 goodness from José, but
 what else?

 It seems to me that publishing a beta version soon is very desirable.
 Consider that for 2.1 we had 8 months between first beta and 2.1 release.

 Vincent, are you still our release manager, or are your other management
 duties still interfering? I like the way you force us to fix every detail
 before release, I think this is needed.


I think we should go into a feature freeze soon and concentrate on fixing
up the necessary things (python3, qt5) and bugs.

IMHO we already have enough new features that qualify a major release.

Jürgen




 JMarc

Re: [patch] better color support in character dialog

[Richard Heck]

On 05/12/2015 07:08 PM, Uwe Stöhr wrote:

Dear LyXers,

it annoyed me a long time that LyX does only provide the most basic 
colors in the character dialog and that these colors are not even 
displayed there.
(For example I use the color lime quite frequently and had therefore 
to use TeX code.)


I thought about this and offering all possible rgb colors would be a 
nightmare because this will pollute the TeX output with color 
definitions and a strength of TeX is to provide a well-structured 
output. So providing only a basic set of colors makes sense.
Since we support the package xcolor for a long time we could expand 
our color list with the standard fonts of xcolor.


This is done in the attached patch. The patch also displays the colors 
in the dialog. It contains also the necessary tex2lyx changes. I will 
of course add lyx2lyx when going on.


OK to go on?


Seems reasonable enough to me.

Check for whitespace errors here:


diff --git a/src/frontends/qt4/GuiPrefs.cpp b/src/frontends/qt4/GuiPrefs.cpp
index 995f8fa..7c5f236 100644
--- a/src/frontends/qt4/GuiPrefs.cpp
+++ b/src/frontends/qt4/GuiPrefs.cpp
@@ -1121,11 +1121,22 @@ PrefColors::PrefColors(GuiPreferences * form)
if (lc == Color_none
|| lc == Color_black
|| lc == Color_white
-   || lc == Color_red
+   || lc == Color_blue
+   || lc == Color_brown
+   || lc == Color_cyan
+   || lc == Color_darkgray
+   || lc == Color_gray
|| lc == Color_green
-   || lc == Color_blue
-   || lc == Color_cyan
+   || lc == Color_lightgray
+   || lc == Color_lime
|| lc == Color_magenta
+   || lc == Color_olive
+   || lc == Color_orange
+   || lc == Color_pink
+   || lc == Color_purple
+   || lc == Color_red
+   || lc == Color_teal
+   || lc == Color_violet
|| lc == Color_yellow
|| lc == Color_inherit
|| lc == Color_ignore)



rh

Re: 2.2

[José Matos]

On Wednesday 13 May 2015 10:42:44 Jean-Marc Lasgouttes wrote:
 I guess we are still waiting for some python 3.3 goodness from José, but 
 what else?

The reason why I am a bit stuck here is due to the nature of string handling on 
python3.

Python 3 requires that when we open a file to already know the encoding or else 
to treat the file as binary that is composed of bytes. And bytes and strings do 
not talk to each other directly.

Usually this is not a problem since for modern lyx (after 1.6? ) all files are 
utf8. The problem comes from older files than can have other encodings. For 
those we need to read the preamble, determine the encoding, and then reopen the 
file as a text file with that encoding.

The reason why I am stuck (since I am busy with other issues) is because I 
would like to do this in a way that the changes are minimal and such that as 
soon as we remove python 2 support the changes are equally non-invasive. With a 
little bit of care that has been possible for all the other issues so that the 
code is native to both 2 and 3, in the sense that it does not look like an 
horrible contraption for each version.

I have on my immediate todo list to generate a list of files where changes are 
needed on what is the status for each file as you proposed in a tracker issue.

Regards,
-- 
José Abílio

math macro crashes again (bug 9490)

[Georg Baum]

Hi,

after a lot of debugging I understand now what happens in 
http://www.lyx.org/trac/ticket/9490. As you may recall, the last math macro 
crash I fixed (9418) was caused by a broken ArgumentProxy::mathMacro_ 
pointer. At that time, I assumed that the only place where an ArgumentProxy 
can occur is as an element of MathMacro::d-expanded_ (which is also 
indicated by the comment in ArgumentProxy::draw(). Under this assumption, 
the fix for 9418 would have fixed all cases of invalid mathMacro_ pointers.

However, this assumption is not true. In MathData::detachMacroParameters(), 
elements of MathMacro::d-expanded_ can be extracted and put into the same 
vector as the macro itself. Unfortunately, if you insert an element into a 
vector, the existing elements may be copied = pointers may become invalid. 
The fix for 9419 does not work for this case, since the ArgumentProxy 
instances in question are already extracted from the macro and stored in the 
local variable detachedArgs.

It would be relatively easy to do a local fix in 
MathData::detachMacroParameters(). However, since the detached ArgumentProxy 
instances stay alive after leaving MathData::detachMacroParameters(), this 
is not enough.

I tried to keep a record of each ArgumentProxy child in a new member of the 
MathMacro itself. Then ArgumentProxy::setOwner() can be called reliably 
whenever a copy of a MathMacro is made. This works fine, but exposes another 
problem: When following the recipe of bug 9490, a MathMacro instance is 
deleted in Undo::Private::doTextUndoOrRedo() while an ArgumentProxy pointing 
to it is still alive.

What to do now? I don't know. I see the following options:

- Change the base class of MathData to RandomAccessList as proposed by Abdel 
in the discussion of 9419. This would solve the invalid pointer problems, 
but not the problem showed by the undo stack, and I fear that more hidden 
problems like this one exist. To me it is now more clear than during the 
discussion of 9418 that the self-contained property of a MathInset is 
really really important and assumed implicitly all over the place. The 
ArgumentProxy is not self-contained, and this is the root of all evil.

- Get rid of MathData::detachMacroParameters(). This would be a feature 
regression: Unfolding a math macro would no longer be possible. Is this an 
important feature?

- Rewrite ArgumentProxy to get rid of the mathMacro_ pointer (or even get 
rid of the class ArgumentProxy). This is a big task.


Any other ideas? Preferences? Unless somebody has a brilliant idea I tend 
towards the second item, since the first does not solve all problems, and 
the last is too much work for me ATM.



Georg

Re: 2.2

[Stephan Witt]

Am 13.05.2015 um 10:42 schrieb Jean-Marc Lasgouttes lasgout...@lyx.org:

 
 Hi there,
 
 The ritual question: what is still needed for 2.2?

The patch I've sent to list on Fri, Mar 20, 2015 at 10:15:18AM +0100, named
0001-svg-hidpi-on-mac.patch is not applied already.

It is needed - but I didn't do it until now because it breaks the rendering of 
the
splash image (the BackgroundWidget of GuiView) and I got distracted from 
solving this.

Stephan

 
 I guess we are still waiting for some python 3.3 goodness from José, but what 
 else?
 
 It seems to me that publishing a beta version soon is very desirable. 
 Consider that for 2.1 we had 8 months between first beta and 2.1 release.
 
 Vincent, are you still our release manager, or are your other management 
 duties still interfering? I like the way you force us to fix every detail 
 before release, I think this is needed.
 
 JMarc
 

Re: math macro crashes again (bug 9490)

[Guillaume M-M]

On 05/13/15 21:34, Georg Baum wrote:

Hi,

after a lot of debugging I understand now what happens in
http://www.lyx.org/trac/ticket/9490. As you may recall, the last math macro
crash I fixed (9418) was caused by a broken ArgumentProxy::mathMacro_
pointer. At that time, I assumed that the only place where an ArgumentProxy
can occur is as an element of MathMacro::d-expanded_ (which is also
indicated by the comment in ArgumentProxy::draw(). Under this assumption,
the fix for 9418 would have fixed all cases of invalid mathMacro_ pointers.

However, this assumption is not true. In MathData::detachMacroParameters(),
elements of MathMacro::d-expanded_ can be extracted and put into the same
vector as the macro itself. Unfortunately, if you insert an element into a
vector, the existing elements may be copied = pointers may become invalid.
The fix for 9419 does not work for this case, since the ArgumentProxy
instances in question are already extracted from the macro and stored in the
local variable detachedArgs.

It would be relatively easy to do a local fix in
MathData::detachMacroParameters(). However, since the detached ArgumentProxy
instances stay alive after leaving MathData::detachMacroParameters(), this
is not enough.

I tried to keep a record of each ArgumentProxy child in a new member of the
MathMacro itself. Then ArgumentProxy::setOwner() can be called reliably
whenever a copy of a MathMacro is made. This works fine, but exposes another
problem: When following the recipe of bug 9490, a MathMacro instance is
deleted in Undo::Private::doTextUndoOrRedo() while an ArgumentProxy pointing
to it is still alive.

What to do now? I don't know. I see the following options:

- Change the base class of MathData to RandomAccessList as proposed by Abdel
in the discussion of 9419. This would solve the invalid pointer problems,
but not the problem showed by the undo stack, and I fear that more hidden
problems like this one exist. To me it is now more clear than during the
discussion of 9418 that the self-contained property of a MathInset is
really really important and assumed implicitly all over the place. The
ArgumentProxy is not self-contained, and this is the root of all evil.

- Get rid of MathData::detachMacroParameters(). This would be a feature
regression: Unfolding a math macro would no longer be possible. Is this an
important feature?

- Rewrite ArgumentProxy to get rid of the mathMacro_ pointer (or even get
rid of the class ArgumentProxy). This is a big task.


Any other ideas? Preferences? Unless somebody has a brilliant idea I tend
towards the second item, since the first does not solve all problems, and
the last is too much work for me ATM.



Georg





Dear Georg,


Thank you for looking at these bugs. I reported 9418 and 9490, and I use 
macro unfolding quite often. Before discovering this feature, I would 
occasionally edit the lyx file externally (!) to change certain macros. 
Given that the original bug was about a crash occurring during 
unfolding, the second solution is a bit like curing a pain by amputation...


I would really appreciate a long-term solution to the math macro bugs. 
It would be useful to know whether many other people had segmentation 
faults because of macros, because I suspect that these crashes have been 
under-reported due to how hard they were to reproduce.


Thank you again for the hard work.


Best,
Guillaume

Re: ui: Setting a vertical size policy

[Pavel Sanda]

Scott Kostyshak wrote:
 In View  Messages Pane, I would like to improve the vertical size
 policy such that the text of the radio buttons is not truncated at the
 minimum height, as it is in the attached screenshot.

I can't reproduce your screenshot here (qt 4.8.5).

 Does anyone know the correct way to do this? I can succeed if I
 hardcode a height, but that does not seem like a good idea.

Hardcoding vertical size? If I use different font or qt theme on my system then 
it will break.
Size policies should fix that, but I remember getting quite a headache from 
trying to fix
this dialog so the vertical size does not get way too big ;)

Pavel

Re: 2.2

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:

 Hi there,

 The ritual question: what is still needed for 2.2?

- how far from finished status is epub support (Richard?)
- is there some some progress on lyx-odt project (Stefano?)

Pavel

Re: [patch] support to set box features in the box dialog

[Pavel Sanda]

Uwe Stöhr wrote:
 Am 11.05.2015 um 17:32 schrieb Pavel Sanda:

 Could you put the hardcoded values like 0.4pt, 3pt into some const 
 variable and use it instead
 of spilling these strings all over the place?

 Thanks for the hint. I have done this now and also improved the code to 
 shorten it and to assure a clean LaTeX output.

You are repeatably uing this contruct:
thickness_string.find(defaultThick) != string::npos

What is thickness_string and similar supposed to contain?

Pavel

ui: Setting a vertical size policy

[Scott Kostyshak]

In View  Messages Pane, I would like to improve the vertical size
policy such that the text of the radio buttons is not truncated at the
minimum height, as it is in the attached screenshot.

Does anyone know the correct way to do this? I can succeed if I
hardcode a height, but that does not seem like a good idea.

Scott

Re: [patch] support to set box features in the box dialog

[Pavel Sanda]

Uwe Stöhr wrote:
> Am 11.05.2015 um 17:32 schrieb Pavel Sanda:
>
>> Could you put the hardcoded values like "0.4pt", "3pt" into some const 
>> variable and use it instead
>> of spilling these strings all over the place?
>
> Thanks for the hint. I have done this now and also improved the code to 
> shorten it and to assure a clean LaTeX output.

You are repeatably uing this contruct:
thickness_string.find(defaultThick) != string::npos

What is thickness_string and similar supposed to contain?

Pavel

2.2

[Jean-Marc Lasgouttes]

Hi there,

The ritual question: what is still needed for 2.2?

I guess we are still waiting for some python 3.3 goodness from José, but 
what else?


It seems to me that publishing a beta version soon is very desirable. 
Consider that for 2.1 we had 8 months between first beta and 2.1 release.


Vincent, are you still our release manager, or are your other management 
duties still interfering? I like the way you force us to fix every 
detail before release, I think this is needed.


JMarc

Re: 2.2

[Liviu Andronic]

On Wed, May 13, 2015 at 10:42 AM, Jean-Marc Lasgouttes
 wrote:
>
> Hi there,
>
> The ritual question: what is still needed for 2.2?
>
> I guess we are still waiting for some python 3.3 goodness from José, but
> what else?
>
> It seems to me that publishing a beta version soon is very desirable.
> Consider that for 2.1 we had 8 months between first beta and 2.1 release.
>
Should we go ahead with #6692?
http://www.lyx.org/trac/ticket/6692

There seems to be user demand, and the implementation feels little
intrusive. I think we would like to test the changed menus a bit
before the betas arrive and the feature freeze kicks in.

Along with the above, #6783 would deserve attention (it seems like an easy fix):
http://www.lyx.org/trac/ticket/6783


Liviu


> Vincent, are you still our release manager, or are your other management
> duties still interfering? I like the way you force us to fix every detail
> before release, I think this is needed.
>
> JMarc
>



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: 2.2

[Jürgen Spitzmüller]

2015-05-13 10:42 GMT+02:00 Jean-Marc Lasgouttes:

>
> Hi there,
>
> The ritual question: what is still needed for 2.2?
>
> I guess we are still waiting for some python 3.3 goodness from José, but
> what else?
>
> It seems to me that publishing a beta version soon is very desirable.
> Consider that for 2.1 we had 8 months between first beta and 2.1 release.
>
> Vincent, are you still our release manager, or are your other management
> duties still interfering? I like the way you force us to fix every detail
> before release, I think this is needed.
>

I think we should go into a feature freeze soon and concentrate on fixing
up the necessary things (python3, qt5) and bugs.

IMHO we already have enough new features that qualify a major release.

Jürgen



>
> JMarc
>
>

Re: Re: [LyX/master] Fix build with GNU libstdc++ C++11 ABI

[José Matos]

On Tuesday 12 May 2015 21:32:23 Georg Baum wrote:
> Thanks to you and Kornel for testing.
> 
> José, depending on how urgent this is you can now either include a local 
> patch in fedora or wait for LyX 2.1.4.
> 
> 
> Georg

Thank you Georg,
this fix is for rawhide, that is planned to be released as Fedora 23, 
on November. Even with our schedule 2.1.4 should be out at that time (and 
hopefully 2.2.0 as well). :-) :-D

Fedora 22 that will be released this month ships with gcc 5.1 but with 
the old ABI so it is not affected.

Again thank you for you thoroughly fix.

Regards, 
-- 
José Abílio

Re: 2.2

[José Matos]

On Wednesday 13 May 2015 10:42:44 Jean-Marc Lasgouttes wrote:
> I guess we are still waiting for some python 3.3 goodness from José, but 
> what else?

The reason why I am a bit stuck here is due to the nature of string handling on 
python3.

Python 3 requires that when we open a file to already know the encoding or else 
to treat the file as binary that is composed of bytes. And bytes and strings do 
not talk to each other directly.

Usually this is not a problem since for modern lyx (after 1.6? ) all files are 
utf8. The problem comes from older files than can have other encodings. For 
those we need to read the preamble, determine the encoding, and then reopen the 
file as a text file with that encoding.

The reason why I am stuck (since I am busy with other issues) is because I 
would like to do this in a way that the changes are minimal and such that as 
soon as we remove python 2 support the changes are equally non-invasive. With a 
little bit of care that has been possible for all the other issues so that the 
code is native to both 2 and 3, in the sense that it does not look like an 
horrible contraption for each version.

I have on my immediate todo list to generate a list of files where changes are 
needed on what is the status for each file as you proposed in a tracker issue.

Regards,
-- 
José Abílio

Re: [patch] better color support in character dialog

[Richard Heck]

On 05/12/2015 07:08 PM, Uwe Stöhr wrote:

Dear LyXers,

it annoyed me a long time that LyX does only provide the most basic 
colors in the character dialog and that these colors are not even 
displayed there.
(For example I use the color "lime" quite frequently and had therefore 
to use TeX code.)


I thought about this and offering all possible rgb colors would be a 
nightmare because this will pollute the TeX output with color 
definitions and a strength of TeX is to provide a well-structured 
output. So providing only a basic set of colors makes sense.
Since we support the package xcolor for a long time we could expand 
our color list with the standard fonts of xcolor.


This is done in the attached patch. The patch also displays the colors 
in the dialog. It contains also the necessary tex2lyx changes. I will 
of course add lyx2lyx when going on.


OK to go on?


Seems reasonable enough to me.

Check for whitespace errors here:


diff --git a/src/frontends/qt4/GuiPrefs.cpp b/src/frontends/qt4/GuiPrefs.cpp
index 995f8fa..7c5f236 100644
--- a/src/frontends/qt4/GuiPrefs.cpp
+++ b/src/frontends/qt4/GuiPrefs.cpp
@@ -1121,11 +1121,22 @@ PrefColors::PrefColors(GuiPreferences * form)
if (lc == Color_none
|| lc == Color_black
|| lc == Color_white
-   || lc == Color_red
+   || lc == Color_blue
+   || lc == Color_brown
+   || lc == Color_cyan
+   || lc == Color_darkgray
+   || lc == Color_gray
|| lc == Color_green
-   || lc == Color_blue
-   || lc == Color_cyan
+   || lc == Color_lightgray
+   || lc == Color_lime
|| lc == Color_magenta
+   || lc == Color_olive
+   || lc == Color_orange
+   || lc == Color_pink
+   || lc == Color_purple
+   || lc == Color_red
+   || lc == Color_teal
+   || lc == Color_violet
|| lc == Color_yellow
|| lc == Color_inherit
|| lc == Color_ignore)



rh

Re: 2.2

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
>
> Hi there,
>
> The ritual question: what is still needed for 2.2?

- how far from finished status is epub support (Richard?)
- is there some some progress on lyx-odt project (Stefano?)

Pavel

ui: Setting a vertical size policy

[Scott Kostyshak]

In View > Messages Pane, I would like to improve the vertical size
policy such that the text of the radio buttons is not truncated at the
minimum height, as it is in the attached screenshot.

Does anyone know the correct way to do this? I can succeed if I
hardcode a height, but that does not seem like a good idea.

Scott

math macro crashes again (bug 9490)

[Georg Baum]

Hi,

after a lot of debugging I understand now what happens in 
http://www.lyx.org/trac/ticket/9490. As you may recall, the last math macro 
crash I fixed (9418) was caused by a broken ArgumentProxy::mathMacro_ 
pointer. At that time, I assumed that the only place where an ArgumentProxy 
can occur is as an element of MathMacro::d->expanded_ (which is also 
indicated by the comment in ArgumentProxy::draw(). Under this assumption, 
the fix for 9418 would have fixed all cases of invalid mathMacro_ pointers.

However, this assumption is not true. In MathData::detachMacroParameters(), 
elements of MathMacro::d->expanded_ can be extracted and put into the same 
vector as the macro itself. Unfortunately, if you insert an element into a 
vector, the existing elements may be copied => pointers may become invalid. 
The fix for 9419 does not work for this case, since the ArgumentProxy 
instances in question are already extracted from the macro and stored in the 
local variable detachedArgs.

It would be relatively easy to do a local fix in 
MathData::detachMacroParameters(). However, since the detached ArgumentProxy 
instances stay alive after leaving MathData::detachMacroParameters(), this 
is not enough.

I tried to keep a record of each ArgumentProxy child in a new member of the 
MathMacro itself. Then ArgumentProxy::setOwner() can be called reliably 
whenever a copy of a MathMacro is made. This works fine, but exposes another 
problem: When following the recipe of bug 9490, a MathMacro instance is 
deleted in Undo::Private::doTextUndoOrRedo() while an ArgumentProxy pointing 
to it is still alive.

What to do now? I don't know. I see the following options:

- Change the base class of MathData to RandomAccessList as proposed by Abdel 
in the discussion of 9419. This would solve the invalid pointer problems, 
but not the problem showed by the undo stack, and I fear that more hidden 
problems like this one exist. To me it is now more clear than during the 
discussion of 9418 that the "self-contained" property of a MathInset is 
really really important and assumed implicitly all over the place. The 
ArgumentProxy is not self-contained, and this is the root of all evil.

- Get rid of MathData::detachMacroParameters(). This would be a feature 
regression: Unfolding a math macro would no longer be possible. Is this an 
important feature?

- Rewrite ArgumentProxy to get rid of the mathMacro_ pointer (or even get 
rid of the class ArgumentProxy). This is a big task.


Any other ideas? Preferences? Unless somebody has a brilliant idea I tend 
towards the second item, since the first does not solve all problems, and 
the last is too much work for me ATM.



Georg

Re: 2.2

[Stephan Witt]

Am 13.05.2015 um 10:42 schrieb Jean-Marc Lasgouttes :

> 
> Hi there,
> 
> The ritual question: what is still needed for 2.2?

The patch I've sent to list on Fri, Mar 20, 2015 at 10:15:18AM +0100, named
0001-svg-hidpi-on-mac.patch is not applied already.

It is needed - but I didn't do it until now because it breaks the rendering of 
the
splash image (the BackgroundWidget of GuiView) and I got distracted from 
solving this.

Stephan

> 
> I guess we are still waiting for some python 3.3 goodness from José, but what 
> else?
> 
> It seems to me that publishing a beta version soon is very desirable. 
> Consider that for 2.1 we had 8 months between first beta and 2.1 release.
> 
> Vincent, are you still our release manager, or are your other management 
> duties still interfering? I like the way you force us to fix every detail 
> before release, I think this is needed.
> 
> JMarc
> 

Re: math macro crashes again (bug 9490)

[Guillaume M-M]

On 05/13/15 21:34, Georg Baum wrote:

Hi,

after a lot of debugging I understand now what happens in
http://www.lyx.org/trac/ticket/9490. As you may recall, the last math macro
crash I fixed (9418) was caused by a broken ArgumentProxy::mathMacro_
pointer. At that time, I assumed that the only place where an ArgumentProxy
can occur is as an element of MathMacro::d->expanded_ (which is also
indicated by the comment in ArgumentProxy::draw(). Under this assumption,
the fix for 9418 would have fixed all cases of invalid mathMacro_ pointers.

However, this assumption is not true. In MathData::detachMacroParameters(),
elements of MathMacro::d->expanded_ can be extracted and put into the same
vector as the macro itself. Unfortunately, if you insert an element into a
vector, the existing elements may be copied => pointers may become invalid.
The fix for 9419 does not work for this case, since the ArgumentProxy
instances in question are already extracted from the macro and stored in the
local variable detachedArgs.

It would be relatively easy to do a local fix in
MathData::detachMacroParameters(). However, since the detached ArgumentProxy
instances stay alive after leaving MathData::detachMacroParameters(), this
is not enough.

I tried to keep a record of each ArgumentProxy child in a new member of the
MathMacro itself. Then ArgumentProxy::setOwner() can be called reliably
whenever a copy of a MathMacro is made. This works fine, but exposes another
problem: When following the recipe of bug 9490, a MathMacro instance is
deleted in Undo::Private::doTextUndoOrRedo() while an ArgumentProxy pointing
to it is still alive.

What to do now? I don't know. I see the following options:

- Change the base class of MathData to RandomAccessList as proposed by Abdel
in the discussion of 9419. This would solve the invalid pointer problems,
but not the problem showed by the undo stack, and I fear that more hidden
problems like this one exist. To me it is now more clear than during the
discussion of 9418 that the "self-contained" property of a MathInset is
really really important and assumed implicitly all over the place. The
ArgumentProxy is not self-contained, and this is the root of all evil.

- Get rid of MathData::detachMacroParameters(). This would be a feature
regression: Unfolding a math macro would no longer be possible. Is this an
important feature?

- Rewrite ArgumentProxy to get rid of the mathMacro_ pointer (or even get
rid of the class ArgumentProxy). This is a big task.


Any other ideas? Preferences? Unless somebody has a brilliant idea I tend
towards the second item, since the first does not solve all problems, and
the last is too much work for me ATM.



Georg





Dear Georg,


Thank you for looking at these bugs. I reported 9418 and 9490, and I use 
macro unfolding quite often. Before discovering this feature, I would 
occasionally edit the lyx file externally (!) to change certain macros. 
Given that the original bug was about a crash occurring during 
unfolding, the second solution is a bit like curing a pain by amputation...


I would really appreciate a long-term solution to the math macro bugs. 
It would be useful to know whether many other people had segmentation 
faults because of macros, because I suspect that these crashes have been 
under-reported due to how hard they were to reproduce.


Thank you again for the hard work.


Best,
Guillaume

Re: ui: Setting a vertical size policy

[Pavel Sanda]

Scott Kostyshak wrote:
> In View > Messages Pane, I would like to improve the vertical size
> policy such that the text of the radio buttons is not truncated at the
> minimum height, as it is in the attached screenshot.

I can't reproduce your screenshot here (qt 4.8.5).

> Does anyone know the correct way to do this? I can succeed if I
> hardcode a height, but that does not seem like a good idea.

Hardcoding vertical size? If I use different font or qt theme on my system then 
it will break.
Size policies should fix that, but I remember getting quite a headache from 
trying to fix
this dialog so the vertical size does not get way too big ;)

Pavel