Re: Some thoughts on further development process towards beta and RCs

[Pavel Sanda]

Uwe Stöhr wrote:
  Uwe, I don't like the pressure you make.

 Sorry. I don't want to pressurize anybody.

no problem, asked for feedback and got it :) your impulse closed many bug
yesterday so good move anyway.

i tried to be transparent and listed exactly 4 bugs which are in my opinion
before-beta stuff if we want to keep the meaning of beta. i'm open to discuss
their priority. but beta is not going in next two weeks, sorry.

pavel

Re: RefStyle Patch

[Jean-Pierre Chrétien]

Richard Heck rgheck at comcast.net writes:

 
 
 OK, one last try at a refstyle patch. 
 
 Comments welcome.

Tried on a simple fresh document.
Seems that package ifthen should be included, due to the tests in the preamble.

I'll investigate more with my examples.

-- 
Jean-Pierre

Re: RefStyle Patch

[Richard Heck]

On 10/14/2010 07:47 AM, Jean-Pierre Chrétien wrote:

Richard Heckrgheckat  comcast.net  writes:

   


OK, one last try at a refstyle patch.

Comments welcome.
 

Tried on a simple fresh document.
Seems that package ifthen should be included, due to the tests in the preamble.

   
Thanks. That was in my original tests, of course, but somehow didn't 
make it into the patch.


rh

Re: r35608 - in lyx-devel/trunk: lib/layouts lib/lyx2lyx lib/scripts po src src/frontends/qt4 src/insets

[Pavel Sanda]

Pavel Sanda wrote:
 rgh...@lyx.org wrote:
  Log:
  Get rid of CharStyle:, Custom:, and Element: prefixes, per a
  suggestion of JMarc's. Docs to follow.
 
 i guess there is also something to change in doxy of LFUN_FLEX_INSERT?

ping

 pavel

Re: r35608 - in lyx-devel/trunk: lib/layouts lib/lyx2lyx lib/scripts po src src/frontends/qt4 src/insets

[Richard Heck]

On 10/14/2010 10:04 AM, Pavel Sanda wrote:

Pavel Sanda wrote:
   

rgh...@lyx.org wrote:
 

Log:
Get rid of CharStyle:, Custom:, and Element: prefixes, per a
suggestion of JMarc's. Docs to follow.
   

i guess there is also something to change in doxy of LFUN_FLEX_INSERT?
 

ping

   
I was waiting to see if JMarc has any comment before changing this. I'll 
go ahead and do it now, though.


rh

Re: Some thoughts on further development process towards beta and RCs

[BH]

On Wed, Oct 13, 2010 at 12:13 PM, John McCabe-Dansted gma...@gmail.com wrote:
 Hi, a patch for #6597 is sitting at:
  http://www.lyx.org/trac/attachment/ticket/6597/GuiClipboard.cpp.2.patch

 I'd like to get this patch in. We discussed the patch and agreed it
 looked pretty reasonable, but there was some theoretical discussion
 as to whether the patch would break cut-and-paste on MacOS X.
 http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg159800.html

 Would someone with MacOS X like to confirm that this patch doesn't
 break pasting into LyX from other applications?

I've tested the patch on Mac OS 10.6, current svn of LyX trunk, and
Qt-4.7. Cutting and pasting both from LyX to other programs and from
other programs to LyX works fine from what I can see.

BH

Re: Some thoughts on further development process towards beta and RCs

[Pavel Sanda]

BH wrote:
  Would someone with MacOS X like to confirm that this patch doesn't
  break pasting into LyX from other applications?
 
 I've tested the patch on Mac OS 10.6, current svn of LyX trunk, and
 Qt-4.7. Cutting and pasting both from LyX to other programs and from
 other programs to LyX works fine from what I can see.

the most problematic cases of our copypaste typically happen when
middle button is used for getting, or puting stuff from/into another
applications and when more lyx instances are used. dunno whether
the patch affects these use cases... its very fragile stuff and i
remeber having some hard debugging nights, thats why i fear to take
responsibility for this patch :)

pavel

Re: Some thoughts on further development process towards beta and RCs

[John McCabe-Dansted]

On Thu, Oct 14, 2010 at 11:53 PM, Pavel Sanda sa...@lyx.org wrote:
 I've tested the patch on Mac OS 10.6, current svn of LyX trunk, and
 Qt-4.7. Cutting and pasting both from LyX to other programs and from
 other programs to LyX works fine from what I can see.

 the most problematic cases of our copypaste typically happen when
 middle button is used for getting, or puting stuff from/into another
 applications and when more lyx instances are used. dunno whether
 the patch affects these use cases... its very fragile stuff and i
 remeber having some hard debugging nights, thats why i fear to take
 responsibility for this patch :)

This patch shouldn't affect middle click, as it only caches the
clipboard status, not the Primary Selection. Also, I have been using
the patch for months, use middle-click extensively, and haven't
noticed anything wrong. I think this patch has also been sitting in
Vincent's tree. I presume he hasn't noticed any regressions.

-- 
John C. McCabe-Dansted

Re: Some thoughts on further development process towards beta and RCs

[Stephan Witt]

Am 14.10.2010 um 17:19 schrieb BH:

 On Wed, Oct 13, 2010 at 12:13 PM, John McCabe-Dansted gma...@gmail.com 
 wrote:
 Hi, a patch for #6597 is sitting at:
  http://www.lyx.org/trac/attachment/ticket/6597/GuiClipboard.cpp.2.patch
 
 I'd like to get this patch in. We discussed the patch and agreed it
 looked pretty reasonable, but there was some theoretical discussion
 as to whether the patch would break cut-and-paste on MacOS X.
 http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg159800.html
 
 Would someone with MacOS X like to confirm that this patch doesn't
 break pasting into LyX from other applications?
 
 I've tested the patch on Mac OS 10.6, current svn of LyX trunk, and
 Qt-4.7. Cutting and pasting both from LyX to other programs and from
 other programs to LyX works fine from what I can see.

+1 for trunk + Qt-4.6.2 on Mac OS 10.6

Stephan

Re: r35637 - lyx-devel/trunk/src

[Abdelrazak Younes]

On 13/10/2010 20:27, rgh...@lyx.org wrote:

Author: rgheck
Date: Wed Oct 13 20:27:40 2010
New Revision: 35637
URL: http://www.lyx.org/trac/changeset/35637

Log:
Why have an argument in an anonymous method if you aren't going to use
it?
   


unfinished iterative cleanups...

Good that you add another iteration :-)

Abdel.

Re: r35634 - lyx-devel/trunk/src

[Abdelrazak Younes]

On 13/10/2010 20:06, rgh...@lyx.org wrote:

Author: rgheck
Date: Wed Oct 13 20:06:01 2010
New Revision: 35634
URL: http://www.lyx.org/trac/changeset/35634

Log:
The inset DOES know what kind of update is needed, and it is supposed to
be telling us. I'm not sure why this wasn't being used any more.
   


Because the DispatchResult passing is a new thing? Introduced recently 
by JMarc or Vincent IIRC.


Abdel.

Re: r35635 - lyx-devel/trunk/src

[Abdelrazak Younes]

On 13/10/2010 20:19, rgh...@lyx.org wrote:

  Why isn't
there any documenation here?
   


This is becoming a mantra, the LyX mantra!

Abdel.

Re: r35638 - lyx-devel/trunk/src

[Abdelrazak Younes]

On 13/10/2010 20:30, rgh...@lyx.org wrote:

Author: rgheck
Date: Wed Oct 13 20:30:37 2010
New Revision: 35638
URL: http://www.lyx.org/trac/changeset/35638

Log:
Anonymize some things.
   


Not needed if the function is static; but it does not hurt of course.

Abdel.

Re: r35639 - lyx-devel/trunk/src

[Abdelrazak Younes]

On 13/10/2010 21:35, Jean-Marc Lasgouttes wrote:

Le 13 oct. 10 à 20:53, rgh...@lyx.org a écrit :

Author: rgheck
Date: Wed Oct 13 20:53:41 2010
New Revision: 35639
URL: http://www.lyx.org/trac/changeset/35639

Log:
Change how some of the updating stuff is handled in lyxfind. I had no
idea what a mess this was.


Wise move. This is one of the ancient Very Bad Pieces of Code.


+1

FWIW the reason why I never completed this cleanup is because I really 
wanted to implement Paragraph::find() and Text::find(), same with 
replace. That was before my family and my job filled in all my spare 
time :-)


Abdel.

Re: r35639 - lyx-devel/trunk/src

[Richard Heck]

On 10/14/2010 12:52 PM, Abdelrazak Younes wrote:

On 13/10/2010 21:35, Jean-Marc Lasgouttes wrote:

Le 13 oct. 10 à 20:53, rgh...@lyx.org a écrit :

Author: rgheck
Date: Wed Oct 13 20:53:41 2010
New Revision: 35639
URL: http://www.lyx.org/trac/changeset/35639

Log:
Change how some of the updating stuff is handled in lyxfind. I had no
idea what a mess this was.


Wise move. This is one of the ancient Very Bad Pieces of Code.


+1

FWIW the reason why I never completed this cleanup is because I really 
wanted to implement Paragraph::find() and Text::find(), same with 
replace. That was before my family and my job filled in all my spare 
time :-)


If you could find the time to fix the three things flagged in r35652, 
I'd really appreciate it. Then I will have to tackle GuiCompleter, where 
there are several direct calls to processUpdateFlags(). If you don't 
have time to do it, then advice to me on how to do it might be sufficient.


Richard

Re: r35575 - lyx-devel/trunk/src

[Stephan Witt]

Am 08.10.2010 um 16:37 schrieb Stephan Witt:

 Am 08.10.2010 um 16:19 schrieb Pavel Sanda:
 
 Stephan Witt wrote:
 but i still dont like we dont care about this consitently. the solution 
 would be to push
 this conde into lyxvc.
 
 I wouldn't vote against such move. :-)
 
 can you move it please?
 
 Yes, I do it when working on the backport of my changes.

I have a general question about the VCBackend code.
The CVS and SVN classes have a file_ member variable.
Am I right that this is the reference to the owner_ file?
Most of the time the file of the owner_ is used and sometimes
it's file_... Is it useful to have both of them?
What should be preferred if it is useful?

 
 please can you update our additional manual with the current state of art
 for CVS and also suggest typical lyx use cases for cvs regime? mean cvs
 user has probaly no idea about cvs edit and so on.
 
 also add some note into revision control item in newinlyx20 wiki...
 
 This I can do. I'm on vacation next two weeks. Some time should be 
 available...

Currently I have less time then I expected.
But it's not forgotten.

Stephan

Re: r35639 - lyx-devel/trunk/src

[Abdelrazak Younes]

On 14/10/2010 19:20, Richard Heck wrote:

On 10/14/2010 12:52 PM, Abdelrazak Younes wrote:

On 13/10/2010 21:35, Jean-Marc Lasgouttes wrote:

Le 13 oct. 10 à 20:53, rgh...@lyx.org a écrit :

Author: rgheck
Date: Wed Oct 13 20:53:41 2010
New Revision: 35639
URL: http://www.lyx.org/trac/changeset/35639

Log:
Change how some of the updating stuff is handled in lyxfind. I had no
idea what a mess this was.


Wise move. This is one of the ancient Very Bad Pieces of Code.


+1

FWIW the reason why I never completed this cleanup is because I 
really wanted to implement Paragraph::find() and Text::find(), same 
with replace. That was before my family and my job filled in all my 
spare time :-)


If you could find the time to fix the three things flagged in r35652, 
I'd really appreciate it.


Not in the next weeks I'm afraid.

Then I will have to tackle GuiCompleter, where there are several 
direct calls to processUpdateFlags(). If you don't have time to do it, 
then advice to me on how to do it might be sufficient.


This should be quite easy for you I guess. In the case of spellcheck, it 
is just a matter of creating an lfun, ideally handled by Text: 
LFUN_SPELLING_CHECK. This would take as parameter the cursor position.
In DispatchResult maybe we need a new flag to indicate that a selection 
should be done; or maybe two pos_type begin_selection and end_selection 
that would be used to set a selection, only if different from -1.
For GuiErrorList we also need a new lfun: LFUN_RANGE_SELECT that would 
would take as parameter the position and the range (positive or negative 
ideally).


Abdel.

Re: r35575 - lyx-devel/trunk/src

[Pavel Sanda]

Stephan Witt wrote:
  Yes, I do it when working on the backport of my changes.
 
 I have a general question about the VCBackend code.
 The CVS and SVN classes have a file_ member variable.
 Am I right that this is the reference to the owner_ file?
 Most of the time the file of the owner_ is used and sometimes
 it's file_... Is it useful to have both of them?
 What should be preferred if it is useful?

owner_ is buffer - something opened in lyx; file_ is just filename
which exist independently whether the file is opened, closed, reloaded
whatsoever... i would need to dig into the code if you want some
specific info.

pavel

Re: r35608 - in lyx-devel/trunk: lib/layouts lib/lyx2lyx lib/scripts po src src/frontends/qt4 src/insets

[Jean-Marc Lasgouttes]

Le 14 oct. 10 à 16:25, Richard Heck a écrit :
I was waiting to see if JMarc has any comment before changing this.  
I'll go ahead and do it now, though.


Sorry I did not find the time. This is not the code I thought it would  
be
but your explanations look convincing. I should know better and look  
beyond

convinving explanations, but I run out of time.

JMarc

Re: r35575 - lyx-devel/trunk/src

[Stephan Witt]

Am 14.10.2010 um 22:43 schrieb Pavel Sanda:

 Stephan Witt wrote:
 Yes, I do it when working on the backport of my changes.
 
 I have a general question about the VCBackend code.
 The CVS and SVN classes have a file_ member variable.
 Am I right that this is the reference to the owner_ file?
 Most of the time the file of the owner_ is used and sometimes
 it's file_... Is it useful to have both of them?
 What should be preferred if it is useful?
 
 owner_ is buffer - something opened in lyx; file_ is just filename
 which exist independently whether the file is opened, closed, reloaded
 whatsoever...

The owner_ variable points to the buffer, of course. 
Most of the time VC implementation uses the filename of the buffer.
But I cannot see what sense the file_ variable of the VC instance has.
One can drop it - or use it consequently - I'd say.
 
 i would need to dig into the code if you want some
 specific info.

If possible... that would be nice.

Stephan

Re: Some thoughts on further development process towards beta and RCs

[Pavel Sanda]

Uwe Stöhr wrote:
> > Uwe, I don't like the pressure you make.
>
> Sorry. I don't want to pressurize anybody.

no problem, asked for feedback and got it :) your impulse closed many bug
yesterday so good move anyway.

i tried to be transparent and listed exactly 4 bugs which are in my opinion
before-beta stuff if we want to keep the meaning of beta. i'm open to discuss
their priority. but beta is not going in next two weeks, sorry.

pavel

Re: RefStyle Patch

[Jean-Pierre Chrétien]

Richard Heck  comcast.net> writes:

> 
> 
> OK, one last try at a refstyle patch. 
> 
> Comments welcome.

Tried on a simple fresh document.
Seems that package ifthen should be included, due to the tests in the preamble.

I'll investigate more with my examples.

-- 
Jean-Pierre

Re: RefStyle Patch

[Richard Heck]

On 10/14/2010 07:47 AM, Jean-Pierre Chrétien wrote:

Richard Heck  writes:

   


OK, one last try at a refstyle patch.

Comments welcome.
 

Tried on a simple fresh document.
Seems that package ifthen should be included, due to the tests in the preamble.

   
Thanks. That was in my original tests, of course, but somehow didn't 
make it into the patch.


rh

Re: r35608 - in lyx-devel/trunk: lib/layouts lib/lyx2lyx lib/scripts po src src/frontends/qt4 src/insets

[Pavel Sanda]

Pavel Sanda wrote:
> rgh...@lyx.org wrote:
> > Log:
> > Get rid of "CharStyle:", "Custom:", and "Element:" prefixes, per a
> > suggestion of JMarc's. Docs to follow.
> 
> i guess there is also something to change in doxy of LFUN_FLEX_INSERT?

ping

> pavel

Re: r35608 - in lyx-devel/trunk: lib/layouts lib/lyx2lyx lib/scripts po src src/frontends/qt4 src/insets

[Richard Heck]

On 10/14/2010 10:04 AM, Pavel Sanda wrote:

Pavel Sanda wrote:
   

rgh...@lyx.org wrote:
 

Log:
Get rid of "CharStyle:", "Custom:", and "Element:" prefixes, per a
suggestion of JMarc's. Docs to follow.
   

i guess there is also something to change in doxy of LFUN_FLEX_INSERT?
 

ping

   
I was waiting to see if JMarc has any comment before changing this. I'll 
go ahead and do it now, though.


rh

Re: Some thoughts on further development process towards beta and RCs

[BH]

On Wed, Oct 13, 2010 at 12:13 PM, John McCabe-Dansted  wrote:
> Hi, a patch for #6597 is sitting at:
>  http://www.lyx.org/trac/attachment/ticket/6597/GuiClipboard.cpp.2.patch
>
> I'd like to get this patch in. We discussed the patch and agreed it
> looked "pretty reasonable", but there was some theoretical discussion
> as to whether the patch would break cut-and-paste on MacOS X.
> http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg159800.html
>
> Would someone with MacOS X like to confirm that this patch doesn't
> break pasting into LyX from other applications?

I've tested the patch on Mac OS 10.6, current svn of LyX trunk, and
Qt-4.7. Cutting and pasting both from LyX to other programs and from
other programs to LyX works fine from what I can see.

BH

Re: Some thoughts on further development process towards beta and RCs

[Pavel Sanda]

BH wrote:
> > Would someone with MacOS X like to confirm that this patch doesn't
> > break pasting into LyX from other applications?
> 
> I've tested the patch on Mac OS 10.6, current svn of LyX trunk, and
> Qt-4.7. Cutting and pasting both from LyX to other programs and from
> other programs to LyX works fine from what I can see.

the most problematic cases of our copy typically happen when
middle button is used for getting, or puting stuff from/into another
applications and when more lyx instances are used. dunno whether
the patch affects these use cases... its very fragile stuff and i
remeber having some hard debugging nights, thats why i fear to take
responsibility for this patch :)

pavel

Re: Some thoughts on further development process towards beta and RCs

[John McCabe-Dansted]

On Thu, Oct 14, 2010 at 11:53 PM, Pavel Sanda  wrote:
>> I've tested the patch on Mac OS 10.6, current svn of LyX trunk, and
>> Qt-4.7. Cutting and pasting both from LyX to other programs and from
>> other programs to LyX works fine from what I can see.
>
> the most problematic cases of our copy typically happen when
> middle button is used for getting, or puting stuff from/into another
> applications and when more lyx instances are used. dunno whether
> the patch affects these use cases... its very fragile stuff and i
> remeber having some hard debugging nights, thats why i fear to take
> responsibility for this patch :)

This patch shouldn't affect middle click, as it only caches the
clipboard status, not the "Primary Selection". Also, I have been using
the patch for months, use middle-click extensively, and haven't
noticed anything wrong. I think this patch has also been sitting in
Vincent's tree. I presume he hasn't noticed any regressions.

-- 
John C. McCabe-Dansted

Re: Some thoughts on further development process towards beta and RCs

[Stephan Witt]

Am 14.10.2010 um 17:19 schrieb BH:

> On Wed, Oct 13, 2010 at 12:13 PM, John McCabe-Dansted  
> wrote:
>> Hi, a patch for #6597 is sitting at:
>>  http://www.lyx.org/trac/attachment/ticket/6597/GuiClipboard.cpp.2.patch
>> 
>> I'd like to get this patch in. We discussed the patch and agreed it
>> looked "pretty reasonable", but there was some theoretical discussion
>> as to whether the patch would break cut-and-paste on MacOS X.
>> http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg159800.html
>> 
>> Would someone with MacOS X like to confirm that this patch doesn't
>> break pasting into LyX from other applications?
> 
> I've tested the patch on Mac OS 10.6, current svn of LyX trunk, and
> Qt-4.7. Cutting and pasting both from LyX to other programs and from
> other programs to LyX works fine from what I can see.

+1 for trunk + Qt-4.6.2 on Mac OS 10.6

Stephan

Re: r35637 - lyx-devel/trunk/src

[Abdelrazak Younes]

On 13/10/2010 20:27, rgh...@lyx.org wrote:

Author: rgheck
Date: Wed Oct 13 20:27:40 2010
New Revision: 35637
URL: http://www.lyx.org/trac/changeset/35637

Log:
Why have an argument in an anonymous method if you aren't going to use
it?
   


unfinished iterative cleanups...

Good that you add another iteration :-)

Abdel.

Re: r35634 - lyx-devel/trunk/src

[Abdelrazak Younes]

On 13/10/2010 20:06, rgh...@lyx.org wrote:

Author: rgheck
Date: Wed Oct 13 20:06:01 2010
New Revision: 35634
URL: http://www.lyx.org/trac/changeset/35634

Log:
The inset DOES know what kind of update is needed, and it is supposed to
be telling us. I'm not sure why this wasn't being used any more.
   


Because the DispatchResult passing is a new thing? Introduced recently 
by JMarc or Vincent IIRC.


Abdel.

Re: r35635 - lyx-devel/trunk/src

[Abdelrazak Younes]

On 13/10/2010 20:19, rgh...@lyx.org wrote:

  Why isn't
there any documenation here?
   


This is becoming a mantra, the LyX mantra!

Abdel.

Re: r35638 - lyx-devel/trunk/src

[Abdelrazak Younes]

On 13/10/2010 20:30, rgh...@lyx.org wrote:

Author: rgheck
Date: Wed Oct 13 20:30:37 2010
New Revision: 35638
URL: http://www.lyx.org/trac/changeset/35638

Log:
Anonymize some things.
   


Not needed if the function is static; but it does not hurt of course.

Abdel.

Re: r35639 - lyx-devel/trunk/src

[Abdelrazak Younes]

On 13/10/2010 21:35, Jean-Marc Lasgouttes wrote:

Le 13 oct. 10 à 20:53, rgh...@lyx.org a écrit :

Author: rgheck
Date: Wed Oct 13 20:53:41 2010
New Revision: 35639
URL: http://www.lyx.org/trac/changeset/35639

Log:
Change how some of the updating stuff is handled in lyxfind. I had no
idea what a mess this was.


Wise move. This is one of the ancient Very Bad Pieces of Code.


+1

FWIW the reason why I never completed this cleanup is because I really 
wanted to implement Paragraph::find() and Text::find(), same with 
replace. That was before my family and my job filled in all my spare 
time :-)


Abdel.

Re: r35639 - lyx-devel/trunk/src

[Richard Heck]

On 10/14/2010 12:52 PM, Abdelrazak Younes wrote:

On 13/10/2010 21:35, Jean-Marc Lasgouttes wrote:

Le 13 oct. 10 à 20:53, rgh...@lyx.org a écrit :

Author: rgheck
Date: Wed Oct 13 20:53:41 2010
New Revision: 35639
URL: http://www.lyx.org/trac/changeset/35639

Log:
Change how some of the updating stuff is handled in lyxfind. I had no
idea what a mess this was.


Wise move. This is one of the ancient Very Bad Pieces of Code.


+1

FWIW the reason why I never completed this cleanup is because I really 
wanted to implement Paragraph::find() and Text::find(), same with 
replace. That was before my family and my job filled in all my spare 
time :-)


If you could find the time to fix the three things flagged in r35652, 
I'd really appreciate it. Then I will have to tackle GuiCompleter, where 
there are several direct calls to processUpdateFlags(). If you don't 
have time to do it, then advice to me on how to do it might be sufficient.


Richard

Re: r35575 - lyx-devel/trunk/src

[Stephan Witt]

Am 08.10.2010 um 16:37 schrieb Stephan Witt:

> Am 08.10.2010 um 16:19 schrieb Pavel Sanda:
> 
>> Stephan Witt wrote:
 but i still dont like we dont care about this consitently. the solution 
 would be to push
 this conde into lyxvc.
>>> 
>>> I wouldn't vote against such move. :-)
>> 
>> can you move it please?
> 
> Yes, I do it when working on the backport of my changes.

I have a general question about the VCBackend code.
The CVS and SVN classes have a file_ member variable.
Am I right that this is the reference to the owner_ file?
Most of the time the file of the owner_ is used and sometimes
it's file_... Is it useful to have both of them?
What should be preferred if it is useful?

>> 
 please can you update our additional manual with the current state of art
 for CVS and also suggest typical lyx use cases for cvs regime? mean cvs
 user has probaly no idea about cvs edit and so on.
 
 also add some note into revision control item in newinlyx20 wiki...
>>> 
>>> This I can do. I'm on vacation next two weeks. Some time should be 
>>> available...

Currently I have less time then I expected.
But it's not forgotten.

Stephan

Re: r35639 - lyx-devel/trunk/src

[Abdelrazak Younes]

On 14/10/2010 19:20, Richard Heck wrote:

On 10/14/2010 12:52 PM, Abdelrazak Younes wrote:

On 13/10/2010 21:35, Jean-Marc Lasgouttes wrote:

Le 13 oct. 10 à 20:53, rgh...@lyx.org a écrit :

Author: rgheck
Date: Wed Oct 13 20:53:41 2010
New Revision: 35639
URL: http://www.lyx.org/trac/changeset/35639

Log:
Change how some of the updating stuff is handled in lyxfind. I had no
idea what a mess this was.


Wise move. This is one of the ancient Very Bad Pieces of Code.


+1

FWIW the reason why I never completed this cleanup is because I 
really wanted to implement Paragraph::find() and Text::find(), same 
with replace. That was before my family and my job filled in all my 
spare time :-)


If you could find the time to fix the three things flagged in r35652, 
I'd really appreciate it.


Not in the next weeks I'm afraid.

Then I will have to tackle GuiCompleter, where there are several 
direct calls to processUpdateFlags(). If you don't have time to do it, 
then advice to me on how to do it might be sufficient.


This should be quite easy for you I guess. In the case of spellcheck, it 
is just a matter of creating an lfun, ideally handled by Text: 
LFUN_SPELLING_CHECK. This would take as parameter the cursor position.
In DispatchResult maybe we need a new flag to indicate that a selection 
should be done; or maybe two pos_type begin_selection and end_selection 
that would be used to set a selection, only if different from -1.
For GuiErrorList we also need a new lfun: LFUN_RANGE_SELECT that would 
would take as parameter the position and the range (positive or negative 
ideally).


Abdel.

Re: r35575 - lyx-devel/trunk/src

[Pavel Sanda]

Stephan Witt wrote:
> > Yes, I do it when working on the backport of my changes.
> 
> I have a general question about the VCBackend code.
> The CVS and SVN classes have a file_ member variable.
> Am I right that this is the reference to the owner_ file?
> Most of the time the file of the owner_ is used and sometimes
> it's file_... Is it useful to have both of them?
> What should be preferred if it is useful?

owner_ is buffer - something opened in lyx; file_ is just filename
which exist independently whether the file is opened, closed, reloaded
whatsoever... i would need to dig into the code if you want some
specific info.

pavel

Re: r35608 - in lyx-devel/trunk: lib/layouts lib/lyx2lyx lib/scripts po src src/frontends/qt4 src/insets

[Jean-Marc Lasgouttes]

Le 14 oct. 10 à 16:25, Richard Heck a écrit :
I was waiting to see if JMarc has any comment before changing this.  
I'll go ahead and do it now, though.


Sorry I did not find the time. This is not the code I thought it would  
be
but your explanations look convincing. I should know better and look  
beyond

convinving explanations, but I run out of time.

JMarc

Re: r35575 - lyx-devel/trunk/src

[Stephan Witt]

Am 14.10.2010 um 22:43 schrieb Pavel Sanda:

> Stephan Witt wrote:
>>> Yes, I do it when working on the backport of my changes.
>> 
>> I have a general question about the VCBackend code.
>> The CVS and SVN classes have a file_ member variable.
>> Am I right that this is the reference to the owner_ file?
>> Most of the time the file of the owner_ is used and sometimes
>> it's file_... Is it useful to have both of them?
>> What should be preferred if it is useful?
> 
> owner_ is buffer - something opened in lyx; file_ is just filename
> which exist independently whether the file is opened, closed, reloaded
> whatsoever...

The owner_ variable "points" to the buffer, of course. 
Most of the time VC implementation uses the filename of the buffer.
But I cannot see what sense the file_ variable of the VC instance has.
One can drop it - or use it consequently - I'd say.
 
> i would need to dig into the code if you want some
> specific info.

If possible... that would be nice.

Stephan