Re: LyX 2.0 release plan

[Jürgen Spitzmüller]

Jean-Marc Lasgouttes wrote:
 I thought my apathy would be enough to have Juergen do it, but he won.

I'm making progress, you know ...

Jürgen

Re: LyX 2.0 release plan

[Jürgen Spitzmüller]

Jean-Marc Lasgouttes wrote:
> I thought my apathy would be enough to have Juergen do it, but he won.

I'm making progress, you know ...

Jürgen

Re: LyX 2.0 release plan

[Jean-Marc Lasgouttes]

Le 29 mars 10 à 00:58, Pavel Sanda a écrit :

Pavel Sanda wrote:
I'll go through the enh bugs with 2.0 target and leave only those  
which are
really to be included. For this I need somebody create two new  
milestones in

trac for postponing - 2.1.0  2.0.1.


ding ding dong dong ;)



Done.

I thought my apathy would be enough to have Juergen do it, but he won.

JMarc

Re: LyX 2.0 release plan

[Jean-Marc Lasgouttes]

Le 29 mars 10 à 00:58, Pavel Sanda a écrit :

Pavel Sanda wrote:
I'll go through the enh bugs with 2.0 target and leave only those  
which are
really to be included. For this I need somebody create two new  
milestones in

trac for postponing - 2.1.0 & 2.0.1.


ding ding dong dong ;)



Done.

I thought my apathy would be enough to have Juergen do it, but he won.

JMarc

Re: LyX 2.0 release plan

[Jean-Marc Lasgouttes]

Le 10/03/2010 23:39, Abdelrazak Younes a écrit :

The problem is that it modifies stuff outside of the cell itself.


Such as?

Vincent made the same argument but I fail to see where this is true. For
longtable, we iterate through the rows and the collumns to see if header
of firstheader is set. For border, each cell is independent,
set-all-lines will loop over all cells of a row.


And so if one invokes set-all-lines the changes are outside of the cell 
parameters, right? I have to admit I do not know well this tabular stuff.


JMarc

Re: LyX 2.0 release plan

[Jean-Marc Lasgouttes]

Le 10/03/2010 23:39, Abdelrazak Younes a écrit :

The problem is that it modifies stuff outside of the cell itself.


Such as?

Vincent made the same argument but I fail to see where this is true. For
longtable, we iterate through the rows and the collumns to see if header
of firstheader is set. For border, each cell is independent,
set-all-lines will loop over all cells of a row.


And so if one invokes set-all-lines the changes are outside of the cell 
parameters, right? I have to admit I do not know well this tabular stuff.


JMarc

Re: LyX 2.0 release plan

[Abdelrazak Younes]

On 03/09/2010 10:47 PM, Jean-Marc Lasgouttes wrote:

Le 09/03/2010 20:11, Pavel Sanda a écrit :
ah, thats part of the AtPoint discussion... unfortunately there seems 
to be no

easy fix right now.


Just cerate inset-type change to replace the uses of inset-modify...


Well this whole issue is because I made the opposite change...
I still think this is a good move because I really don't like to have to 
create a new LFUN for each and every inset. Also because when the use of 
user defined insets can be generalized then inset-modify could work 
straight away.


So we should IMHO fix the issue in Cursor::getStatus() rather than go 
backward.




For some reason I do not manage to get svn access here. It is a pity
since otherwise sitting in front of the Mont Blanc is fine. I even had 
a talk in which a co-author is Alfredo Braunstein :)


Hello Alfredo!

Abdel.

Re: LyX 2.0 release plan

[rgheck]

On 03/10/2010 03:00 AM, Abdelrazak Younes wrote:

On 03/09/2010 10:47 PM, Jean-Marc Lasgouttes wrote:

Le 09/03/2010 20:11, Pavel Sanda a écrit :
ah, thats part of the AtPoint discussion... unfortunately there 
seems to be no

easy fix right now.


Just cerate inset-type change to replace the uses of inset-modify...


Well this whole issue is because I made the opposite change...
I still think this is a good move because I really don't like to have 
to create a new LFUN for each and every inset. Also because when the 
use of user defined insets can be generalized then inset-modify could 
work straight away.


So we should IMHO fix the issue in Cursor::getStatus() rather than go 
backward.


If the issue is that InsetTabular thinks it has to have the cursor 
inside it to apply the LFUN, can't we change how that works? I.e., can't 
we move the cursor in there, or re-write the routine so it doesn't need 
to assume that?


rh

Re: LyX 2.0 release plan

[Jean-Marc Lasgouttes]

Le 10/03/2010 13:33, rgheck a écrit :

On 03/10/2010 03:00 AM, Abdelrazak Younes wrote:

I still think this is a good move because I really don't like to have
to create a new LFUN for each and every inset. Also because when the
use of user defined insets can be generalized then inset-modify could
work straight away.


Except that in the long run we should generalize the notion of type or 
subtype for insets in order to be able to manage that in a centralized 
way. This would be useful for inset style names too. It would make sense 
to me that each inset has a name (float) and some of them have a type 
(figure).



So we should IMHO fix the issue in Cursor::getStatus() rather than go
backward.


If the issue is that InsetTabular thinks it has to have the cursor
inside it to apply the LFUN, can't we change how that works? I.e., can't
we move the cursor in there, or re-write the routine so it doesn't need
to assume that?


Hmm, what is the particular bug we want to fix here?

JMarc

RE: LyX 2.0 release plan

[Vincent van Ravesteijn - TNW]

 If the issue is that InsetTabular thinks it has to have the cursor 
 inside it to apply the LFUN, can't we change how that works? I.e., 
 can't we move the cursor in there, or re-write the routine so it 
 doesn't need to assume that?

Hmm, what is the particular bug we want to fix here?

Jmarc


The one below:

other bug you would like to see killed?

Insert a table, put the cursor in front of the table, press set all
lines on the table toolbar.. Crash.

Vincent



Vincent

Re: LyX 2.0 release plan

[Jean-Marc Lasgouttes]

Le 10/03/2010 09:00, Abdelrazak Younes a écrit :

Well this whole issue is because I made the opposite change...
I still think this is a good move because I really don't like to have to
create a new LFUN for each and every inset. Also because when the use of
user defined insets can be generalized then inset-modify could work
straight away.


The problem, as I see it, is that inset-modify is really 
inset-params-modify. It does not require any cursor position, because it 
acts on the global parameters of the inset. In this sense it is 
particularly relevant to use the AtPoint flag.


Tabular features are different, since they depend on the cursor 
position. In this sense, they should not be handled via inset-modify.
A possibility would be to handle this in InsetTableCell::dispatch, but I 
am not sure this make lots of sense.


So my new proposal would be to keep inset-modify as it is (or rename it) 
and recreate the tabular-feature lfun, since it is such a special beast.


JMarc

Re: LyX 2.0 release plan

[Jean-Marc Lasgouttes]

Le 10/03/2010 13:52, Vincent van Ravesteijn - TNW a écrit :

The one below:


other bug you would like to see killed?


Insert a table, put the cursor in front of the table, press set all
lines on the table toolbar.. Crash.


But this one is fixed now, isn't it? I mean, we worked around it :)

JMarc

Re: LyX 2.0 release plan

[Abdelrazak Younes]

On 10/03/2010 23:14, Jean-Marc Lasgouttes wrote:

Le 10/03/2010 13:52, Vincent van Ravesteijn - TNW a écrit :

The one below:


other bug you would like to see killed?


Insert a table, put the cursor in front of the table, press set all
lines on the table toolbar.. Crash.


But this one is fixed now, isn't it? I mean, we worked around it :)


Yes, Edwin did. And I also did something similar in InsetMathGrid IIRC.

Abdel.

Re: LyX 2.0 release plan

[Jean-Marc Lasgouttes]

Le 10/03/2010 23:15, Abdelrazak Younes a écrit :

But this one is fixed now, isn't it? I mean, we worked around it :)


Yes, Edwin did. And I also did something similar in InsetMathGrid IIRC.


OK, thanks.

JMarc

Re: LyX 2.0 release plan

[Abdelrazak Younes]

On 10/03/2010 23:09, Jean-Marc Lasgouttes wrote:

Le 10/03/2010 09:00, Abdelrazak Younes a écrit :

Well this whole issue is because I made the opposite change...
I still think this is a good move because I really don't like to have to
create a new LFUN for each and every inset. Also because when the use of
user defined insets can be generalized then inset-modify could work
straight away.


The problem, as I see it, is that inset-modify is really 
inset-params-modify. It does not require any cursor position, because 
it acts on the global parameters of the inset. In this sense it is 
particularly relevant to use the AtPoint flag.


Tabular features are different, since they depend on the cursor 
position. In this sense, they should not be handled via inset-modify.


Well, it does modify the inset so it's OK to have it in there.
But I agree about the distinction beween inset-modify and 
inset-params-modify. Basically inset-modify should be about modifying 
the content (and can depend on the Cursor position) and 
inset-params-modify should be about modifying the parameter of the 
inset, without touching the contents.


A possibility would be to handle this in InsetTableCell::dispatch, but 
I am not sure this make lots of sense.


I think it does.



So my new proposal would be to keep inset-modify as it is (or rename 
it) and recreate the tabular-feature lfun, since it is such a special 
beast.


Let's discuss this a bit more. The immediate bugs are fixed for now.

Abdel.

Re: LyX 2.0 release plan

[Jean-Marc Lasgouttes]

Le 10/03/2010 23:20, Abdelrazak Younes a écrit :

Well, it does modify the inset so it's OK to have it in there.
But I agree about the distinction beween inset-modify and
inset-params-modify. Basically inset-modify should be about modifying
the content (and can depend on the Cursor position) and
inset-params-modify should be about modifying the parameter of the
inset, without touching the contents.


Except that I am not sure that inset-modify will be able to have common 
enough semantics to be a single function. In the furute, 
inset-params-modify will just set the parameters like in the xml format:

  inset-param-modify insetname param1=val1 param2=val2
and the code will be in one nice place, and be used also for file reading.

I do not see such a nice scheme emerging for your inset-modify.


A possibility would be to handle this in InsetTableCell::dispatch, but
I am not sure this make lots of sense.


I think it does.


The problem is that it modifies stuff outside of the cell itself.

JMarc

Re: LyX 2.0 release plan

[Abdelrazak Younes]

On 10/03/2010 23:27, Jean-Marc Lasgouttes wrote:

Le 10/03/2010 23:20, Abdelrazak Younes a écrit :

Well, it does modify the inset so it's OK to have it in there.
But I agree about the distinction beween inset-modify and
inset-params-modify. Basically inset-modify should be about modifying
the content (and can depend on the Cursor position) and
inset-params-modify should be about modifying the parameter of the
inset, without touching the contents.


Except that I am not sure that inset-modify will be able to have 
common enough semantics to be a single function. In the furute, 
inset-params-modify will just set the parameters like in the xml format:

  inset-param-modify insetname param1=val1 param2=val2
and the code will be in one nice place, and be used also for file 
reading.


I do not see such a nice scheme emerging for your inset-modify.


A possibility would be to handle this in InsetTableCell::dispatch, but
I am not sure this make lots of sense.


I think it does.


The problem is that it modifies stuff outside of the cell itself.


Such as?

Vincent made the same argument but I fail to see where this is true. For 
longtable, we iterate through the rows and the collumns to see if header 
of firstheader is set. For border, each cell is independent, 
set-all-lines will loop over all cells of a row.


Abdel.

Re: LyX 2.0 release plan

[Abdelrazak Younes]

On 03/09/2010 10:47 PM, Jean-Marc Lasgouttes wrote:

Le 09/03/2010 20:11, Pavel Sanda a écrit :
ah, thats part of the AtPoint discussion... unfortunately there seems 
to be no

easy fix right now.


Just cerate inset-type change to replace the uses of inset-modify...


Well this whole issue is because I made the opposite change...
I still think this is a good move because I really don't like to have to 
create a new LFUN for each and every inset. Also because when the use of 
user defined insets can be generalized then inset-modify could work 
straight away.


So we should IMHO fix the issue in Cursor::getStatus() rather than go 
backward.




For some reason I do not manage to get svn access here. It is a pity
since otherwise sitting in front of the Mont Blanc is fine. I even had 
a talk in which a co-author is Alfredo Braunstein :)


Hello Alfredo!

Abdel.

Re: LyX 2.0 release plan

[rgheck]

On 03/10/2010 03:00 AM, Abdelrazak Younes wrote:

On 03/09/2010 10:47 PM, Jean-Marc Lasgouttes wrote:

Le 09/03/2010 20:11, Pavel Sanda a écrit :
ah, thats part of the AtPoint discussion... unfortunately there 
seems to be no

easy fix right now.


Just cerate inset-type change to replace the uses of inset-modify...


Well this whole issue is because I made the opposite change...
I still think this is a good move because I really don't like to have 
to create a new LFUN for each and every inset. Also because when the 
use of user defined insets can be generalized then inset-modify could 
work straight away.


So we should IMHO fix the issue in Cursor::getStatus() rather than go 
backward.


If the issue is that InsetTabular thinks it has to have the cursor 
inside it to apply the LFUN, can't we change how that works? I.e., can't 
we move the cursor in there, or re-write the routine so it doesn't need 
to assume that?


rh

Re: LyX 2.0 release plan

[Jean-Marc Lasgouttes]

Le 10/03/2010 13:33, rgheck a écrit :

On 03/10/2010 03:00 AM, Abdelrazak Younes wrote:

I still think this is a good move because I really don't like to have
to create a new LFUN for each and every inset. Also because when the
use of user defined insets can be generalized then inset-modify could
work straight away.


Except that in the long run we should generalize the notion of type or 
subtype for insets in order to be able to manage that in a centralized 
way. This would be useful for inset style names too. It would make sense 
to me that each inset has a name ("float") and some of them have a type 
("figure").



So we should IMHO fix the issue in Cursor::getStatus() rather than go
backward.


If the issue is that InsetTabular thinks it has to have the cursor
inside it to apply the LFUN, can't we change how that works? I.e., can't
we move the cursor in there, or re-write the routine so it doesn't need
to assume that?


Hmm, what is the particular bug we want to fix here?

JMarc

RE: LyX 2.0 release plan

[Vincent van Ravesteijn - TNW]

>> If the issue is that InsetTabular thinks it has to have the cursor 
>> inside it to apply the LFUN, can't we change how that works? I.e., 
>> can't we move the cursor in there, or re-write the routine so it 
>> doesn't need to assume that?
>
>Hmm, what is the particular bug we want to fix here?
>
>Jmarc
>

The one below:

>>other bug you would like to see killed?
>
>Insert a table, put the cursor in front of the table, press set all
lines on the table toolbar.. Crash.
>
>Vincent
>


Vincent

Re: LyX 2.0 release plan

[Jean-Marc Lasgouttes]

Le 10/03/2010 09:00, Abdelrazak Younes a écrit :

Well this whole issue is because I made the opposite change...
I still think this is a good move because I really don't like to have to
create a new LFUN for each and every inset. Also because when the use of
user defined insets can be generalized then inset-modify could work
straight away.


The problem, as I see it, is that inset-modify is really 
inset-params-modify. It does not require any cursor position, because it 
acts on the global parameters of the inset. In this sense it is 
particularly relevant to use the AtPoint flag.


Tabular features are different, since they depend on the cursor 
position. In this sense, they should not be handled via inset-modify.
A possibility would be to handle this in InsetTableCell::dispatch, but I 
am not sure this make lots of sense.


So my new proposal would be to keep inset-modify as it is (or rename it) 
and recreate the tabular-feature lfun, since it is such a special beast.


JMarc

Re: LyX 2.0 release plan

[Jean-Marc Lasgouttes]

Le 10/03/2010 13:52, Vincent van Ravesteijn - TNW a écrit :

The one below:


other bug you would like to see killed?


Insert a table, put the cursor in front of the table, press set all
lines on the table toolbar.. Crash.


But this one is fixed now, isn't it? I mean, we worked around it :)

JMarc

Re: LyX 2.0 release plan

[Abdelrazak Younes]

On 10/03/2010 23:14, Jean-Marc Lasgouttes wrote:

Le 10/03/2010 13:52, Vincent van Ravesteijn - TNW a écrit :

The one below:


other bug you would like to see killed?


Insert a table, put the cursor in front of the table, press set all
lines on the table toolbar.. Crash.


But this one is fixed now, isn't it? I mean, we worked around it :)


Yes, Edwin did. And I also did something similar in InsetMathGrid IIRC.

Abdel.

Re: LyX 2.0 release plan

[Jean-Marc Lasgouttes]

Le 10/03/2010 23:15, Abdelrazak Younes a écrit :

But this one is fixed now, isn't it? I mean, we worked around it :)


Yes, Edwin did. And I also did something similar in InsetMathGrid IIRC.


OK, thanks.

JMarc

Re: LyX 2.0 release plan

[Abdelrazak Younes]

On 10/03/2010 23:09, Jean-Marc Lasgouttes wrote:

Le 10/03/2010 09:00, Abdelrazak Younes a écrit :

Well this whole issue is because I made the opposite change...
I still think this is a good move because I really don't like to have to
create a new LFUN for each and every inset. Also because when the use of
user defined insets can be generalized then inset-modify could work
straight away.


The problem, as I see it, is that inset-modify is really 
inset-params-modify. It does not require any cursor position, because 
it acts on the global parameters of the inset. In this sense it is 
particularly relevant to use the AtPoint flag.


Tabular features are different, since they depend on the cursor 
position. In this sense, they should not be handled via inset-modify.


Well, it does modify the inset so it's OK to have it in there.
But I agree about the distinction beween inset-modify and 
inset-params-modify. Basically inset-modify should be about modifying 
the content (and can depend on the Cursor position) and 
inset-params-modify should be about modifying the parameter of the 
inset, without touching the contents.


A possibility would be to handle this in InsetTableCell::dispatch, but 
I am not sure this make lots of sense.


I think it does.



So my new proposal would be to keep inset-modify as it is (or rename 
it) and recreate the tabular-feature lfun, since it is such a special 
beast.


Let's discuss this a bit more. The immediate bugs are fixed for now.

Abdel.

Re: LyX 2.0 release plan

[Jean-Marc Lasgouttes]

Le 10/03/2010 23:20, Abdelrazak Younes a écrit :

Well, it does modify the inset so it's OK to have it in there.
But I agree about the distinction beween inset-modify and
inset-params-modify. Basically inset-modify should be about modifying
the content (and can depend on the Cursor position) and
inset-params-modify should be about modifying the parameter of the
inset, without touching the contents.


Except that I am not sure that inset-modify will be able to have common 
enough semantics to be a single function. In the furute, 
inset-params-modify will just set the parameters like in the xml format:

  inset-param-modify insetname param1=val1 param2=val2
and the code will be in one nice place, and be used also for file reading.

I do not see such a nice scheme emerging for your inset-modify.


A possibility would be to handle this in InsetTableCell::dispatch, but
I am not sure this make lots of sense.


I think it does.


The problem is that it modifies stuff outside of the cell itself.

JMarc

Re: LyX 2.0 release plan

[Abdelrazak Younes]

On 10/03/2010 23:27, Jean-Marc Lasgouttes wrote:

Le 10/03/2010 23:20, Abdelrazak Younes a écrit :

Well, it does modify the inset so it's OK to have it in there.
But I agree about the distinction beween inset-modify and
inset-params-modify. Basically inset-modify should be about modifying
the content (and can depend on the Cursor position) and
inset-params-modify should be about modifying the parameter of the
inset, without touching the contents.


Except that I am not sure that inset-modify will be able to have 
common enough semantics to be a single function. In the furute, 
inset-params-modify will just set the parameters like in the xml format:

  inset-param-modify insetname param1=val1 param2=val2
and the code will be in one nice place, and be used also for file 
reading.


I do not see such a nice scheme emerging for your inset-modify.


A possibility would be to handle this in InsetTableCell::dispatch, but
I am not sure this make lots of sense.


I think it does.


The problem is that it modifies stuff outside of the cell itself.


Such as?

Vincent made the same argument but I fail to see where this is true. For 
longtable, we iterate through the rows and the collumns to see if header 
of firstheader is set. For border, each cell is independent, 
set-all-lines will loop over all cells of a row.


Abdel.

Re: LyX 2.0 release plan

[Jürgen Spitzmüller]

Pavel Sanda wrote:
   The error dialog is currently completely broken (it doesn't show at
   all). I  think this is a pretty nasty bug.
 
 any news about this one?

No. But I think this one is also due to the buffer cloning.

Jürgen

Re: LyX 2.0 release plan

[Abdelrazak Younes]

On 03/09/2010 04:11 PM, rgheck wrote:

On 03/09/2010 10:07 AM, Jürgen Spitzmüller wrote:

Pavel Sanda wrote:

The error dialog is currently completely broken (it doesn't show at
all). I  think this is a pretty nasty bug.

any news about this one?

No. But I think this one is also due to the buffer cloning.


Probably.


Definitely.

I remember writing in some commit logs that this need fixing but I never 
managed to come back to this unfortunately.


Abdel.

Re: LyX 2.0 release plan

[Pavel Sanda]

Vincent van Ravesteijn - TNW wrote:
 other bug you would like to see killed?
 
 Insert a table, put the cursor in front of the table, press set all
 lines on the table toolbar.. Crash.

table guys? Ed, Uwe?
pavel

Re: LyX 2.0 release plan

[rgheck]

On 03/09/2010 10:07 AM, Jürgen Spitzmüller wrote:

Pavel Sanda wrote:
   

The error dialog is currently completely broken (it doesn't show at
all). I  think this is a pretty nasty bug.
 

any news about this one?
 

No. But I think this one is also due to the buffer cloning.

   

Probably.

rh

Re: LyX 2.0 release plan

[Pavel Sanda]

Pavel Sanda wrote:
 Jürgen Spitzmüller wrote:
  Pavel Sanda wrote:
   other bug you would like to see killed?
  
  The error dialog is currently completely broken (it doesn't show at all). I 
  think this is a pretty nasty bug.

any news about this one?
pavel

Re: LyX 2.0 release plan

[Edwin Leuven]

Pavel Sanda wrote:

Vincent van Ravesteijn - TNW wrote:

other bug you would like to see killed?

Insert a table, put the cursor in front of the table, press set all
lines on the table toolbar.. Crash.


table guys? Ed, Uwe?


because with the cursor in front of a tabular, 'inset' in the code below 
points to the tabular, the toolbar buttons get enabled, clicking them 
calls a function but we are not in the correct inset. boom.


?


bool Cursor::getStatus(FuncRequest const  cmd, FuncStatus  status) const
{
Cursor cur = *this;

// Try to fix cursor in case it is broken.
cur.fixIfBroken();

// Is this a function that acts on inset at point?
Inset * inset = cur.nextInset();
if (lyxaction.funcHasFlag(cmd.action, LyXAction::AtPoint)
 inset  inset-getStatus(cur, cmd, status))
return true;

...

Re: LyX 2.0 release plan

[rgheck]

On 03/09/2010 01:59 PM, Edwin Leuven wrote:

Pavel Sanda wrote:

Vincent van Ravesteijn - TNW wrote:

other bug you would like to see killed?

Insert a table, put the cursor in front of the table, press set all
lines on the table toolbar.. Crash.


table guys? Ed, Uwe?


because with the cursor in front of a tabular, 'inset' in the code 
below points to the tabular, the toolbar buttons get enabled, clicking 
them calls a function but we are not in the correct inset. boom.


?


bool Cursor::getStatus(FuncRequest const  cmd, FuncStatus  status) 
const

{
Cursor cur = *this;

// Try to fix cursor in case it is broken.
cur.fixIfBroken();

// Is this a function that acts on inset at point?
Inset * inset = cur.nextInset();
if (lyxaction.funcHasFlag(cmd.action, LyXAction::AtPoint)
 inset  inset-getStatus(cur, cmd, status))
return true;

Do we need then to remove the AtPoint feature from whatever LFUN this 
is? What that means is precisely: You can apply this LFUN when not in 
the inset but in front of it.


rh

Re: LyX 2.0 release plan

[Pavel Sanda]

Edwin Leuven wrote:
 Pavel Sanda wrote:
 Vincent van Ravesteijn - TNW wrote:
 other bug you would like to see killed?
 Insert a table, put the cursor in front of the table, press set all
 lines on the table toolbar.. Crash.
 table guys? Ed, Uwe?

 because with the cursor in front of a tabular, 'inset' in the code below 
 points to the tabular, the toolbar buttons get enabled, clicking them calls 
 a function but we are not in the correct inset. boom.

ah, thats part of the AtPoint discussion... unfortunately there seems to be no
easy fix right now.
pavel

Re: LyX 2.0 release plan

[Edwin Leuven]

rgheck wrote:
Do we need then to remove the AtPoint feature from whatever LFUN this 
is?


i think we can't because it is LFUN_INSET_MODIFY

What that means is precisely: You can apply this LFUN when not in 
the inset but in front of it.


but for tabular functions the cursor need to be in the table

to avoid the crash i committed this

http://www.lyx.org/trac/changeset/33687

Re: LyX 2.0 release plan

[rgheck]

On 03/09/2010 02:12 PM, Edwin Leuven wrote:

rgheck wrote:
Do we need then to remove the AtPoint feature from whatever LFUN this 
is?


i think we can't because it is LFUN_INSET_MODIFY


Ah, yes. That issue.

rh

Re: LyX 2.0 release plan

[Jean-Marc Lasgouttes]

Le 09/03/2010 20:11, Pavel Sanda a écrit :

ah, thats part of the AtPoint discussion... unfortunately there seems to be no
easy fix right now.


Just cerate inset-type change to replace the uses of inset-modify... For 
some reason I do not manage to get svn access here. It is a pity
since otherwise sitting in front of the Mont Blanc is fine. I even had a 
talk in which a co-author is Alfredo Braunstein :)


JMarc

Re: LyX 2.0 release plan

[Jürgen Spitzmüller]

Pavel Sanda wrote:
> > > The error dialog is currently completely broken (it doesn't show at
> > > all). I  think this is a pretty nasty bug.
> 
> any news about this one?

No. But I think this one is also due to the buffer cloning.

Jürgen

Re: LyX 2.0 release plan

[Abdelrazak Younes]

On 03/09/2010 04:11 PM, rgheck wrote:

On 03/09/2010 10:07 AM, Jürgen Spitzmüller wrote:

Pavel Sanda wrote:

The error dialog is currently completely broken (it doesn't show at
all). I  think this is a pretty nasty bug.

any news about this one?

No. But I think this one is also due to the buffer cloning.


Probably.


Definitely.

I remember writing in some commit logs that this need fixing but I never 
managed to come back to this unfortunately.


Abdel.

Re: LyX 2.0 release plan

[Pavel Sanda]

Vincent van Ravesteijn - TNW wrote:
> >other bug you would like to see killed?
> 
> Insert a table, put the cursor in front of the table, press set all
> lines on the table toolbar.. Crash.

table guys? Ed, Uwe?
pavel

Re: LyX 2.0 release plan

[rgheck]

On 03/09/2010 10:07 AM, Jürgen Spitzmüller wrote:

Pavel Sanda wrote:
   

The error dialog is currently completely broken (it doesn't show at
all). I  think this is a pretty nasty bug.
 

any news about this one?
 

No. But I think this one is also due to the buffer cloning.

   

Probably.

rh

Re: LyX 2.0 release plan

[Pavel Sanda]

Pavel Sanda wrote:
> Jürgen Spitzmüller wrote:
> > Pavel Sanda wrote:
> > > other bug you would like to see killed?
> > 
> > The error dialog is currently completely broken (it doesn't show at all). I 
> > think this is a pretty nasty bug.

any news about this one?
pavel

Re: LyX 2.0 release plan

[Edwin Leuven]

Pavel Sanda wrote:

Vincent van Ravesteijn - TNW wrote:

other bug you would like to see killed?

Insert a table, put the cursor in front of the table, press set all
lines on the table toolbar.. Crash.


table guys? Ed, Uwe?


because with the cursor in front of a tabular, 'inset' in the code below 
points to the tabular, the toolbar buttons get enabled, clicking them 
calls a function but we are not in the correct inset. boom.


?


bool Cursor::getStatus(FuncRequest const & cmd, FuncStatus & status) const
{
Cursor cur = *this;

// Try to fix cursor in case it is broken.
cur.fixIfBroken();

// Is this a function that acts on inset at point?
Inset * inset = cur.nextInset();
if (lyxaction.funcHasFlag(cmd.action, LyXAction::AtPoint)
&& inset && inset->getStatus(cur, cmd, status))
return true;

...

Re: LyX 2.0 release plan

[rgheck]

On 03/09/2010 01:59 PM, Edwin Leuven wrote:

Pavel Sanda wrote:

Vincent van Ravesteijn - TNW wrote:

other bug you would like to see killed?

Insert a table, put the cursor in front of the table, press set all
lines on the table toolbar.. Crash.


table guys? Ed, Uwe?


because with the cursor in front of a tabular, 'inset' in the code 
below points to the tabular, the toolbar buttons get enabled, clicking 
them calls a function but we are not in the correct inset. boom.


?


bool Cursor::getStatus(FuncRequest const & cmd, FuncStatus & status) 
const

{
Cursor cur = *this;

// Try to fix cursor in case it is broken.
cur.fixIfBroken();

// Is this a function that acts on inset at point?
Inset * inset = cur.nextInset();
if (lyxaction.funcHasFlag(cmd.action, LyXAction::AtPoint)
&& inset && inset->getStatus(cur, cmd, status))
return true;

Do we need then to remove the AtPoint feature from whatever LFUN this 
is? What that means is precisely: You can apply this LFUN when not in 
the inset but in front of it.


rh

Re: LyX 2.0 release plan

[Pavel Sanda]

Edwin Leuven wrote:
> Pavel Sanda wrote:
>> Vincent van Ravesteijn - TNW wrote:
 other bug you would like to see killed?
>>> Insert a table, put the cursor in front of the table, press set all
>>> lines on the table toolbar.. Crash.
>> table guys? Ed, Uwe?
>
> because with the cursor in front of a tabular, 'inset' in the code below 
> points to the tabular, the toolbar buttons get enabled, clicking them calls 
> a function but we are not in the correct inset. boom.

ah, thats part of the AtPoint discussion... unfortunately there seems to be no
easy fix right now.
pavel

Re: LyX 2.0 release plan

[Edwin Leuven]

rgheck wrote:
Do we need then to remove the AtPoint feature from whatever LFUN this 
is?


i think we can't because it is LFUN_INSET_MODIFY

What that means is precisely: You can apply this LFUN when not in 
the inset but in front of it.


but for tabular functions the cursor need to be in the table

to avoid the crash i committed this

http://www.lyx.org/trac/changeset/33687

Re: LyX 2.0 release plan

[rgheck]

On 03/09/2010 02:12 PM, Edwin Leuven wrote:

rgheck wrote:
Do we need then to remove the AtPoint feature from whatever LFUN this 
is?


i think we can't because it is LFUN_INSET_MODIFY


Ah, yes. That issue.

rh

Re: LyX 2.0 release plan

[Jean-Marc Lasgouttes]

Le 09/03/2010 20:11, Pavel Sanda a écrit :

ah, thats part of the AtPoint discussion... unfortunately there seems to be no
easy fix right now.


Just cerate inset-type change to replace the uses of inset-modify... For 
some reason I do not manage to get svn access here. It is a pity
since otherwise sitting in front of the Mont Blanc is fine. I even had a 
talk in which a co-author is Alfredo Braunstein :)


JMarc

Re: LyX 2.0 release plan

[rgheck]

On 03/08/2010 01:19 AM, Pavel Sanda wrote:

Pavel Sanda wrote:
   
tarball creation is already fixed, monolithic builds checked, short

work with trunk didn't revealed any drastic problems and currently
i monitor two ugly bugs:

- Richard fixed crash #6522, but the price is that outliner doesn't
   work anymore. this needs to be addressed.

   
This is worse, really. My fix is definitely incorrect...I think. ;-) And 
I strongly suspect there are similar bugs lurking in other places, all 
caused by the fact that we call updateBuffer()---the old 
updateLabels()---too early in various places. The change to Qt 4.6.x 
reveals the problem: At the end of updateBuffer(), we emit the 
structureChanged() signal, which causes the TOC to update itself (among 
other things, I'd guess); when it does so, it eventually tries to set 
the focus to the main work area, which means accessing the cursor; but 
the process of updating the cursor, etc, apparently hasn't yet 
completed, and the cursor points at a paragraph that no longer exists.


If you look in the dispatch routine in Text3.cpp, you'll see that there 
are 9 different places updateBuffer() is called; there are 7 in 
Text.cpp; and 2 more in Text2.cpp. This is a problem.


rh

RE: LyX 2.0 release plan

[Vincent van Ravesteijn - TNW]

other bug you would like to see killed?

Insert a table, put the cursor in front of the table, press set all
lines on the table toolbar.. Crash.

Vincent

RE: LyX 2.0 release plan

[Vincent van Ravesteijn - TNW]

 other bug you would like to see killed?

The outline doesn't work anymore.

Vincent

Re: LyX 2.0 release plan

[rgheck]

On 03/08/2010 08:18 AM, Vincent van Ravesteijn - TNW wrote:

other bug you would like to see killed?
 

The outline doesn't work anymore.

   
That's due to my fix for the outliner crash. Now it doesn't crash but 
doesn't work, either.


See also the Export Crash thread. There are serious problems here 
somewhere.


rh

Re: LyX 2.0 release plan

[Jean-Marc Lasgouttes]

Le 06/03/2010 19:04, Abdelrazak Younes a écrit :

* There has been some work on dispatch results, but I have no idea
whats the
current status. JMarc? There are already filled bugs around dispatch.


Concerning the DispatchResult stuff, I have to admit I do not know what 
the status is :) I think it does not work worse than before, but I am 
not sure I fixed the bugs I wanted to fix...




In particular inset-modify tabular has to be addressed...


For inset-modify, I think that putting this as AtPoint function was 
wrong. Actually the reason why it happens is the

inset-modify changetype variant which actually makes no sense. We
should define a inset-change-type lfun and use this in contextual menus.

JMarc

Re: LyX 2.0 release plan

[rgheck]

On 03/08/2010 01:19 AM, Pavel Sanda wrote:

Pavel Sanda wrote:
   
tarball creation is already fixed, monolithic builds checked, short

work with trunk didn't revealed any drastic problems and currently
i monitor two ugly bugs:

- Richard fixed crash #6522, but the price is that outliner doesn't
   work anymore. this needs to be addressed.

   
This is worse, really. My fix is definitely incorrect...I think. ;-) And 
I strongly suspect there are similar bugs lurking in other places, all 
caused by the fact that we call updateBuffer()---the old 
updateLabels()---too early in various places. The change to Qt 4.6.x 
reveals the problem: At the end of updateBuffer(), we emit the 
structureChanged() signal, which causes the TOC to update itself (among 
other things, I'd guess); when it does so, it eventually tries to set 
the focus to the main work area, which means accessing the cursor; but 
the process of updating the cursor, etc, apparently hasn't yet 
completed, and the cursor points at a paragraph that no longer exists.


If you look in the dispatch routine in Text3.cpp, you'll see that there 
are 9 different places updateBuffer() is called; there are 7 in 
Text.cpp; and 2 more in Text2.cpp. This is a problem.


rh

RE: LyX 2.0 release plan

[Vincent van Ravesteijn - TNW]

>other bug you would like to see killed?

Insert a table, put the cursor in front of the table, press set all
lines on the table toolbar.. Crash.

Vincent

RE: LyX 2.0 release plan

[Vincent van Ravesteijn - TNW]

> other bug you would like to see killed?

The outline doesn't work anymore.

Vincent

Re: LyX 2.0 release plan

[rgheck]

On 03/08/2010 08:18 AM, Vincent van Ravesteijn - TNW wrote:

other bug you would like to see killed?
 

The outline doesn't work anymore.

   
That's due to my "fix" for the outliner crash. Now it doesn't crash but 
doesn't work, either.


See also the "Export Crash" thread. There are serious problems here 
somewhere.


rh

Re: LyX 2.0 release plan

[Jean-Marc Lasgouttes]

Le 06/03/2010 19:04, Abdelrazak Younes a écrit :

* There has been some work on dispatch results, but I have no idea
whats the
current status. JMarc? There are already filled bugs around dispatch.


Concerning the DispatchResult stuff, I have to admit I do not know what 
the status is :) I think it does not work worse than before, but I am 
not sure I fixed the bugs I wanted to fix...




In particular "inset-modify tabular" has to be addressed...


For inset-modify, I think that putting this as AtPoint function was 
wrong. Actually the reason why it happens is the

"inset-modify changetype" variant which actually makes no sense. We
should define a inset-change-type lfun and use this in contextual menus.

JMarc

Re: LyX 2.0 release plan

[Jürgen Spitzmüller]

Abdelrazak Younes wrote:
 For the packagers we need some summary what are the recommended
 dependencies. Haven't been closely following this stuff - could somebody
 write some summary of all those spellcheck (a/i/hun/spell) and thesaurus
 deps into RELEASE-NOTES? Juergen, Abdel?
   
 
 Jürgen has much better writing skills than me :-P

Very transparent trial. But I'll do it.

Jürgen

Re: LyX 2.0 release plan

[Jürgen Spitzmüller]

Jürgen Spitzmüller wrote:
  Jürgen has much better writing skills than me :-P
 
 Very transparent trial. But I'll do it.

Done. Please check if everything is correct.

Jürgen

Re: LyX 2.0 release plan

[Pavel Sanda]

Abdelrazak Younes wrote:
 Is there some cost to leaving the old code in until e.g. #6516 is fixed?


 No, we can leave it if this is a blocker of course.

actually it would fine if you could look before alpha on this particular one.
pavel

Re: LyX 2.0 release plan

[Tommaso Cucinotta]

Pavel Sanda wrote:

* Advanced Search - as far as I can see all wanted features finished, Tommaso?
  

at least the simple usage scenarios are ok . . .

  I expect lot of bug reports here though, we need to wait on users testing.
  
. . . though, I expect bugs to come up when you try all the things 
together, like using more checkboxes at once (among the ones available 
in the panel -- no, I didn't check all the combinations), using regular 
expressions (understanding what exactly works and what not), trying to 
put strange things like ERT inserts with unusual contents inside (e.g., 
braces ?!?), searching for weird things like separators, pictures, 
external materials/children and the like, and some other issues due to 
some escaping that occurs in lyxfind.cpp which may not be perfect or may 
not always work.


   T.

Re: LyX 2.0 release plan

[Pavel Sanda]

Pavel Sanda wrote:
 Alpha - next week if possible

tarball creation is already fixed, monolithic builds checked, short
work with trunk didn't revealed any drastic problems and currently
i monitor two ugly bugs:

- crashes in #6516, there are already some hinst from Peter in trac
- Richard fixed crash #6522, but the price is that outliner doesn't
  work anymore. this needs to be addressed.

other bug you would like to see killed?


if we are able to fix those, i would like to tag alpha 1 at wednesday
and release at friday.

pavel

Re: LyX 2.0 release plan

[Jürgen Spitzmüller]

Pavel Sanda wrote:
 other bug you would like to see killed?

The error dialog is currently completely broken (it doesn't show at all). I 
think this is a pretty nasty bug.

Jürgen

Re: LyX 2.0 release plan

[Pavel Sanda]

Jürgen Spitzmüller wrote:
 Pavel Sanda wrote:
  other bug you would like to see killed?
 
 The error dialog is currently completely broken (it doesn't show at all). I 
 think this is a pretty nasty bug.

ok
pavel

Re: LyX 2.0 release plan

[Jürgen Spitzmüller]

Abdelrazak Younes wrote:
> >>For the packagers we need some summary what are the recommended
> >>dependencies. Haven't been closely following this stuff - could somebody
> >>write some summary of all those spellcheck (a/i/hun/spell) and thesaurus
> >>deps into RELEASE-NOTES? Juergen, Abdel?
> >>  
> 
> Jürgen has much better writing skills than me :-P

Very transparent trial. But I'll do it.

Jürgen

Re: LyX 2.0 release plan

[Jürgen Spitzmüller]

Jürgen Spitzmüller wrote:
> > Jürgen has much better writing skills than me :-P
> 
> Very transparent trial. But I'll do it.

Done. Please check if everything is correct.

Jürgen

Re: LyX 2.0 release plan

[Pavel Sanda]

Abdelrazak Younes wrote:
>> Is there some cost to leaving the old code in until e.g. #6516 is fixed?
>>
>
> No, we can leave it if this is a blocker of course.

actually it would fine if you could look before alpha on this particular one.
pavel

Re: LyX 2.0 release plan

[Tommaso Cucinotta]

Pavel Sanda wrote:

* Advanced Search - as far as I can see all wanted features finished, Tommaso?
  

at least the simple usage scenarios are ok . . .

  I expect lot of bug reports here though, we need to wait on users testing.
  
. . . though, I expect bugs to come up when you try all the things 
together, like using more checkboxes at once (among the ones available 
in the panel -- no, I didn't check all the combinations), using regular 
expressions (understanding what exactly works and what not), trying to 
put strange things like ERT inserts with unusual contents inside (e.g., 
braces ?!?), searching for weird things like separators, pictures, 
external materials/children and the like, and some other issues due to 
some escaping that occurs in lyxfind.cpp which may not be perfect or may 
not always work.


   T.

Re: LyX 2.0 release plan

[Pavel Sanda]

Pavel Sanda wrote:
> Alpha - next week if possible

tarball creation is already fixed, monolithic builds checked, short
work with trunk didn't revealed any drastic problems and currently
i monitor two ugly bugs:

- crashes in #6516, there are already some hinst from Peter in trac
- Richard fixed crash #6522, but the price is that outliner doesn't
  work anymore. this needs to be addressed.

other bug you would like to see killed?


if we are able to fix those, i would like to tag alpha 1 at wednesday
and release at friday.

pavel

Re: LyX 2.0 release plan

[Jürgen Spitzmüller]

Pavel Sanda wrote:
> other bug you would like to see killed?

The error dialog is currently completely broken (it doesn't show at all). I 
think this is a pretty nasty bug.

Jürgen

Re: LyX 2.0 release plan

[Pavel Sanda]

Jürgen Spitzmüller wrote:
> Pavel Sanda wrote:
> > other bug you would like to see killed?
> 
> The error dialog is currently completely broken (it doesn't show at all). I 
> think this is a pretty nasty bug.

ok
pavel

Re: LyX 2.0 release plan

[Pavel Sanda]

Bo Peng wrote:
 Other entries?
 
  The Export as ZIP feature. I'll try to come up with a prototype asap.
 
  Vincent
 
 Is this the final consensus of the embedding/zip/folder/whatever
 feature of lyx?

there was no discussion about this proposal and as i understood
its not embedding feature, but one more item on file-export
menu, just more advanced version of python zipping script from
Enrico we already have in the tree.

 feature is certainly not enough. If I am going to re-design an
 embedding feature now (very unlikely :-), I would make

the only (new) design idea was proposed by Abdel not so long ago at
the end of 'Re: r33474'... thread. feel free to comment on it.

pavel

Re: LyX 2.0 release plan

[John McCabe-Dansted]

On Fri, Mar 5, 2010 at 10:48 PM, Vincent van Ravesteijn - TNW
v.f.vanraveste...@tudelft.nl wrote:
 Did we leave the instability period that was expected due to:
 - threaded export,

IMHO we should
 #define EXPORT_in_THREAD 0
I have done this in keytest since otherwise keytest would do almost
nothing but generate reports about  EXPORT_in_THREAD problems such as
#6427. On my machine each threaded export has a roughly 50% chance of
crashing LyX. We don't need users tell us that EXPORT_in_THREAD is
broken. We already know it is.

Another thing: will the alphas abort on assertions? We know that there
are some mostly harmless assertions that popup without warning such as
#6172
  lassert.cpp(21): ASSERTION y  -100 VIOLATED IN CoordCache?.cpp:31
There seems to be little gain in triggering a SIGABRT on such
assertions. If we do not want these assertions being buried in some
xsession file no-one reads, perhaps we could modify LASSERT to popup a
dialog like the following.:

+--
|  Warning: Assertion triggered
+--
|  The following assertion has been triggered. This is a bug in LyX.
Please the the Bug reporting guide and report this bug.*
|lassert.cpp(21): ASSERTION y  -100 VIOLATED IN CoordCache?.cpp:31
|
|  [ ] Do not show this warning again
|
|  [Abort] [Ignore]
+---

We could perhaps also add options like Get backtrace without
aborting, Search for bug in LyX bugtracker, and maybe even Report
bug in LYX bug tracker.

* Though we probably don't want users actually reporting this
particular bug since we already know about it.
--

http://www.lyx.org/trac/ticket/6427
http://www.lyx.org/trac/ticket/6172

-- 
John C. McCabe-Dansted

Re: LyX 2.0 release plan

[Vincent van Ravesteijn]

John McCabe-Dansted schreef:

On Fri, Mar 5, 2010 at 10:48 PM, Vincent van Ravesteijn - TNW
v.f.vanraveste...@tudelft.nl wrote:
  

Did we leave the instability period that was expected due to:
- threaded export,



IMHO we should
 #define EXPORT_in_THREAD 0
  

No, we should have this.


I have done this in keytest since otherwise keytest would do almost
nothing but generate reports about  EXPORT_in_THREAD problems such as
#6427. 

I expect users not to press \Ct for thirty seconds.


On my machine each threaded export has a roughly 50% chance of
crashing LyX. 

Then you have a buggy machine.


We don't need users tell us that EXPORT_in_THREAD is
broken. We already know it is.
  

No, we don't.


Another thing: will the alphas abort on assertions? We know that there
are some mostly harmless assertions that popup without warning such as
#6172
  

That's the whole idea of assertions.


  lassert.cpp(21): ASSERTION y  -100 VIOLATED IN CoordCache?.cpp:31
There seems to be little gain in triggering a SIGABRT on such
assertions. 

Why not ?


* Though we probably don't want users actually reporting this
particular bug since we already know about it.
  

Who says we know about it ?

Vincent

Re: LyX 2.0 release plan

[Pavel Sanda]

John McCabe-Dansted wrote:
 IMHO we should
  #define EXPORT_in_THREAD 0

no we should collect as many bugs as possible for new features.

 #6427. On my machine each threaded export has a roughly 50% chance of
 crashing LyX. We don't need users tell us that EXPORT_in_THREAD is
 broken. We already know it is.

i dont have those crashes. at least we could identify group of people
reporting the same and try to find what is the common denominator.

 Another thing: will the alphas abort on assertions?

the default should be yes for all prereleases.
on the other hand its after all choice of the testers what build type
./configure --enable-build-type=[rel(ease), dev(elopment), pre(release)]
they choose.

We know that there
 are some mostly harmless assertions that popup without warning such as
 #6172
   lassert.cpp(21): ASSERTION y  -100 VIOLATED IN CoordCache?.cpp:31
 There seems to be little gain in triggering a SIGABRT on such
 assertions.

assertion means we do something really badly and prerelease is good time
to catch it.

If we do not want these assertions being buried in some
 xsession file no-one reads, perhaps we could modify LASSERT to popup a
 dialog like the following.:

if they find reproducible assertion, the recipy is enough; if its not 
reproducible
then assertion msg itself is usually not much useful...

pavel

Re: LyX 2.0 release plan

[John McCabe-Dansted]

On Sat, Mar 6, 2010 at 10:17 PM, Pavel Sanda sa...@lyx.org wrote:
 John McCabe-Dansted wrote:
 IMHO we should
  #define EXPORT_in_THREAD 0

 no we should collect as many bugs as possible for new features.

But we need some exciting new feature to announce with the second Alpha! :P

 #6427. On my machine each threaded export has a roughly 50% chance of
 crashing LyX. We don't need users tell us that EXPORT_in_THREAD is
 broken. We already know it is.

Actually, I think I am hitting  #6516 more often than #6427.

 i dont have those crashes. at least we could identify group of people
 reporting the same and try to find what is the common denominator.

My first impression was that we had already found the major bugs in
EXPORT_in_THREAD and were mainly waiting on fixes, but I guess I don't
know that.

 Another thing: will the alphas abort on assertions?

 the default should be yes for all prereleases.
 on the other hand its after all choice of the testers what build type
 ./configure --enable-build-type=[rel(ease), dev(elopment), pre(release)]
 they choose.

We know that there
 are some mostly harmless assertions that popup without warning such as
 #6172
   lassert.cpp(21): ASSERTION y  -100 VIOLATED IN CoordCache?.cpp:31
 There seems to be little gain in triggering a SIGABRT on such
 assertions.

 assertion means we do something really badly and prerelease is good time
 to catch it.

But we have already caught/reported this bug. I am not sure how making
a users window disappear would help us further.

It seems that a dialog box allowing the user to choose what to do on a
case by case basis would be nicer than the LyX window  disappearing
without any warning. Is there a disadvantage?

If we do not want these assertions being buried in some
 xsession file no-one reads, perhaps we could modify LASSERT to popup a
 dialog like the following.:

 if they find reproducible assertion, the recipy is enough; if its not 
 reproducible
 then assertion msg itself is usually not much useful...

Well how about the search option?  As a tester an option to quickly
tell whether a bug has already been reported would seem quite useful.

Also the report option could inform the user that if they do not know
how to reproduce the bug they need not report it. FYI, I have search
and report links in keytest like this:
   http://gmatht.homelinux.net/xp/html_out/out/t4/html/
The report fills in a How to reproduce stub that may also encourage
the user to look for a way to reproduce. (Since I am currently the
only user of keytest this is hardly necessary for keytest yet).

-- 
John C. McCabe-Dansted

Re: LyX 2.0 release plan

[Pavel Sanda]

John McCabe-Dansted wrote:
  #6427. On my machine each threaded export has a roughly 50% chance of
  crashing LyX. We don't need users tell us that EXPORT_in_THREAD is
  broken. We already know it is.
 
 Actually, I think I am hitting  #6516 more often than #6427.

i see. the master child layout and viewing seems to be really killer for
lyx even here. priority raised.

 But we have already caught/reported this bug. I am not sure how making
 a users window disappear would help us further.

for this one no ;)

 It seems that a dialog box allowing the user to choose what to do on a
 case by case basis would be nicer than the LyX window  disappearing
 without any warning. Is there a disadvantage?

over engineering. please note again that alpha is for testers only
and not for Joe the BFU. the annoucements will go only to dev and
users list.

the dialog which would make me interested is the one which produce
backtrace after each crash, so user can put it in our bugzilla.
but thats not easy to do i guess.

 Well how about the search option?  As a tester an option to quickly
 tell whether a bug has already been reported would seem quite useful.
 
 Also the report option could inform the user that if they do not know
 how to reproduce the bug they need not report it. FYI, I have search
 and report links in keytest like this:
http://gmatht.homelinux.net/xp/html_out/out/t4/html/
 The report fills in a How to reproduce stub that may also encourage
 the user to look for a way to reproduce. (Since I am currently the
 only user of keytest this is hardly necessary for keytest yet).

sorry John, really better to focus on fixing the particular bugs then
this circus around :)

pavel

Re: LyX 2.0 release plan

[Pavel Sanda]

Pavel Sanda wrote:
 stage. The current version can be always reached at
 http://wiki.lyx.org/Devel/LyX20Road
 and I fill it once this thread is finished.

did this now. still waiting on replies from the French wing Abdel and JMarc.

one more idea - if you feel some particular bug should be fixed before 
releasing the forthcomming tarball mark it as highest priority in trac.

pavel

 
 
 * Advanced Search - as far as I can see all wanted features finished, Tommaso?
   I expect lot of bug reports here though, we need to wait on users testing.
 
 * Spellchecking - IIRC all features done or were there something more - I 
 remember,
   some proposals like automatic switching off when xx% unrecognized etc.
   There are also already untouched bugs with spellcheck component. Abdel?
 
   For the packagers we need some summary what are the recommended 
 dependencies.
   Haven't been closely following this stuff - could somebody write some 
 summary
   of all those spellcheck (a/i/hun/spell) and thesaurus deps into 
 RELEASE-NOTES?
   Juergen, Abdel?
 
 * Comparison - IIRC Vincent considered some more work which would use
   words instead of characters to boost up the process. Currently the
   documents which are far from each other will never finish in a reasonable 
 time.
   Vincent what are your plans? Also NewInLyx2.0 entry is missing or we wait 
 for
   the finishing?
 
 * HTML export. I remember Richard asked for help with images. Anybody around?
   Some plans to add instant preview snapshots for equations, or external 
 insets
   using preview? Some other plans Richard? NewInLyx2.0 entry is missing.
 
 * Multiple viewers/converters. Juergen asked for some help; how this evolved,
   what is to be done in this area? Juergen, Richard? 
 
 * rc2rc conversion scripts for converting older preferences into new ones.
   Jose promised to come with something. I have worried what happen with users
   which run lyx beta to test and get prefs overwritten for their stable 1.6.x?
 
 * Instant preview. What is the status/plan with the patch. IIRC Vincent was
   unsatisfied with the state of art without being specific.
 
 * Tabular stuff. Edwin, Uwe and Abdel seem to work on it right now.
 
 * There has been some work on dispatch results, but I have no idea whats the
   current status. JMarc? There are already filled bugs around dispatch.
 
 * Connection between VCS and comparison feature. I have idea what to do but
   others weren't happy about the approach, so more discussion is needed.
 
 * Layout groups are hopeless? Richard? Anybody? 
   http://wiki.lyx.org/Devel/LayoutGroup
 
 
 Other entries?
 
 Pavel

Re: LyX 2.0 release plan

[Abdelrazak Younes]

On 06/03/2010 18:45, Pavel Sanda wrote:

Pavel Sanda wrote:
   

stage. The current version can be always reached at
http://wiki.lyx.org/Devel/LyX20Road
and I fill it once this thread is finished.
 

did this now. still waiting on replies from the French wing Abdel and JMarc.
   


Not sure what has already been commented but here are some more comment 
below...



one more idea - if you feel some particular bug should be fixed before
releasing the forthcomming tarball mark it as highest priority in trac.

pavel

   


* Advanced Search - as far as I can see all wanted features finished, Tommaso?
   I expect lot of bug reports here though, we need to wait on users testing.

* Spellchecking - IIRC all features done or were there something more - I 
remember,
   some proposals like automatic switching off when xx% unrecognized etc.
   There are also already untouched bugs with spellcheck component. Abdel?
 


What can I say? I don't have much free time and lots of bugs are my 
doing... Don't stop the alpha for me as I will always be late...



   For the packagers we need some summary what are the recommended dependencies.
   Haven't been closely following this stuff - could somebody write some summary
   of all those spellcheck (a/i/hun/spell) and thesaurus deps into 
RELEASE-NOTES?
   Juergen, Abdel?
 


Jürgen has much better writing skills than me :-P



* Tabular stuff. Edwin, Uwe and Abdel seem to work on it right now.
 


This is my priority right now... At least the table dialog - inset 
communications.



* There has been some work on dispatch results, but I have no idea whats the
   current status. JMarc? There are already filled bugs around dispatch.
 


In particular inset-modify tabular has to be addressed...

Abdel.

Re: LyX 2.0 release plan

[Abdelrazak Younes]

On 06/03/2010 14:43, Vincent van Ravesteijn wrote:

John McCabe-Dansted schreef:

On Fri, Mar 5, 2010 at 10:48 PM, Vincent van Ravesteijn - TNW
v.f.vanraveste...@tudelft.nl wrote:

Did we leave the instability period that was expected due to:
- threaded export,


IMHO we should
 #define EXPORT_in_THREAD 0

No, we should have this.


FWIW I put this macro because I was not sure if the feature would 
converge to a stable state, but this seems almost OK right now. Lots of 
people are awaiting this feature so if we don't intent to go back, what 
about deleting the old synchronous export code?


Abdel.

Re: LyX 2.0 release plan

[John McCabe-Dansted]

On Sun, Mar 7, 2010 at 12:52 AM, Pavel Sanda sa...@lyx.org wrote:
 John McCabe-Dansted wrote:
 It seems that a dialog box allowing the user to choose what to do on a
 case by case basis would be nicer than the LyX window  disappearing
 without any warning. Is there a disadvantage?

 over engineering. please note again that alpha is for testers only
 and not for Joe the BFU. the annoucements will go only to dev and
 users list.

I was thinking more of a long term thing, but thought I should discuss
the ultimate design now.

 the dialog which would make me interested is the one which produce
 backtrace after each crash, so user can put it in our bugzilla.
 but thats not easy to do i guess.

Maybe something like the following?
char buffer[512];
sprintf(buffer, (echo set height 0 ; echo bt ; yes q) | gdb
./lyx %d,getpid());
system(buffer);
(Clearly ./lyx should be replaced with lyx::os::support::utf8_argv(0))

Seems to work on my Linux box. There is gdb for MingW but I don't know
if that means it could be made to work on Windows.

I imagine that using Qt dialogs if there is a actual crash (rather
than an assertion) may be a little risky. But  maybe I could replace
BOOST_ASSERT(false) with code similar to the above in lassert?

-- 
John C. McCabe-Dansted

Re: LyX 2.0 release plan

[John McCabe-Dansted]

On Sun, Mar 7, 2010 at 2:10 AM, Abdelrazak Younes you...@lyx.org wrote:
 On 06/03/2010 14:43, Vincent van Ravesteijn wrote:

 John McCabe-Dansted schreef:

 On Fri, Mar 5, 2010 at 10:48 PM, Vincent van Ravesteijn - TNW
 v.f.vanraveste...@tudelft.nl wrote:

 Did we leave the instability period that was expected due to:
 - threaded export,

 IMHO we should
  #define EXPORT_in_THREAD 0

 No, we should have this.

 FWIW I put this macro because I was not sure if the feature would converge
 to a stable state, but this seems almost OK right now. Lots of people are
 awaiting this feature so if we don't intent to go back, what about deleting
 the old synchronous export code?

Well I can't compile my thesis with EXPORT_in_THREAD 1, due to  #6516.
I don't know if there are any other bugs in the threaded code that
would prevent my thesis from compiling.

Is there some cost to leaving the old code in until e.g. #6516 is fixed?

-- 
John C. McCabe-Dansted

Re: LyX 2.0 release plan

[Pavel Sanda]

John McCabe-Dansted wrote:
  the dialog which would make me interested is the one which produce
  backtrace after each crash, so user can put it in our bugzilla.
  but thats not easy to do i guess.
 
 Maybe something like the following?
 char buffer[512];
 sprintf(buffer, (echo set height 0 ; echo bt ; yes q) | gdb
 ./lyx %d,getpid());
 system(buffer);
 (Clearly ./lyx should be replaced with lyx::os::support::utf8_argv(0))
 
 Seems to work on my Linux box. There is gdb for MingW but I don't know
 if that means it could be made to work on Windows.

you rely not only on gdb but also on bash i think. this wont help on win32.

 I imagine that using Qt dialogs if there is a actual crash (rather
 than an assertion) may be a little risky.

one can launch another binary which just gets lyx backtrace on stdin and 
puts into QEditText.

pavel

Re: LyX 2.0 release plan

[Abdelrazak Younes]

On 06/03/2010 20:32, John McCabe-Dansted wrote:

On Sun, Mar 7, 2010 at 2:10 AM, Abdelrazak Younesyou...@lyx.org  wrote:
   

On 06/03/2010 14:43, Vincent van Ravesteijn wrote:
 

John McCabe-Dansted schreef:
   

On Fri, Mar 5, 2010 at 10:48 PM, Vincent van Ravesteijn - TNW
v.f.vanraveste...@tudelft.nl  wrote:
 

Did we leave the instability period that was expected due to:
- threaded export,
   

IMHO we should
  #define EXPORT_in_THREAD 0
 

No, we should have this.
   

FWIW I put this macro because I was not sure if the feature would converge
to a stable state, but this seems almost OK right now. Lots of people are
awaiting this feature so if we don't intent to go back, what about deleting
the old synchronous export code?
 

Well I can't compile my thesis with EXPORT_in_THREAD 1, due to  #6516.
I don't know if there are any other bugs in the threaded code that
would prevent my thesis from compiling.

Is there some cost to leaving the old code in until e.g. #6516 is fixed?
   


No, we can leave it if this is a blocker of course.

Abdel.

Re: LyX 2.0 release plan

[Pavel Sanda]

Bo Peng wrote:
> >>Other entries?
> >
> > The "Export as ZIP" feature. I'll try to come up with a prototype asap.
> >
> > Vincent
> 
> Is this the final consensus of the embedding/zip/folder/whatever
> feature of lyx?

there was no discussion about this proposal and as i understood
its not embedding feature, but one more item on file->export
menu, just more advanced version of python zipping script from
Enrico we already have in the tree.

> feature is certainly not enough. If I am going to re-design an
> embedding feature now (very unlikely :-), I would make

the only (new) design idea was proposed by Abdel not so long ago at
the end of 'Re: r33474'... thread. feel free to comment on it.

pavel

Re: LyX 2.0 release plan

[John McCabe-Dansted]

On Fri, Mar 5, 2010 at 10:48 PM, Vincent van Ravesteijn - TNW
 wrote:
> Did we leave the instability period that was expected due to:
> - threaded export,

IMHO we should
 #define EXPORT_in_THREAD 0
I have done this in keytest since otherwise keytest would do almost
nothing but generate reports about  EXPORT_in_THREAD problems such as
#6427. On my machine each threaded export has a roughly 50% chance of
crashing LyX. We don't need users tell us that EXPORT_in_THREAD is
broken. We already know it is.

Another thing: will the alphas abort on assertions? We know that there
are some mostly harmless assertions that popup without warning such as
#6172
  lassert.cpp(21): ASSERTION y > -100 VIOLATED IN CoordCache?.cpp:31
There seems to be little gain in triggering a SIGABRT on such
assertions. If we do not want these assertions being buried in some
xsession file no-one reads, perhaps we could modify LASSERT to popup a
dialog like the following.:

+--
|  Warning: Assertion triggered
+--
|  The following assertion has been triggered. This is a bug in LyX.
Please the the Bug reporting guide and report this bug.*
|lassert.cpp(21): ASSERTION y > -100 VIOLATED IN CoordCache?.cpp:31
|
|  [ ] Do not show this warning again
|
|  [Abort] [Ignore]
+---

We could perhaps also add options like "Get backtrace without
aborting", "Search for bug in LyX bugtracker", and maybe even "Report
bug in LYX bug tracker".

* Though we probably don't want users actually reporting this
particular bug since we already know about it.
--

http://www.lyx.org/trac/ticket/6427
http://www.lyx.org/trac/ticket/6172

-- 
John C. McCabe-Dansted

Re: LyX 2.0 release plan

[Vincent van Ravesteijn]

John McCabe-Dansted schreef:

On Fri, Mar 5, 2010 at 10:48 PM, Vincent van Ravesteijn - TNW
 wrote:
  

Did we leave the instability period that was expected due to:
- threaded export,



IMHO we should
 #define EXPORT_in_THREAD 0
  

No, we should have this.


I have done this in keytest since otherwise keytest would do almost
nothing but generate reports about  EXPORT_in_THREAD problems such as
#6427. 

I expect users not to press \Ct for thirty seconds.


On my machine each threaded export has a roughly 50% chance of
crashing LyX. 

Then you have a buggy machine.


We don't need users tell us that EXPORT_in_THREAD is
broken. We already know it is.
  

No, we don't.


Another thing: will the alphas abort on assertions? We know that there
are some mostly harmless assertions that popup without warning such as
#6172
  

That's the whole idea of assertions.


  lassert.cpp(21): ASSERTION y > -100 VIOLATED IN CoordCache?.cpp:31
There seems to be little gain in triggering a SIGABRT on such
assertions. 

Why not ?


* Though we probably don't want users actually reporting this
particular bug since we already know about it.
  

Who says we know about it ?

Vincent

Re: LyX 2.0 release plan

[Pavel Sanda]

John McCabe-Dansted wrote:
> IMHO we should
>  #define EXPORT_in_THREAD 0

no we should collect as many bugs as possible for new features.

> #6427. On my machine each threaded export has a roughly 50% chance of
> crashing LyX. We don't need users tell us that EXPORT_in_THREAD is
> broken. We already know it is.

i dont have those crashes. at least we could identify group of people
reporting the same and try to find what is the common denominator.

> Another thing: will the alphas abort on assertions?

the default should be yes for all prereleases.
on the other hand its after all choice of the testers what build type
./configure --enable-build-type=[rel(ease), dev(elopment), pre(release)]
they choose.

>We know that there
> are some mostly harmless assertions that popup without warning such as
> #6172
>   lassert.cpp(21): ASSERTION y > -100 VIOLATED IN CoordCache?.cpp:31
> There seems to be little gain in triggering a SIGABRT on such
> assertions.

assertion means we do something really badly and prerelease is good time
to catch it.

>If we do not want these assertions being buried in some
> xsession file no-one reads, perhaps we could modify LASSERT to popup a
> dialog like the following.:

if they find reproducible assertion, the recipy is enough; if its not 
reproducible
then assertion msg itself is usually not much useful...

pavel

Re: LyX 2.0 release plan

[John McCabe-Dansted]

On Sat, Mar 6, 2010 at 10:17 PM, Pavel Sanda  wrote:
> John McCabe-Dansted wrote:
>> IMHO we should
>>  #define EXPORT_in_THREAD 0
>
> no we should collect as many bugs as possible for new features.

But we need some exciting new feature to announce with the second Alpha! :P

>> #6427. On my machine each threaded export has a roughly 50% chance of
>> crashing LyX. We don't need users tell us that EXPORT_in_THREAD is
>> broken. We already know it is.

Actually, I think I am hitting  #6516 more often than #6427.

> i dont have those crashes. at least we could identify group of people
> reporting the same and try to find what is the common denominator.

My first impression was that we had already found the major bugs in
EXPORT_in_THREAD and were mainly waiting on fixes, but I guess I don't
know that.

>> Another thing: will the alphas abort on assertions?
>
> the default should be yes for all prereleases.
> on the other hand its after all choice of the testers what build type
> ./configure --enable-build-type=[rel(ease), dev(elopment), pre(release)]
> they choose.
>
>>We know that there
>> are some mostly harmless assertions that popup without warning such as
>> #6172
>>   lassert.cpp(21): ASSERTION y > -100 VIOLATED IN CoordCache?.cpp:31
>> There seems to be little gain in triggering a SIGABRT on such
>> assertions.
>
> assertion means we do something really badly and prerelease is good time
> to catch it.

But we have already caught/reported this bug. I am not sure how making
a users window disappear would help us further.

It seems that a dialog box allowing the user to choose what to do on a
case by case basis would be nicer than the LyX window  disappearing
without any warning. Is there a disadvantage?

>>If we do not want these assertions being buried in some
>> xsession file no-one reads, perhaps we could modify LASSERT to popup a
>> dialog like the following.:
>
> if they find reproducible assertion, the recipy is enough; if its not 
> reproducible
> then assertion msg itself is usually not much useful...

Well how about the search option?  As a tester an option to quickly
tell whether a bug has already been reported would seem quite useful.

Also the report option could inform the user that if they do not know
how to reproduce the bug they need not report it. FYI, I have search
and report links in keytest like this:
   http://gmatht.homelinux.net/xp/html_out/out/t4/html/
The report fills in a "How to reproduce" stub that may also encourage
the user to look for a way to reproduce. (Since I am currently the
only user of keytest this is hardly necessary for keytest yet).

-- 
John C. McCabe-Dansted

Re: LyX 2.0 release plan

[Pavel Sanda]

John McCabe-Dansted wrote:
> >> #6427. On my machine each threaded export has a roughly 50% chance of
> >> crashing LyX. We don't need users tell us that EXPORT_in_THREAD is
> >> broken. We already know it is.
> 
> Actually, I think I am hitting  #6516 more often than #6427.

i see. the master child layout and viewing seems to be really killer for
lyx even here. priority raised.

> But we have already caught/reported this bug. I am not sure how making
> a users window disappear would help us further.

for this one no ;)

> It seems that a dialog box allowing the user to choose what to do on a
> case by case basis would be nicer than the LyX window  disappearing
> without any warning. Is there a disadvantage?

over engineering. please note again that alpha is for testers only
and not for Joe the BFU. the annoucements will go only to dev and
users list.

the dialog which would make me interested is the one which produce
backtrace after each crash, so user can put it in our bugzilla.
but thats not easy to do i guess.

> Well how about the search option?  As a tester an option to quickly
> tell whether a bug has already been reported would seem quite useful.
> 
> Also the report option could inform the user that if they do not know
> how to reproduce the bug they need not report it. FYI, I have search
> and report links in keytest like this:
>http://gmatht.homelinux.net/xp/html_out/out/t4/html/
> The report fills in a "How to reproduce" stub that may also encourage
> the user to look for a way to reproduce. (Since I am currently the
> only user of keytest this is hardly necessary for keytest yet).

sorry John, really better to focus on fixing the particular bugs then
this circus around :)

pavel

Re: LyX 2.0 release plan

[Pavel Sanda]

Pavel Sanda wrote:
> stage. The current version can be always reached at
> http://wiki.lyx.org/Devel/LyX20Road
> and I fill it once this thread is finished.

did this now. still waiting on replies from the French wing Abdel and JMarc.

one more idea - if you feel some particular bug should be fixed before 
releasing the forthcomming tarball mark it as highest priority in trac.

pavel

> 
> 
> * Advanced Search - as far as I can see all wanted features finished, Tommaso?
>   I expect lot of bug reports here though, we need to wait on users testing.
> 
> * Spellchecking - IIRC all features done or were there something more - I 
> remember,
>   some proposals like automatic switching off when xx% unrecognized etc.
>   There are also already untouched bugs with spellcheck component. Abdel?
> 
>   For the packagers we need some summary what are the recommended 
> dependencies.
>   Haven't been closely following this stuff - could somebody write some 
> summary
>   of all those spellcheck (a/i/hun/spell) and thesaurus deps into 
> RELEASE-NOTES?
>   Juergen, Abdel?
> 
> * Comparison - IIRC Vincent considered some more work which would use
>   words instead of characters to boost up the process. Currently the
>   documents which are far from each other will never finish in a reasonable 
> time.
>   Vincent what are your plans? Also NewInLyx2.0 entry is missing or we wait 
> for
>   the finishing?
> 
> * HTML export. I remember Richard asked for help with images. Anybody around?
>   Some plans to add instant preview snapshots for equations, or external 
> insets
>   using preview? Some other plans Richard? NewInLyx2.0 entry is missing.
> 
> * Multiple viewers/converters. Juergen asked for some help; how this evolved,
>   what is to be done in this area? Juergen, Richard? 
> 
> * rc2rc conversion scripts for converting older preferences into new ones.
>   Jose promised to come with something. I have worried what happen with users
>   which run lyx beta to test and get prefs overwritten for their stable 1.6.x?
> 
> * Instant preview. What is the status/plan with the patch. IIRC Vincent was
>   unsatisfied with the state of art without being specific.
> 
> * Tabular stuff. Edwin, Uwe and Abdel seem to work on it right now.
> 
> * There has been some work on dispatch results, but I have no idea whats the
>   current status. JMarc? There are already filled bugs around dispatch.
> 
> * Connection between VCS and comparison feature. I have idea what to do but
>   others weren't happy about the approach, so more discussion is needed.
> 
> * Layout groups are hopeless? Richard? Anybody? 
>   http://wiki.lyx.org/Devel/LayoutGroup
> 
> 
> Other entries?
> 
> Pavel

Re: LyX 2.0 release plan

[Abdelrazak Younes]

On 06/03/2010 18:45, Pavel Sanda wrote:

Pavel Sanda wrote:
   

stage. The current version can be always reached at
http://wiki.lyx.org/Devel/LyX20Road
and I fill it once this thread is finished.
 

did this now. still waiting on replies from the French wing Abdel and JMarc.
   


Not sure what has already been commented but here are some more comment 
below...



one more idea - if you feel some particular bug should be fixed before
releasing the forthcomming tarball mark it as highest priority in trac.

pavel

   


* Advanced Search - as far as I can see all wanted features finished, Tommaso?
   I expect lot of bug reports here though, we need to wait on users testing.

* Spellchecking - IIRC all features done or were there something more - I 
remember,
   some proposals like automatic switching off when xx% unrecognized etc.
   There are also already untouched bugs with spellcheck component. Abdel?
 


What can I say? I don't have much free time and lots of bugs are my 
doing... Don't stop the alpha for me as I will always be late...



   For the packagers we need some summary what are the recommended dependencies.
   Haven't been closely following this stuff - could somebody write some summary
   of all those spellcheck (a/i/hun/spell) and thesaurus deps into 
RELEASE-NOTES?
   Juergen, Abdel?
 


Jürgen has much better writing skills than me :-P



* Tabular stuff. Edwin, Uwe and Abdel seem to work on it right now.
 


This is my priority right now... At least the table dialog <-> inset 
communications.



* There has been some work on dispatch results, but I have no idea whats the
   current status. JMarc? There are already filled bugs around dispatch.
 


In particular "inset-modify tabular" has to be addressed...

Abdel.

Re: LyX 2.0 release plan

[Abdelrazak Younes]

On 06/03/2010 14:43, Vincent van Ravesteijn wrote:

John McCabe-Dansted schreef:

On Fri, Mar 5, 2010 at 10:48 PM, Vincent van Ravesteijn - TNW
 wrote:

Did we leave the instability period that was expected due to:
- threaded export,


IMHO we should
 #define EXPORT_in_THREAD 0

No, we should have this.


FWIW I put this macro because I was not sure if the feature would 
converge to a stable state, but this seems almost OK right now. Lots of 
people are awaiting this feature so if we don't intent to go back, what 
about deleting the old synchronous export code?


Abdel.

Re: LyX 2.0 release plan

[John McCabe-Dansted]

On Sun, Mar 7, 2010 at 12:52 AM, Pavel Sanda  wrote:
> John McCabe-Dansted wrote:
>> It seems that a dialog box allowing the user to choose what to do on a
>> case by case basis would be nicer than the LyX window  disappearing
>> without any warning. Is there a disadvantage?
>
> over engineering. please note again that alpha is for testers only
> and not for Joe the BFU. the annoucements will go only to dev and
> users list.

I was thinking more of a long term thing, but thought I should discuss
the ultimate design now.

> the dialog which would make me interested is the one which produce
> backtrace after each crash, so user can put it in our bugzilla.
> but thats not easy to do i guess.

Maybe something like the following?
char buffer[512];
sprintf(buffer, "(echo set height 0 ; echo bt ; yes q) | gdb
./lyx %d",getpid());
system(buffer);
(Clearly ./lyx should be replaced with lyx::os::support::utf8_argv(0))

Seems to work on my Linux box. There is gdb for MingW but I don't know
if that means it could be made to work on Windows.

I imagine that using Qt dialogs if there is a actual crash (rather
than an assertion) may be a little risky. But  maybe I could replace
"BOOST_ASSERT(false)" with code similar to the above in lassert?

-- 
John C. McCabe-Dansted

Re: LyX 2.0 release plan

[John McCabe-Dansted]

On Sun, Mar 7, 2010 at 2:10 AM, Abdelrazak Younes  wrote:
> On 06/03/2010 14:43, Vincent van Ravesteijn wrote:
>>
>> John McCabe-Dansted schreef:
>>>
>>> On Fri, Mar 5, 2010 at 10:48 PM, Vincent van Ravesteijn - TNW
>>>  wrote:

 Did we leave the instability period that was expected due to:
 - threaded export,
>>>
>>> IMHO we should
>>>  #define EXPORT_in_THREAD 0
>>
>> No, we should have this.
>
> FWIW I put this macro because I was not sure if the feature would converge
> to a stable state, but this seems almost OK right now. Lots of people are
> awaiting this feature so if we don't intent to go back, what about deleting
> the old synchronous export code?

Well I can't compile my thesis with EXPORT_in_THREAD 1, due to  #6516.
I don't know if there are any other bugs in the threaded code that
would prevent my thesis from compiling.

Is there some cost to leaving the old code in until e.g. #6516 is fixed?

-- 
John C. McCabe-Dansted

Re: LyX 2.0 release plan

[Pavel Sanda]

John McCabe-Dansted wrote:
> > the dialog which would make me interested is the one which produce
> > backtrace after each crash, so user can put it in our bugzilla.
> > but thats not easy to do i guess.
> 
> Maybe something like the following?
> char buffer[512];
> sprintf(buffer, "(echo set height 0 ; echo bt ; yes q) | gdb
> ./lyx %d",getpid());
> system(buffer);
> (Clearly ./lyx should be replaced with lyx::os::support::utf8_argv(0))
> 
> Seems to work on my Linux box. There is gdb for MingW but I don't know
> if that means it could be made to work on Windows.

you rely not only on gdb but also on bash i think. this wont help on win32.

> I imagine that using Qt dialogs if there is a actual crash (rather
> than an assertion) may be a little risky.

one can launch another binary which just gets lyx backtrace on stdin and 
puts into QEditText.

pavel

Re: LyX 2.0 release plan

[Abdelrazak Younes]

On 06/03/2010 20:32, John McCabe-Dansted wrote:

On Sun, Mar 7, 2010 at 2:10 AM, Abdelrazak Younes  wrote:
   

On 06/03/2010 14:43, Vincent van Ravesteijn wrote:
 

John McCabe-Dansted schreef:
   

On Fri, Mar 5, 2010 at 10:48 PM, Vincent van Ravesteijn - TNW
  wrote:
 

Did we leave the instability period that was expected due to:
- threaded export,
   

IMHO we should
  #define EXPORT_in_THREAD 0
 

No, we should have this.
   

FWIW I put this macro because I was not sure if the feature would converge
to a stable state, but this seems almost OK right now. Lots of people are
awaiting this feature so if we don't intent to go back, what about deleting
the old synchronous export code?
 

Well I can't compile my thesis with EXPORT_in_THREAD 1, due to  #6516.
I don't know if there are any other bugs in the threaded code that
would prevent my thesis from compiling.

Is there some cost to leaving the old code in until e.g. #6516 is fixed?
   


No, we can leave it if this is a blocker of course.

Abdel.