Re: Inset handling question

[Abdelrazak Younes]

On 10/28/2010 01:51 AM, Uwe Stöhr wrote:

 You are going forward... you should go backward.

Ah, OK.
When I replace ++it by --it the compiler quites with the message 
that there are unresolved externals because a variable beginning with 
-- doesn't exist.


Then it is declared but not implemented...


This is strange because I thought that -- can be used the same way as ++.


No, this has to be a different method.



 Also cur.inset() is 'this' really.

I tried this but this doesn't compile:

D:\LyXSVN\lyx-devel\src\insets\InsetTabular.cpp(4318) : error C2664: 
'lyx::inset
_iterator_begin' : cannot convert parameter 1 from 'const 
lyx::InsetTabular *con

st ' to 'lyx::Inset '


'this' is 'Inset *' so in this cas you must use '*this'.



 But I don't like use of InsetIterator in this case.

Why is InsetIterator no good solution?


Because it is heavy.



 You can just use the Cursor starting at position 0...

I don't understand yet how the cursor stuff works. I can move the 
cursor stepwise through the table cells but how do I move it outside 
of the table to check if I'm then in a float?


You have to go up in the Cursor slices. Use DocIterator::operator[]. The 
last element of the DocIterator slices is the current cursor position; 
the first element is the position in the outer text inset.



(Damn, I permanently hit my programming skills limits.)


The DocIterator stuff is documented somewhere in the Wiki. You must read 
that before doing anything else.


Abdel.

Re: Remove name from param2string and friends

[Abdelrazak Younes]

On 10/28/2010 03:54 AM, Richard Heck wrote:

On 10/27/2010 08:00 PM, Vincent van Ravesteijn wrote:
 As far as I can see, this name parameter is not used, because 
InsetCommandParams already has a insetCode associated with it.


Is it ok to remove it then and to clean up a lot again ?

see:
http://gitorious.org/lyx/lyx/commit/f7da26338d03df0149b8284e4750857f6495787c 

http://gitorious.org/lyx/lyx/commit/ab5f453397bb2cada9ed248b2e079b748fa03489 

http://gitorious.org/lyx/lyx/commit/ae44ea46eb0bf7da75b2dee4d8b8a4f9559b53f1 




If it seems to work, it should be OK, I think.


I agree. But make sure insetCode is properly initialized everywhere 
though...


Abdel.

Re: Inset handling question

[Abdelrazak Younes]

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

On 10/28/2010 01:51 AM, Uwe Stöhr wrote:

 You can just use the Cursor starting at position 0...

I don't understand yet how the cursor stuff works. I can move the 
cursor stepwise through the table cells but how do I move it outside 
of the table to check if I'm then in a float?


You have to go up in the Cursor slices. Use DocIterator::operator[]. 
The last element of the DocIterator slices is the current cursor 
position; the first element is the position in the outer text inset.


I forgot to say: you can just use 
cursor().innerInsetOfType(FLOAT_CODE)... If the returned inset pointer 
is different from 0 then you are inside a float.


Abdel.

Re: RefStyle Patch

[Jean-Pierre Chrétien]

Jean-Pierre Chrétien a écrit :

Richard Heck a écrit :

On 10/27/2010 04:17 AM, Jean-Pierre Chrétien wrote:


When I look at the exported latex file test_french_refstyle.tex, I see this:

\...@ifundefined{   hmref}
  {\def\RSthmtxt{theorem~}\newref{thm}{name = \RSthmtxt}}

which creates the crossrefs for theorems.

This works in my example beacuse the test is always true, but the
code in LaTeXFeatures.cpp should read

   \...@ifundefined{thmref}\n
  {\\def\\RSthmtxt{theorem~}\\newref{thm}{name = \\RSthmtxt}}\n

instead of

   \...@ifundefined{\thmref}\n
  {\\def\\RSthmtxt{theorem~}\\newref{thm}{name = \\RSthmtxt}}\n

Right ?

--
Jean-Pierre

Re: announce: template to write Ph.D. theses with LyX

[Uwe Stöhr]

Am 28.10.2010 06:56, schrieb Waluyo Adi Siswanto:


Actually all lists in my thesis template is in frontmatter, I guess
you mean frontmatter.


Yes.


Anyway, in users perspective; it might be useful if the lyx templates
are grouped into three types (folders): articles, books, and theses.
When users open new documents from templates, they will see three
folders.


A thesis is basically a book. But even this statement is not always 
correct. There are different types of theses: for Bachelor, Master, 
Diploma, Ph.D., ...


My experience is that for short theses (like a 30 page Bachelor thesis) 
using the article style is advantageous. I therefore designed the thesis 
template to be able to easily change the document class from KOMA-script 
book to article. OK, this can surely improved and users will report us 
what they want to be changed once LyX 2.0 is out.



We have already various article templates, but don't have thesis and
books. So my suggestion, under thesis and books there are also several
examples. Users can choose which one they can start with to customize.


Until now we haven't grouped the templates. When somebody wants to write 
a letter, he will only look at the letter templates. But you are right, 
this becomes difficult with an increasing number of templates. What we 
can indeed do is to group the templates folder with subfolders for


- letters
- CVs
- Journal articles
- theses

regards Uwe

Re: longtable in LyXHTML(trunk)

[Richard Heck]

On 10/28/2010 01:27 AM, Kornel Benko wrote:

Hi Richard,
exporting (or displaying) longtables in LyXHTML-format discards the 
table-header.
Export through other format (e.g. PDF (pdflatex)) is ok.
Normal tables export is fine though.

   

Can you put this in trac? I hope to have time to work on HTML shortly.

If you could add a simple test file that'd be even better. I never use 
these so didn't get to test it.


Richard

Re: RefStyle Patch

[Richard Heck]

On 10/28/2010 05:36 AM, Jean-Pierre Chrétien wrote:

Jean-Pierre Chrétien a écrit :

Richard Heck a écrit :

On 10/27/2010 04:17 AM, Jean-Pierre Chrétien wrote:


When I look at the exported latex file test_french_refstyle.tex, I see 
this:


\...@ifundefined{hmref}
  {\def\RSthmtxt{theorem~}\newref{thm}{name = \RSthmtxt}}

which creates the crossrefs for theorems.

This works in my example beacuse the test is always true, but the
code in LaTeXFeatures.cpp should read

   \...@ifundefined{thmref}\n
  {\\def\\RSthmtxt{theorem~}\\newref{thm}{name = \\RSthmtxt}}\n

instead of

   \...@ifundefined{\thmref}\n
  {\\def\\RSthmtxt{theorem~}\\newref{thm}{name = \\RSthmtxt}}\n

Right ?


I'm not seeing the difference

rh

Re: Git repos on Gitorious

[Abdelrazak Younes]

On 10/27/2010 07:55 AM, Vincent van Ravesteijn wrote:
 Hi all,

 Just to inform you. I made a git repository on gitorious.

Hi Vincent,

I think you should keep 'master' in line with svn/trunk and do your 
personal commit in a new 'vfr' branch. We could also create a new common 
branch for git only development. This branch would be used by people who 
would like to switch to git entirely and would be merged into master 
(and svn/trunk) periodically (everyday?). Or we could do the opposite: 
create a read-only branch svn and merge periodically commit from 
master where main development would happen.


Abdel.

Re: RefStyle Patch

[Richard Heck]

I'm not seeing the difference


Anyway, I'm going to do the other thing I suggested, I think.

Richard

Re: Git repos on Gitorious

[Vincent van Ravesteijn]

 I think you should keep 'master' in line with svn/trunk and do your personal
 commit in a new 'vfr' branch.

Yes, that was the idea. However, I got a little screwed by someone
renaming InsetNomencl.cpp to InsetNomenclature.cpp. ;)..

Well, it's either me that didn't write the scripts well enough, or Git
has a bit uncomfortabilities (?) with deleted files and/or Windows.
That's why I was messing up when pushing the commits for the
InsetCommandParams patches.

Also, I have to sort of manually update the git to the svn server. I
might improve on this, but it's less easy on windows.

 We could also create a new common branch for
 git only development. This branch would be used by people who would like to
 switch to git entirely and would be merged into master (and svn/trunk)
 periodically (everyday?).

That's how Qt works I guess. They also immediately check that
everything compiles before merging.

However, what happens on merge conflicts if someone commits something
to the git server and someone changed a same thing into the svn server
?

Hmm.. if you can automatically merge.. why not everytime somebody
commits something ?

I feel that it's not suitable for us to wait for one day to see other
one's commits. That does not help checking up on each other, helping
each other out, and so forth.

 Or we could do the opposite: create a read-only
 branch svn and merge periodically commit from master where main
 development would happen.


I like your first proposal more.

On my pc, I have one checkout which is both under svn and git control.
That works quite well if you know what you're doing.

 Abdel.

Vincent

Re: Git repos on Gitorious

[Vincent van Ravesteijn]

 Yes, that was the idea. However, I got a little screwed by someone
 renaming InsetNomencl.cpp to InsetNomenclature.cpp. ;)..

 Well, it's either me that didn't write the scripts well enough, or Git
 has a bit uncomfortabilities (?) with deleted files and/or Windows.
 That's why I was messing up when pushing the commits for the
 InsetCommandParams patches.

I'll try to undo the mess. Nice way to got to learn this git-business
somewhat better.

Do you want access to the repository ?

Vincent

Re: Git repos on Gitorious

[Abdelrazak Younes]

On 10/28/2010 05:24 PM, Vincent van Ravesteijn wrote:

Yes, that was the idea. However, I got a little screwed by someone
renaming InsetNomencl.cpp to InsetNomenclature.cpp. ;)..

Well, it's either me that didn't write the scripts well enough, or Git
has a bit uncomfortabilities (?) with deleted files and/or Windows.
That's why I was messing up when pushing the commits for the
InsetCommandParams patches.
 

I'll try to undo the mess. Nice way to got to learn this git-business
somewhat better.

Do you want access to the repository ?
   


Yes please. I already have an account in gitourious (younes), so I guess 
it is just a matter of allowing me in.


Abdel.

Re: Git repos on Gitorious

[Abdelrazak Younes]

On 10/28/2010 05:46 PM, Abdelrazak Younes wrote:

On 10/28/2010 05:24 PM, Vincent van Ravesteijn wrote:

Yes, that was the idea. However, I got a little screwed by someone
renaming InsetNomencl.cpp to InsetNomenclature.cpp. ;)..

Well, it's either me that didn't write the scripts well enough, or Git
has a bit uncomfortabilities (?) with deleted files and/or Windows.
That's why I was messing up when pushing the commits for the
InsetCommandParams patches.

I'll try to undo the mess. Nice way to got to learn this git-business
somewhat better.

Do you want access to the repository ?


Yes please. I already have an account in gitourious (younes)


Sorry, its abdel (with my gmail address) not younes.

Abdel.

Re: RefStyle Patch

[Jean-Pierre Chrétien]

Richard Heck a écrit :



I'm not seeing the difference


Anyway, I'm going to do the other thing I suggested, I think.


The problem with : has vanished, but theorems are now unknown:
?? is returned in my bug #6609 example.

--
Jean-Pierre

Re: RefStyle Patch

[Richard Heck]

On 10/28/2010 11:55 AM, Jean-Pierre Chrétien wrote:

Richard Heck a écrit :



I'm not seeing the difference


Anyway, I'm going to do the other thing I suggested, I think.


The problem with : has vanished, but theorems are now unknown:
?? is returned in my bug #6609 example.


Took out too much

Are there other things besides theorems we should define that aren't in 
refstyle.cfg?


Is there some way we could provide translatability (in LyX's po files) 
of theorem here?


rh

Label Dialog Broken

[Richard Heck]

The changeover to InsetParamsWidget has borked the label dialog in ways 
I cannot seem to understand. Try this: Create a new section heading, and 
give it the title Hello. Now InsertLabel. You ought to get a dialog 
with sec:Hello, but you get an empty dialog.


Worse problem: If you had something in the dialog previously, you get it 
back again. I.e., LyX invites you to create a duplicate label.


The source of this is that InsetParamsDialog::initializeParams() ignores 
its argument and restores the previous state of the dialog. I don't see 
how this could be over-ridden.


Richard

Re: longtable in LyXHTML(trunk)

[Kornel Benko]

Am Donnerstag 28 Oktober 2010 schrieb Richard Heck:
 On 10/28/2010 01:27 AM, Kornel Benko wrote:
  Hi Richard,
  exporting (or displaying) longtables in LyXHTML-format discards the
  table-header. Export through other format (e.g. PDF (pdflatex)) is ok.
  Normal tables export is fine though.
 
 Can you put this in trac? I hope to have time to work on HTML shortly.
 
 If you could add a simple test file that'd be even better. I never use
 these so didn't get to test it.
 
 Richard

Done. #6995

Kornel


signature.asc
Description: This is a digitally signed message part.

Re: RefStyle Patch

[Kornel Benko]

Am Donnerstag 28 Oktober 2010 schrieb Richard Heck:
 On 10/28/2010 05:36 AM, Jean-Pierre Chrétien wrote:
  Jean-Pierre Chrétien a écrit :
  Richard Heck a écrit :
  On 10/27/2010 04:17 AM, Jean-Pierre Chrétien wrote:
  When I look at the exported latex file test_french_refstyle.tex, I see
  this:
  
  \...@ifundefined{hmref}
  
{\def\RSthmtxt{theorem~}\newref{thm}{name = \RSthmtxt}}
  
  which creates the crossrefs for theorems.
  
  This works in my example beacuse the test is always true, but the
  code in LaTeXFeatures.cpp should read
  
 \...@ifundefined{thmref}\n
 
{\\def\\RSthmtxt{theorem~}\\newref{thm}{name = \\RSthmtxt}}\n
  
  instead of
  
 \...@ifundefined{\thmref}\n
 
{\\def\\RSthmtxt{theorem~}\\newref{thm}{name = \\RSthmtxt}}\n
  
  Right ?
 
 I'm not seeing the difference
 
 rh

The diff is in the first line
...fundefined{thmref}...
vs
...fundefined{\thmref}...

Kornel


signature.asc
Description: This is a digitally signed message part.

Re: Git repos on Gitorious

[Vincent van Ravesteijn]

 Sorry, its abdel (with my gmail address) not younes.

 Abdel.

You're in.

Vincent

Re: longtable in LyXHTML(trunk)

[Richard Heck]

On 10/28/2010 12:12 PM, Kornel Benko wrote:

Am Donnerstag 28 Oktober 2010 schrieb Richard Heck:
   

On 10/28/2010 01:27 AM, Kornel Benko wrote:
 

Hi Richard,
exporting (or displaying) longtables in LyXHTML-format discards the
table-header. Export through other format (e.g. PDF (pdflatex)) is ok.
Normal tables export is fine though.
   

Can you put this in trac? I hope to have time to work on HTML shortly.

If you could add a simple test file that'd be even better. I never use
these so didn't get to test it.

Richard
 

Done. #6995

   

Thanks.

rh

Re: Label Dialog Broken

[Abdelrazak Younes]

On 10/28/2010 06:04 PM, Richard Heck wrote:


The changeover to InsetParamsWidget has borked the label dialog in 
ways I cannot seem to understand. Try this: Create a new section 
heading, and give it the title Hello. Now InsertLabel. You ought to 
get a dialog with sec:Hello, but you get an empty dialog.


Worse problem: If you had something in the dialog previously, you get 
it back again. I.e., LyX invites you to create a duplicate label.


The source of this is that InsetParamsDialog::initializeParams() 
ignores its argument and restores the previous state of the dialog. I 
don't see how this could be over-ridden.


I'll try to fix that ASAP. Or I revert if I can't...

Abdel.

Re: RefStyle Patch

[Jean-Pierre Chrétien]

Richard Heck a écrit :



Are there other things besides theorems we should define that aren't in 
refstyle.cfg?


To be prettyref-coherent, lemmas.



Is there some way we could provide translatability (in LyX's po files) 
of theorem here?


For the time being, we need a restricted set of declarations and translations
in LyX (no plurals, no capitalization).

If you declare all refstyle commands for theorems and such, marked as gettext 
strings, in the code, they will get translated in po files, but this will be 
static in the interface language.


We would like to have strings translated depending upon the current language in 
the document, to allow true babel i18n.


What about providing with LyX an auxiliary file containing the required 
translations (a refstyle.def file if new languages are needed) ?
When fully tested and fairly complete, we could send the file to Danie Els for 
update in CTAN.


--
Jean-Pierre

Re: Git repos on Gitorious

[Abdelrazak Younes]

On 10/28/2010 06:21 PM, Vincent van Ravesteijn wrote:

Sorry, its abdel (with my gmail address) not younes.

Abdel.
 

You're in.
   


Thanks!

Abdel.

Re: RefStyle Patch

[Richard Heck]

On 10/28/2010 12:16 PM, Kornel Benko wrote:


The diff is in the first line
...fundefined{thmref}...
vs
...fundefined{\thmref}...

   

Oh, right, I see.

rh

Re: Label Dialog Broken

[Richard Heck]

On 10/28/2010 12:04 PM, Richard Heck wrote:


The changeover to InsetParamsWidget has borked the label dialog in 
ways I cannot seem to understand. Try this: Create a new section 
heading, and give it the title Hello. Now InsertLabel. You ought to 
get a dialog with sec:Hello, but you get an empty dialog.


Worse problem: If you had something in the dialog previously, you get 
it back again. I.e., LyX invites you to create a duplicate label.


The source of this is that InsetParamsDialog::initializeParams() 
ignores its argument and restores the previous state of the dialog. I 
don't see how this could be over-ridden.



OK, I think I've fixed this at r35886, but please check.

Richard

Re: Label Dialog Broken

[Abdelrazak Younes]

On 10/28/2010 06:31 PM, Richard Heck wrote:

On 10/28/2010 12:04 PM, Richard Heck wrote:


The changeover to InsetParamsWidget has borked the label dialog in 
ways I cannot seem to understand. Try this: Create a new section 
heading, and give it the title Hello. Now InsertLabel. You ought 
to get a dialog with sec:Hello, but you get an empty dialog.


Worse problem: If you had something in the dialog previously, you get 
it back again. I.e., LyX invites you to create a duplicate label.


The source of this is that InsetParamsDialog::initializeParams() 
ignores its argument and restores the previous state of the dialog. I 
don't see how this could be over-ridden.



OK, I think I've fixed this at r35886, but please check.


Yes thanks, that's what I wanted to do. But it can be generalized into 
InsetParamsWidget, no need to implement it in each class:


bool InsetParamsWidget::initialiseParams(std::string const  data)
{
InsetCommandParams p(insetCode());
if (!InsetCommand::string2params(insetName(), data, p))
return false;
paramsToDialog(params);
return true;
}

The insetName() bit could go once Vincent has committed his change about 
string2params().

Of course this also means that a new virtual method needs to be created:

InsetParamsWidget::paramsToDialog(InsetCommandParams const)

I resisted doing this because I thought not all InsetParamsWidget based class 
would use InsetCommandParams.

Abdel.

Re: Label Dialog Broken

[Richard Heck]

On 10/28/2010 01:07 PM, Abdelrazak Younes wrote:

On 10/28/2010 06:31 PM, Richard Heck wrote:

On 10/28/2010 12:04 PM, Richard Heck wrote:


The changeover to InsetParamsWidget has borked the label dialog in 
ways I cannot seem to understand. Try this: Create a new section 
heading, and give it the title Hello. Now InsertLabel. You ought 
to get a dialog with sec:Hello, but you get an empty dialog.


Worse problem: If you had something in the dialog previously, you 
get it back again. I.e., LyX invites you to create a duplicate label.


The source of this is that InsetParamsDialog::initializeParams() 
ignores its argument and restores the previous state of the dialog. 
I don't see how this could be over-ridden.



OK, I think I've fixed this at r35886, but please check.


Yes thanks, that's what I wanted to do. But it can be generalized into 
InsetParamsWidget, no need to implement it in each class:


bool InsetParamsWidget::initialiseParams(std::string const  data)
{
InsetCommandParams p(insetCode());
if (!InsetCommand::string2params(insetName(), data, p))
return false;
paramsToDialog(params);
return true;
}

The insetName() bit could go once Vincent has committed his change 
about string2params().


Of course this also means that a new virtual method needs to be created:

InsetParamsWidget::paramsToDialog(InsetCommandParams const)

I resisted doing this because I thought not all InsetParamsWidget 
based class would use InsetCommandParams.


Perhaps that is a reason to keep it as it is. There's going to be some 
virtual method here that gets overridden in the base classes. In my 
code, it's initialiseParams(); your proposal has it being 
paramsToDialog(ICP). But that has the cost you just mentioned. And 
InsetGraphics and InsetListings are possible candidates.


Andre has occasionally suggested getting rid of the whole ICP business 
in favor of some sort of inheritance. I'm becoming sympathetic and have 
been thinking about doing this early in the 2.1 cycle. So maybe that's 
another reason.


rh

Re: RefStyle Patch

[Richard Heck]

On 10/28/2010 12:24 PM, Jean-Pierre Chrétien wrote:

Richard Heck a écrit :



Are there other things besides theorems we should define that aren't 
in refstyle.cfg?


To be prettyref-coherent, lemmas.



Is there some way we could provide translatability (in LyX's po 
files) of theorem here?


For the time being, we need a restricted set of declarations and 
translations

in LyX (no plurals, no capitalization).

If you declare all refstyle commands for theorems and such, marked as 
gettext strings, in the code, they will get translated in po files, 
but this will be static in the interface language.



Right, no good.

We would like to have strings translated depending upon the current 
language in the document, to allow true babel i18n.


What about providing with LyX an auxiliary file containing the 
required translations (a refstyle.def file if new languages are needed) ?


The problem is knowing how and where to install this. Users can do it, 
of course, but it's harder for us to do.


When fully tested and fairly complete, we could send the file to Danie 
Els for update in CTAN.



Ultimately, this is clearly best.

Perhaps we can do this: (i) Try to get translations from our own 
translators of theorem and lemma, if that covers everything prettyref 
does, that we can hardcode into LaTeXFeatures.cpp, so that we at least 
do as well as refstyle.cfg does with these two; (ii) Send an updated 
version of refstyle.cfg to Els, including those translations. The former 
could be removed after a while, i.e., once we had some sense that the 
new version was common enough.


Richard

externally modified warning

[Julien Rioux]

Hi,

Using svn trunk compiled a few days ago (r35874). I am working on a file 
under svn version control. After modifying the file and wanting to save, 
I get a warning that the file has been externally modified. It has not 
been externally modified.


Recipe:
Open a lyx file under svn
Change something
Save

--
Julien

Re: RefStyle Patch

[Jean-Marc Lasgouttes]

Le 28 oct. 10 à 18:24, Jean-Pierre Chrétien a écrit :
Is there some way we could provide translatability (in LyX's po  
files) of theorem here?


For the time being, we need a restricted set of declarations and  
translations

in LyX (no plurals, no capitalization).

If you declare all refstyle commands for theorems and such, marked  
as gettext strings, in the code, they will get translated in po  
files, but this will be static in the interface language.


No, currently we use some gettext strings (Chapter) in the document  
language.

So we have the needed bits to translate i the language we want.

JMarc

Re: externally modified warning

[Stephan Witt]

Am 28.10.2010 um 21:05 schrieb Julien Rioux:

 Hi,
 
 Using svn trunk compiled a few days ago (r35874). I am working on a file 
 under svn version control. After modifying the file and wanting to save, I 
 get a warning that the file has been externally modified. It has not been 
 externally modified.
 
 Recipe:
 Open a lyx file under svn
 Change something
 Save

Here it doesn't depend on version control.

I set a break in Buffer::isExternallyModified().
The private members timestamp_ and checksum_ equals to 0 (not really 
initialized).
Consequently LyX does not enter Buffer::saveCheckSum()... this call somehow 
gets lost.
I'm afraid the last changes regarding Buffer read operations are the culprit.

Stephan

Re: externally modified warning

[Richard Heck]

On 10/28/2010 04:30 PM, Stephan Witt wrote:

Am 28.10.2010 um 21:05 schrieb Julien Rioux:

   

Hi,

Using svn trunk compiled a few days ago (r35874). I am working on a file under 
svn version control. After modifying the file and wanting to save, I get a 
warning that the file has been externally modified. It has not been externally 
modified.

Recipe:
Open a lyx file under svn
Change something
Save
 

Here it doesn't depend on version control.

I set a break in Buffer::isExternallyModified().
The private members timestamp_ and checksum_ equals to 0 (not really 
initialized).
Consequently LyX does not enter Buffer::saveCheckSum()... this call somehow 
gets lost.
I'm afraid the last changes regarding Buffer read operations are the culprit.

   

I'll fix this. I'm just trying to figure out the best way

rh

Re: Problem with Reconfigure and timeout in SystemCall

[RGH]

On 10/27/2010 12:21 AM, Vincent van Ravesteijn wrote:

Hi,

If I reconfigure and have to wait for MikTeX to download some
packages, LyX will break the Reconfigure script due to some timeout in
SystemCall.

   
The startscript routine seems to put a timeout of 18 on the process. 
If that's milliseconds, then it's only about three minutes.


Richard

Re: [Patch] Rename Invisible in View menu to Hidden|H.

[RGH]

On 10/26/2010 01:12 AM, John McCabe-Dansted wrote:

On Mon, Oct 25, 2010 at 3:55 PM, Jürgen Spitzmüllersp...@lyx.org  wrote:
   

Please let me know of other issues. Note particularly that all fixes that
entail a string change should go in very soon, since we will turn to string
freeze soon.
 

Well this string change doesn't affect branch, but I think we should
rename Invisible as Hidden|H in the View menu as:
1) This allows a natural keyboard accelerator H (I is already used).
2) This matches the terminology Hide tab used in the context menu
when hiding the tab.

   

Committed, thanks.

I'll tell you what I'd also like: A Close-this-document-set option, that 
would close the master and all its children, NOT hide them. If you're 
interested


Richard

Re: announce: template to write Ph.D. theses with LyX

[Waluyo Adi Siswanto]

 A thesis is basically a book. But even this statement is not always correct.
 There are different types of theses: for Bachelor, Master, Diploma, Ph.D.,
 ...

Books usually a bit fancy, chapter headings a bit fancy, not too
formal. For LaTeX expert might not be a problem to customize
everything. But are LyX users all LaTeX users? Some perhaps use LyX
just to get started.


 My experience is that for short theses (like a 30 page Bachelor thesis)
 using the article style is advantageous. I therefore designed the thesis
 template to be able to easily change the document class from KOMA-script
 book to article. OK, this can surely improved and users will report us what
 they want to be changed once LyX 2.0 is out.


Perhaps, rather than one generic style, it could be thesis-typeA,
thesis-typeB without mentioning any university, so users feel
comfortable to choose and to customize it.


 Until now we haven't grouped the templates. When somebody wants to write a
 letter, he will only look at the letter templates. But you are right, this
 becomes difficult with an increasing number of templates. What we can indeed
 do is to group the templates folder with subfolders for

 - letters
 - CVs
 - Journal articles
 - theses


Perhaps using group prefix is another alternative to help users to
find (just like what appears in the document class), so it will be
organized automatically:
article-IEEEtran
article-elsevier
article-...
book-novel
book-art
book-...
cv-simple
cv-fancy
cv-...
letter-modelA
letter-...
presentation-simple
presentation-fancy
presentation-...
thesis-model-A
thesis-model-B
thesis-...
misc-..

Best Regards
Waluyo

Re: r35894 - in lyx-devel/trunk/src: frontends/qt4 insets

[Vincent van Ravesteijn]

 Op 29-10-2010 3:18, uwesto...@lyx.org schreef:

Modified: lyx-devel/trunk/src/insets/InsetTabular.cpp
==
--- lyx-devel/trunk/src/insets/InsetTabular.cpp Fri Oct 29 02:46:21 2010
(r35893)
+++ lyx-devel/trunk/src/insets/InsetTabular.cpp Fri Oct 29 03:18:18 2010
(r35894)
@@ -4313,6 +4313,9 @@
break;

case Tabular::SET_LONGTABULAR:
+   // setting as longtable is not allowed when table is 
inside a float
+   if (cur.innerInsetOfType(FLOAT_CODE) != 0)
+   status.setEnabled(false);
status.setOnOff(tabular.is_long_tabular);
break;



What about Wrap floats ? These have the code WRAP_CODE.

Vincent

Re: Inset handling question

[Uwe Stöhr]

The DocIterator stuff is documented somewhere in the Wiki. You must read that 
before doing
anything else.


Indeed! I found this page:
http://wiki.lyx.org/Devel/Diagrams
and I understand now a lot more. Many thanks Pavel, for your devel Wiki pages!
This explains also my question from the last post:


When I replace ++it by --it the compiler quites with the message that there 
are unresolved
externals because a variable beginning with -- doesn't exist.


InsetIterator is only defined as forward iterator.

---


'this' is 'Inset *' so in this cas you must use '*this'.


I already tried this but this also doesn't compile:

D:\LyXSVN\lyx-devel\src\insets\InsetTabular.cpp(4318) : error C2664: 'lyx::inset_iterator_begin' : 
cannot convert parameter 1 from 'const lyx::InsetTabular' to 'lyx::Inset '

Conversion loses qualifiers

The pointer stuff is still magic to me.

 I forgot to say: you can just use cursor().innerInsetOfType(FLOAT_CODE)

Thanks, I used this for the fix: http://www.lyx.org/trac/changeset/35894

One last question: How do I explicitly specify that the 0 in my patch is a pointer? I mean 0 
could also refer an int or double. The compiler doesn't complain and 0 is the default return value 
of innerInsetOfType but I'm wondering why this works.


many thanks and regards
Uwe

Re: r35894 - in lyx-devel/trunk/src: frontends/qt4 insets

[Uwe Stöhr]

Am 29.10.2010 03:23, schrieb Vincent van Ravesteijn:


What about Wrap floats ? These have the code WRAP_CODE.


Thanks, I forgot the wrapped floats and added this now.

regards Uwe

Re: Inset handling question

[Vincent van Ravesteijn]

One last question: How do I explicitly specify that the 0 in my 
patch is a pointer? I mean 0 could also refer an int or double. The 
compiler doesn't complain and 0 is the default return value of 
innerInsetOfType but I'm wondering why this works.


There is also a small section on this in the codeandadvice manual in 
development/coding.


Some code uses NULL to somehow indicate a null pointer, sometimes you 
see (Inset *) 0, but in the end a pointer is just a number and a number 
can be 0 I guess.


Usually we just do:

Inset * inset = getInset(...);
if (inset)
.

leaving out the check for 0.

See InsetFloat::updateBuffer() at line 209 of InsetFloat.cpp

bool const in_subflt = (it.innerInsetOfType(FLOAT_CODE)
 || it.innerInsetOfType(WRAP_CODE));

if (in_subflt)
...

This makes it slightly more readible as the document mentions before 
states that multiline if statements should be avoided.


Vincent

how to change GUI Language

[Christian del Castillo]

I am also posting these suggestions in the developer's mailing list

This is a post I made at the LaTex forum, fortunately for me the issue was
addressed and solved by a kind user showing a picture of how the menu should
look like in English, from there I was able to GUESSTIMATE which menu
entries I should be manipulating, despite not completely understanding the
language my GUI was in.

I was also going to the mail archive, and the way I understandit is that LyX
will detect the system language and adjust GUI accordingly, however in my
case, the system language was in English, my IP address Korean, the only
Japanese setting I had was in 'Language to display non-unicode characters'
in. So, why did the installer decide on Japanese in the first place?

here is a link to my post on the LaTex forum:
http://www.latex-community.org/forum/viewtopic.php?f=19t=10613p=41052#p41052

=

I think this is a very major issue, as it can affect first time users, and
turn them off completely from the software if not addressed.
This is my first time to try LyX. I installed the package, and while doing
so was not given any option regarding the GUI language. After finally
completing the installation, Voila! the GUI was in JAPANESE!

-Problem 1) I am working in South Korea, I have language sets for my PC set
to enable both Korean and Japanese, but why did the install package choose
to be in Japanese? what would happen if I am Korean, for example, with
absolutely no knowledge of Japanese?
-Problem 2) I can speak, read, and write a LITTLE Japanese, but not that
much. If anybody will give me instructions on how to change the GUI language
I might have trouble looking for the relevant menu entry. If, for some
reason or another the GUI language became Korean, for example, I would have
absolutely no way of being able to look for the menu entry

So I suggest the ff:

Suggestion 1) Give the user the ability to CHOOSE preferred language on
install REGARDLESS of IP address (or whatever method was used to choose GUI
in my current situation)!
Suggestion 2) Make the menu entry to change the GUI language EASY TO FIND
and also IN A LANGUAGE DIFFERENT FROM THE CURRENT GUI, a lot of people would
want to change the GUI because they do not have enough ability in the
language in the first place.

=

Chris del Castillo, PhD
Gyeongsang National University
South Korea




-- 
=
'Christian' Carmelo del Castillo, PhD
Aquatic Biotechnology Center,
Gyeongsang National University, Republic of Korea
TEL: +82-55-751-6732 FAX: +82-55-762-6733
e-mail: chia...@msn.com

Re: Inset handling question

[Uwe Stöhr]

Am 29.10.2010 03:33, schrieb Vincent van Ravesteijn:


One last question: How do I explicitly specify that the 0 in my patch is a pointer? I 
mean 0
could also refer an int or double. The compiler doesn't complain and 0 is the 
default return
value of innerInsetOfType but I'm wondering why this works.


There is also a small section on this in the codeandadvice manual in 
development/coding.


Thanks, I'll have a look at this manual.


Some code uses NULL to somehow indicate a null pointer, sometimes you see 
(Inset *) 0, but in the
end a pointer is just a number and a number can be 0 I guess.

Usually we just do:...


Thanks for the explanation.

regards Uwe

Re: Inset handling question

[Richard Heck]

 On 10/28/10 9:42 PM, Uwe Stöhr wrote:


Some code uses NULL to somehow indicate a null pointer, sometimes you 
see (Inset *) 0, but in the

end a pointer is just a number and a number can be 0 I guess.

Usually we just do:...


Thanks for the explanation.

To maybe explain a little more, C++ will sometimes do what are called 
implicit conversions. This is when there is a standard way to convert 
from one type to another. For example, consider this line:

string str = Hello;
Here, Hello is specified as a literal. This means that it is actually 
a const array of characters, specifically, what C++ calls const char 
*. But there is an obvious sort of conversion from const char * to 
string, and so you can do this without specifying the conversion 
explicitly.


With classes, this happens whenever one class has a constructor that 
takes some other type as an argument. So, for example, suppose we have:

class A {
A();
A(int);
};
So class A has two constructors: A default one, and one that takes an 
int. Then you can do:

A avar;
avar = 2;
This is because the compiler knows how to make an A from an int.

In the string case we have a constructor:
string(const char *);
that is defined in string.h. So the compiler knows how to do that 
conversion.


Essentially the same thing happens with pointers and integers: The 
compiler knows how to make a pointer from an int. These are not classes, 
so there aren't constructors, but the idea is the same.


Richard

Re: externally modified warning

[Stephan Witt]

Am 28.10.2010 um 22:59 schrieb Richard Heck:

 On 10/28/2010 04:30 PM, Stephan Witt wrote:
 Am 28.10.2010 um 21:05 schrieb Julien Rioux:
 
   
 Hi,
 
 Using svn trunk compiled a few days ago (r35874). I am working on a file 
 under svn version control. After modifying the file and wanting to save, I 
 get a warning that the file has been externally modified. It has not been 
 externally modified.
 
 Recipe:
 Open a lyx file under svn
 Change something
 Save
 
 Here it doesn't depend on version control.
 
 I set a break in Buffer::isExternallyModified().
 The private members timestamp_ and checksum_ equals to 0 (not really 
 initialized).
 Consequently LyX does not enter Buffer::saveCheckSum()... this call somehow 
 gets lost.
 I'm afraid the last changes regarding Buffer read operations are the culprit.
   
 I'll fix this. I'm just trying to figure out the best way

Thanks, you fixed it.

Stephan

Re: #6982: on mispelled work, right click and selecting one option produces a crash

[Stephan Witt]

Am 26.10.2010 um 07:50 schrieb LyX Ticket Tracker:

 #6982: on mispelled work, right click and selecting one option produces a 
 crash
 --+-
 Reporter:  urlwolf   |   Owner:  stwitt  
 Type:  defect|  Status:  accepted
 Priority:  high  |   Milestone:  2.0.0   
 Component:  spell | Version:  2.0.0svn
 Severity:  critical  |Keywords:  crash infoneeded
 --+-
 Changes (by stwitt):
 
  * keywords:  crash = crash infoneeded
  * owner:  lasgouttes = stwitt
  * status:  new = accepted
 
 
 Comment:
 
 I tried to reproduce and failed.
 Please add some details.
 What is select one option?
 I tried Ignore all and it did not crash - the spell checker simply
 ignored it afterwards.
 I tried replace with a suggestion - it worked, too.
 What's the platform you are using?
 More detailed instruction to solve this issue would be helpful.
 
 -- 
 Ticket URL: http://www.lyx.org/trac/ticket/6982#comment:3
 The LyX Project http://www.lyx.org/
 LyX -- The Document Processor

What's to do with this ticket?
I think it's not urgent.
I don't understand the recipe, cannot reproduce, asked and got no answer.
So at least the priority is not high...

Stephan

Re: Inset handling question

[Abdelrazak Younes]

On 10/28/2010 01:51 AM, Uwe Stöhr wrote:

> You are going forward... you should go backward.

Ah, OK.
When I replace "++it" by "--it" the compiler quites with the message 
that there are unresolved externals because a variable beginning with 
"--" doesn't exist.


Then it is declared but not implemented...


This is strange because I thought that -- can be used the same way as ++.


No, this has to be a different method.



> Also cur.inset() is 'this' really.

I tried this but this doesn't compile:

D:\LyXSVN\lyx-devel\src\insets\InsetTabular.cpp(4318) : error C2664: 
'lyx::inset
_iterator_begin' : cannot convert parameter 1 from 'const 
lyx::InsetTabular *con

st ' to 'lyx::Inset &'


'this' is 'Inset *' so in this cas you must use '*this'.



> But I don't like use of InsetIterator in this case.

Why is InsetIterator no good solution?


Because it is heavy.



> You can just use the Cursor starting at position 0...

I don't understand yet how the cursor stuff works. I can move the 
cursor stepwise through the table cells but how do I move it outside 
of the table to check if I'm then in a float?


You have to go up in the Cursor slices. Use DocIterator::operator[]. The 
last element of the DocIterator slices is the current cursor position; 
the first element is the position in the outer text inset.



(Damn, I permanently hit my programming skills limits.)


The DocIterator stuff is documented somewhere in the Wiki. You must read 
that before doing anything else.


Abdel.

Re: Remove name from param2string and friends

[Abdelrazak Younes]

On 10/28/2010 03:54 AM, Richard Heck wrote:

On 10/27/2010 08:00 PM, Vincent van Ravesteijn wrote:
 As far as I can see, this name parameter is not used, because 
InsetCommandParams already has a insetCode associated with it.


Is it ok to remove it then and to clean up a lot again ?

see:
http://gitorious.org/lyx/lyx/commit/f7da26338d03df0149b8284e4750857f6495787c 

http://gitorious.org/lyx/lyx/commit/ab5f453397bb2cada9ed248b2e079b748fa03489 

http://gitorious.org/lyx/lyx/commit/ae44ea46eb0bf7da75b2dee4d8b8a4f9559b53f1 




If it seems to work, it should be OK, I think.


I agree. But make sure insetCode is properly initialized everywhere 
though...


Abdel.

Re: Inset handling question

[Abdelrazak Younes]

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

On 10/28/2010 01:51 AM, Uwe Stöhr wrote:

> You can just use the Cursor starting at position 0...

I don't understand yet how the cursor stuff works. I can move the 
cursor stepwise through the table cells but how do I move it outside 
of the table to check if I'm then in a float?


You have to go up in the Cursor slices. Use DocIterator::operator[]. 
The last element of the DocIterator slices is the current cursor 
position; the first element is the position in the outer text inset.


I forgot to say: you can just use 
cursor().innerInsetOfType(FLOAT_CODE)... If the returned inset pointer 
is different from 0 then you are inside a float.


Abdel.

Re: RefStyle Patch

[Jean-Pierre Chrétien]

Jean-Pierre Chrétien a écrit :

Richard Heck a écrit :

On 10/27/2010 04:17 AM, Jean-Pierre Chrétien wrote:


When I look at the exported latex file test_french_refstyle.tex, I see this:

\...@ifundefined{   hmref}
  {\def\RSthmtxt{theorem~}\newref{thm}{name = \RSthmtxt}}

which creates the crossrefs for theorems.

This works in my example beacuse the test is always true, but the
code in LaTeXFeatures.cpp should read

   "\...@ifundefined{thmref}\n"
"  {\\def\\RSthmtxt{theorem~}\\newref{thm}{name = \\RSthmtxt}}\n"

instead of

   "\...@ifundefined{\thmref}\n"
"  {\\def\\RSthmtxt{theorem~}\\newref{thm}{name = \\RSthmtxt}}\n"

Right ?

--
Jean-Pierre

Re: announce: template to write Ph.D. theses with LyX

[Uwe Stöhr]

Am 28.10.2010 06:56, schrieb Waluyo Adi Siswanto:


Actually all lists in my thesis template is in frontmatter, I guess
you mean frontmatter.


Yes.


Anyway, in users perspective; it might be useful if the lyx templates
are grouped into three types (folders): articles, books, and theses.
When users open new documents from templates, they will see three
folders.


A thesis is basically a book. But even this statement is not always 
correct. There are different types of theses: for Bachelor, Master, 
Diploma, Ph.D., ...


My experience is that for short theses (like a 30 page Bachelor thesis) 
using the article style is advantageous. I therefore designed the thesis 
template to be able to easily change the document class from KOMA-script 
book to article. OK, this can surely improved and users will report us 
what they want to be changed once LyX 2.0 is out.



We have already various article templates, but don't have thesis and
books. So my suggestion, under thesis and books there are also several
examples. Users can choose which one they can start with to customize.


Until now we haven't grouped the templates. When somebody wants to write 
a letter, he will only look at the letter templates. But you are right, 
this becomes difficult with an increasing number of templates. What we 
can indeed do is to group the templates folder with subfolders for


- letters
- CVs
- Journal articles
- theses

regards Uwe

Re: longtable in LyXHTML(trunk)

[Richard Heck]

On 10/28/2010 01:27 AM, Kornel Benko wrote:

Hi Richard,
exporting (or displaying) longtables in LyXHTML-format discards the 
table-header.
Export through other format (e.g. PDF (pdflatex)) is ok.
Normal tables export is fine though.

   

Can you put this in trac? I hope to have time to work on HTML shortly.

If you could add a simple test file that'd be even better. I never use 
these so didn't get to test it.


Richard

Re: RefStyle Patch

[Richard Heck]

On 10/28/2010 05:36 AM, Jean-Pierre Chrétien wrote:

Jean-Pierre Chrétien a écrit :

Richard Heck a écrit :

On 10/27/2010 04:17 AM, Jean-Pierre Chrétien wrote:


When I look at the exported latex file test_french_refstyle.tex, I see 
this:


\...@ifundefined{hmref}
  {\def\RSthmtxt{theorem~}\newref{thm}{name = \RSthmtxt}}

which creates the crossrefs for theorems.

This works in my example beacuse the test is always true, but the
code in LaTeXFeatures.cpp should read

   "\...@ifundefined{thmref}\n"
"  {\\def\\RSthmtxt{theorem~}\\newref{thm}{name = \\RSthmtxt}}\n"

instead of

   "\...@ifundefined{\thmref}\n"
"  {\\def\\RSthmtxt{theorem~}\\newref{thm}{name = \\RSthmtxt}}\n"

Right ?


I'm not seeing the difference

rh

Re: Git repos on Gitorious

[Abdelrazak Younes]

On 10/27/2010 07:55 AM, Vincent van Ravesteijn wrote:
> Hi all,
>
> Just to inform you. I made a git repository on gitorious.

Hi Vincent,

I think you should keep 'master' in line with svn/trunk and do your 
personal commit in a new 'vfr' branch. We could also create a new common 
branch for git only development. This branch would be used by people who 
would like to switch to git entirely and would be merged into master 
(and svn/trunk) periodically (everyday?). Or we could do the opposite: 
create a read-only branch "svn" and merge periodically commit from 
master where main development would happen.


Abdel.

Re: RefStyle Patch

[Richard Heck]

I'm not seeing the difference


Anyway, I'm going to do the other thing I suggested, I think.

Richard

Re: Git repos on Gitorious

[Vincent van Ravesteijn]

> I think you should keep 'master' in line with svn/trunk and do your personal
> commit in a new 'vfr' branch.

Yes, that was the idea. However, I got a little screwed by someone
renaming InsetNomencl.cpp to InsetNomenclature.cpp. ;)..

Well, it's either me that didn't write the scripts well enough, or Git
has a bit uncomfortabilities (?) with deleted files and/or Windows.
That's why I was messing up when pushing the commits for the
InsetCommandParams patches.

Also, I have to sort of manually update the git to the svn server. I
might improve on this, but it's less easy on windows.

> We could also create a new common branch for
> git only development. This branch would be used by people who would like to
> switch to git entirely and would be merged into master (and svn/trunk)
> periodically (everyday?).

That's how Qt works I guess. They also immediately check that
everything compiles before merging.

However, what happens on merge conflicts if someone commits something
to the git server and someone changed a same thing into the svn server
?

Hmm.. if you can automatically merge.. why not everytime somebody
commits something ?

I feel that it's not suitable for us to wait for one day to see other
one's commits. That does not help checking up on each other, helping
each other out, and so forth.

> Or we could do the opposite: create a read-only
> branch "svn" and merge periodically commit from master where main
> development would happen.
>

I like your first proposal more.

On my pc, I have one checkout which is both under svn and git control.
That works quite well if you know what you're doing.

> Abdel.

Vincent

Re: Git repos on Gitorious

[Vincent van Ravesteijn]

> Yes, that was the idea. However, I got a little screwed by someone
> renaming InsetNomencl.cpp to InsetNomenclature.cpp. ;)..
>
> Well, it's either me that didn't write the scripts well enough, or Git
> has a bit uncomfortabilities (?) with deleted files and/or Windows.
> That's why I was messing up when pushing the commits for the
> InsetCommandParams patches.

I'll try to undo the mess. Nice way to got to learn this git-business
somewhat better.

Do you want access to the repository ?

Vincent

Re: Git repos on Gitorious

[Abdelrazak Younes]

On 10/28/2010 05:24 PM, Vincent van Ravesteijn wrote:

Yes, that was the idea. However, I got a little screwed by someone
renaming InsetNomencl.cpp to InsetNomenclature.cpp. ;)..

Well, it's either me that didn't write the scripts well enough, or Git
has a bit uncomfortabilities (?) with deleted files and/or Windows.
That's why I was messing up when pushing the commits for the
InsetCommandParams patches.
 

I'll try to undo the mess. Nice way to got to learn this git-business
somewhat better.

Do you want access to the repository ?
   


Yes please. I already have an account in gitourious (younes), so I guess 
it is just a matter of allowing me in.


Abdel.

Re: Git repos on Gitorious

[Abdelrazak Younes]

On 10/28/2010 05:46 PM, Abdelrazak Younes wrote:

On 10/28/2010 05:24 PM, Vincent van Ravesteijn wrote:

Yes, that was the idea. However, I got a little screwed by someone
renaming InsetNomencl.cpp to InsetNomenclature.cpp. ;)..

Well, it's either me that didn't write the scripts well enough, or Git
has a bit uncomfortabilities (?) with deleted files and/or Windows.
That's why I was messing up when pushing the commits for the
InsetCommandParams patches.

I'll try to undo the mess. Nice way to got to learn this git-business
somewhat better.

Do you want access to the repository ?


Yes please. I already have an account in gitourious (younes)


Sorry, its abdel (with my gmail address) not younes.

Abdel.

Re: RefStyle Patch

[Jean-Pierre Chrétien]

Richard Heck a écrit :



I'm not seeing the difference


Anyway, I'm going to do the other thing I suggested, I think.


The problem with ":" has vanished, but theorems are now unknown:
?? is returned in my bug #6609 example.

--
Jean-Pierre

Re: RefStyle Patch

[Richard Heck]

On 10/28/2010 11:55 AM, Jean-Pierre Chrétien wrote:

Richard Heck a écrit :



I'm not seeing the difference


Anyway, I'm going to do the other thing I suggested, I think.


The problem with ":" has vanished, but theorems are now unknown:
?? is returned in my bug #6609 example.


Took out too much

Are there other things besides theorems we should define that aren't in 
refstyle.cfg?


Is there some way we could provide translatability (in LyX's po files) 
of "theorem" here?


rh

Label Dialog Broken

[Richard Heck]

The changeover to InsetParamsWidget has borked the label dialog in ways 
I cannot seem to understand. Try this: Create a new section heading, and 
give it the title "Hello". Now Insert>Label. You ought to get a dialog 
with "sec:Hello", but you get an empty dialog.


Worse problem: If you had something in the dialog previously, you get it 
back again. I.e., LyX invites you to create a duplicate label.


The source of this is that InsetParamsDialog::initializeParams() ignores 
its argument and restores the previous state of the dialog. I don't see 
how this could be over-ridden.


Richard

Re: longtable in LyXHTML(trunk)

[Kornel Benko]

Am Donnerstag 28 Oktober 2010 schrieb Richard Heck:
> On 10/28/2010 01:27 AM, Kornel Benko wrote:
> > Hi Richard,
> > exporting (or displaying) longtables in LyXHTML-format discards the
> > table-header. Export through other format (e.g. PDF (pdflatex)) is ok.
> > Normal tables export is fine though.
> 
> Can you put this in trac? I hope to have time to work on HTML shortly.
> 
> If you could add a simple test file that'd be even better. I never use
> these so didn't get to test it.
> 
> Richard

Done. #6995

Kornel


signature.asc
Description: This is a digitally signed message part.

Re: RefStyle Patch

[Kornel Benko]

Am Donnerstag 28 Oktober 2010 schrieb Richard Heck:
> On 10/28/2010 05:36 AM, Jean-Pierre Chrétien wrote:
> > Jean-Pierre Chrétien a écrit :
> >> Richard Heck a écrit :
> >>> On 10/27/2010 04:17 AM, Jean-Pierre Chrétien wrote:
> > When I look at the exported latex file test_french_refstyle.tex, I see
> > this:
> > 
> > \...@ifundefined{hmref}
> > 
> >   {\def\RSthmtxt{theorem~}\newref{thm}{name = \RSthmtxt}}
> > 
> > which creates the crossrefs for theorems.
> > 
> > This works in my example beacuse the test is always true, but the
> > code in LaTeXFeatures.cpp should read
> > 
> >"\...@ifundefined{thmref}\n"
> >
> > "  {\\def\\RSthmtxt{theorem~}\\newref{thm}{name = \\RSthmtxt}}\n"
> > 
> > instead of
> > 
> >"\...@ifundefined{\thmref}\n"
> >
> > "  {\\def\\RSthmtxt{theorem~}\\newref{thm}{name = \\RSthmtxt}}\n"
> > 
> > Right ?
> 
> I'm not seeing the difference
> 
> rh

The diff is in the first line
...fundefined{thmref}...
vs
...fundefined{\thmref}...

Kornel


signature.asc
Description: This is a digitally signed message part.

Re: Git repos on Gitorious

[Vincent van Ravesteijn]

> Sorry, its abdel (with my gmail address) not younes.
>
> Abdel.

You're in.

Vincent

Re: longtable in LyXHTML(trunk)

[Richard Heck]

On 10/28/2010 12:12 PM, Kornel Benko wrote:

Am Donnerstag 28 Oktober 2010 schrieb Richard Heck:
   

On 10/28/2010 01:27 AM, Kornel Benko wrote:
 

Hi Richard,
exporting (or displaying) longtables in LyXHTML-format discards the
table-header. Export through other format (e.g. PDF (pdflatex)) is ok.
Normal tables export is fine though.
   

Can you put this in trac? I hope to have time to work on HTML shortly.

If you could add a simple test file that'd be even better. I never use
these so didn't get to test it.

Richard
 

Done. #6995

   

Thanks.

rh

Re: Label Dialog Broken

[Abdelrazak Younes]

On 10/28/2010 06:04 PM, Richard Heck wrote:


The changeover to InsetParamsWidget has borked the label dialog in 
ways I cannot seem to understand. Try this: Create a new section 
heading, and give it the title "Hello". Now Insert>Label. You ought to 
get a dialog with "sec:Hello", but you get an empty dialog.


Worse problem: If you had something in the dialog previously, you get 
it back again. I.e., LyX invites you to create a duplicate label.


The source of this is that InsetParamsDialog::initializeParams() 
ignores its argument and restores the previous state of the dialog. I 
don't see how this could be over-ridden.


I'll try to fix that ASAP. Or I revert if I can't...

Abdel.

Re: RefStyle Patch

[Jean-Pierre Chrétien]

Richard Heck a écrit :



Are there other things besides theorems we should define that aren't in 
refstyle.cfg?


To be prettyref-coherent, lemmas.



Is there some way we could provide translatability (in LyX's po files) 
of "theorem" here?


For the time being, we need a restricted set of declarations and translations
in LyX (no plurals, no capitalization).

If you declare all refstyle commands for theorems and such, marked as gettext 
strings, in the code, they will get translated in po files, but this will be 
static in the interface language.


We would like to have strings translated depending upon the current language in 
the document, to allow true babel i18n.


What about providing with LyX an auxiliary file containing the required 
translations (a refstyle.def file if new languages are needed) ?
When fully tested and fairly complete, we could send the file to Danie Els for 
update in CTAN.


--
Jean-Pierre

Re: Git repos on Gitorious

[Abdelrazak Younes]

On 10/28/2010 06:21 PM, Vincent van Ravesteijn wrote:

Sorry, its abdel (with my gmail address) not younes.

Abdel.
 

You're in.
   


Thanks!

Abdel.

Re: RefStyle Patch

[Richard Heck]

On 10/28/2010 12:16 PM, Kornel Benko wrote:


The diff is in the first line
...fundefined{thmref}...
vs
...fundefined{\thmref}...

   

Oh, right, I see.

rh

Re: Label Dialog Broken

[Richard Heck]

On 10/28/2010 12:04 PM, Richard Heck wrote:


The changeover to InsetParamsWidget has borked the label dialog in 
ways I cannot seem to understand. Try this: Create a new section 
heading, and give it the title "Hello". Now Insert>Label. You ought to 
get a dialog with "sec:Hello", but you get an empty dialog.


Worse problem: If you had something in the dialog previously, you get 
it back again. I.e., LyX invites you to create a duplicate label.


The source of this is that InsetParamsDialog::initializeParams() 
ignores its argument and restores the previous state of the dialog. I 
don't see how this could be over-ridden.



OK, I think I've fixed this at r35886, but please check.

Richard

Re: Label Dialog Broken

[Abdelrazak Younes]

On 10/28/2010 06:31 PM, Richard Heck wrote:

On 10/28/2010 12:04 PM, Richard Heck wrote:


The changeover to InsetParamsWidget has borked the label dialog in 
ways I cannot seem to understand. Try this: Create a new section 
heading, and give it the title "Hello". Now Insert>Label. You ought 
to get a dialog with "sec:Hello", but you get an empty dialog.


Worse problem: If you had something in the dialog previously, you get 
it back again. I.e., LyX invites you to create a duplicate label.


The source of this is that InsetParamsDialog::initializeParams() 
ignores its argument and restores the previous state of the dialog. I 
don't see how this could be over-ridden.



OK, I think I've fixed this at r35886, but please check.


Yes thanks, that's what I wanted to do. But it can be generalized into 
InsetParamsWidget, no need to implement it in each class:


bool InsetParamsWidget::initialiseParams(std::string const&  data)
{
InsetCommandParams p(insetCode());
if (!InsetCommand::string2params(insetName(), data, p))
return false;
paramsToDialog(params);
return true;
}

The insetName() bit could go once Vincent has committed his change about 
string2params().

Of course this also means that a new virtual method needs to be created:

InsetParamsWidget::paramsToDialog(InsetCommandParams const&)

I resisted doing this because I thought not all InsetParamsWidget based class 
would use InsetCommandParams.

Abdel.

Re: Label Dialog Broken

[Richard Heck]

On 10/28/2010 01:07 PM, Abdelrazak Younes wrote:

On 10/28/2010 06:31 PM, Richard Heck wrote:

On 10/28/2010 12:04 PM, Richard Heck wrote:


The changeover to InsetParamsWidget has borked the label dialog in 
ways I cannot seem to understand. Try this: Create a new section 
heading, and give it the title "Hello". Now Insert>Label. You ought 
to get a dialog with "sec:Hello", but you get an empty dialog.


Worse problem: If you had something in the dialog previously, you 
get it back again. I.e., LyX invites you to create a duplicate label.


The source of this is that InsetParamsDialog::initializeParams() 
ignores its argument and restores the previous state of the dialog. 
I don't see how this could be over-ridden.



OK, I think I've fixed this at r35886, but please check.


Yes thanks, that's what I wanted to do. But it can be generalized into 
InsetParamsWidget, no need to implement it in each class:


bool InsetParamsWidget::initialiseParams(std::string const&  data)
{
InsetCommandParams p(insetCode());
if (!InsetCommand::string2params(insetName(), data, p))
return false;
paramsToDialog(params);
return true;
}

The insetName() bit could go once Vincent has committed his change 
about string2params().


Of course this also means that a new virtual method needs to be created:

InsetParamsWidget::paramsToDialog(InsetCommandParams const&)

I resisted doing this because I thought not all InsetParamsWidget 
based class would use InsetCommandParams.


Perhaps that is a reason to keep it as it is. There's going to be some 
virtual method here that gets overridden in the base classes. In my 
code, it's initialiseParams(); your proposal has it being 
paramsToDialog(ICP). But that has the cost you just mentioned. And 
InsetGraphics and InsetListings are possible candidates.


Andre has occasionally suggested getting rid of the whole ICP business 
in favor of some sort of inheritance. I'm becoming sympathetic and have 
been thinking about doing this early in the 2.1 cycle. So maybe that's 
another reason.


rh

Re: RefStyle Patch

[Richard Heck]

On 10/28/2010 12:24 PM, Jean-Pierre Chrétien wrote:

Richard Heck a écrit :



Are there other things besides theorems we should define that aren't 
in refstyle.cfg?


To be prettyref-coherent, lemmas.



Is there some way we could provide translatability (in LyX's po 
files) of "theorem" here?


For the time being, we need a restricted set of declarations and 
translations

in LyX (no plurals, no capitalization).

If you declare all refstyle commands for theorems and such, marked as 
gettext strings, in the code, they will get translated in po files, 
but this will be static in the interface language.



Right, no good.

We would like to have strings translated depending upon the current 
language in the document, to allow true babel i18n.


What about providing with LyX an auxiliary file containing the 
required translations (a refstyle.def file if new languages are needed) ?


The problem is knowing how and where to install this. Users can do it, 
of course, but it's harder for us to do.


When fully tested and fairly complete, we could send the file to Danie 
Els for update in CTAN.



Ultimately, this is clearly best.

Perhaps we can do this: (i) Try to get translations from our own 
translators of theorem and lemma, if that covers everything prettyref 
does, that we can hardcode into LaTeXFeatures.cpp, so that we at least 
do as well as refstyle.cfg does with these two; (ii) Send an updated 
version of refstyle.cfg to Els, including those translations. The former 
could be removed after a while, i.e., once we had some sense that the 
new version was common enough.


Richard

externally modified warning

[Julien Rioux]

Hi,

Using svn trunk compiled a few days ago (r35874). I am working on a file 
under svn version control. After modifying the file and wanting to save, 
I get a warning that the file has been externally modified. It has not 
been externally modified.


Recipe:
Open a lyx file under svn
Change something
Save

--
Julien

Re: RefStyle Patch

[Jean-Marc Lasgouttes]

Le 28 oct. 10 à 18:24, Jean-Pierre Chrétien a écrit :
Is there some way we could provide translatability (in LyX's po  
files) of "theorem" here?


For the time being, we need a restricted set of declarations and  
translations

in LyX (no plurals, no capitalization).

If you declare all refstyle commands for theorems and such, marked  
as gettext strings, in the code, they will get translated in po  
files, but this will be static in the interface language.


No, currently we use some gettext strings (Chapter) in the document  
language.

So we have the needed bits to translate i the language we want.

JMarc

Re: externally modified warning

[Stephan Witt]

Am 28.10.2010 um 21:05 schrieb Julien Rioux:

> Hi,
> 
> Using svn trunk compiled a few days ago (r35874). I am working on a file 
> under svn version control. After modifying the file and wanting to save, I 
> get a warning that the file has been externally modified. It has not been 
> externally modified.
> 
> Recipe:
> Open a lyx file under svn
> Change something
> Save

Here it doesn't depend on version control.

I set a break in Buffer::isExternallyModified().
The private members timestamp_ and checksum_ equals to 0 (not really 
initialized).
Consequently LyX does not enter Buffer::saveCheckSum()... this call somehow 
gets lost.
I'm afraid the last changes regarding Buffer read operations are the culprit.

Stephan

Re: externally modified warning

[Richard Heck]

On 10/28/2010 04:30 PM, Stephan Witt wrote:

Am 28.10.2010 um 21:05 schrieb Julien Rioux:

   

Hi,

Using svn trunk compiled a few days ago (r35874). I am working on a file under 
svn version control. After modifying the file and wanting to save, I get a 
warning that the file has been externally modified. It has not been externally 
modified.

Recipe:
Open a lyx file under svn
Change something
Save
 

Here it doesn't depend on version control.

I set a break in Buffer::isExternallyModified().
The private members timestamp_ and checksum_ equals to 0 (not really 
initialized).
Consequently LyX does not enter Buffer::saveCheckSum()... this call somehow 
gets lost.
I'm afraid the last changes regarding Buffer read operations are the culprit.

   

I'll fix this. I'm just trying to figure out the best way

rh

Re: Problem with Reconfigure and timeout in SystemCall

[RGH]

On 10/27/2010 12:21 AM, Vincent van Ravesteijn wrote:

Hi,

If I reconfigure and have to wait for MikTeX to download some
packages, LyX will break the Reconfigure script due to some timeout in
SystemCall.

   
The startscript routine seems to put a timeout of 18 on the process. 
If that's milliseconds, then it's only about three minutes.


Richard

Re: [Patch] Rename "Invisible" in View menu to "Hidden|H".

[RGH]

On 10/26/2010 01:12 AM, John McCabe-Dansted wrote:

On Mon, Oct 25, 2010 at 3:55 PM, Jürgen Spitzmüller  wrote:
   

Please let me know of other issues. Note particularly that all fixes that
entail a string change should go in very soon, since we will turn to string
freeze soon.
 

Well this string change doesn't affect branch, but I think we should
rename Invisible as Hidden|H in the View menu as:
1) This allows a natural keyboard accelerator "H" ("I" is already used).
2) This matches the terminology "Hide tab" used in the context menu
when hiding the tab.

   

Committed, thanks.

I'll tell you what I'd also like: A Close-this-document-set option, that 
would close the master and all its children, NOT hide them. If you're 
interested


Richard

Re: announce: template to write Ph.D. theses with LyX

[Waluyo Adi Siswanto]

>
> A thesis is basically a book. But even this statement is not always correct.
> There are different types of theses: for Bachelor, Master, Diploma, Ph.D.,
> ...

Books usually a bit fancy, chapter headings a bit fancy, not too
formal. For LaTeX expert might not be a problem to customize
everything. But are LyX users all LaTeX users? Some perhaps use LyX
just to get started.

>
> My experience is that for short theses (like a 30 page Bachelor thesis)
> using the article style is advantageous. I therefore designed the thesis
> template to be able to easily change the document class from KOMA-script
> book to article. OK, this can surely improved and users will report us what
> they want to be changed once LyX 2.0 is out.
>

Perhaps, rather than one generic style, it could be thesis-typeA,
thesis-typeB without mentioning any university, so users feel
comfortable to choose and to customize it.


> Until now we haven't grouped the templates. When somebody wants to write a
> letter, he will only look at the letter templates. But you are right, this
> becomes difficult with an increasing number of templates. What we can indeed
> do is to group the templates folder with subfolders for
>
> - letters
> - CVs
> - Journal articles
> - theses
>

Perhaps using group prefix is another alternative to help users to
find (just like what appears in the document class), so it will be
organized automatically:
article-IEEEtran
article-elsevier
article-...
book-novel
book-art
book-...
cv-simple
cv-fancy
cv-...
letter-modelA
letter-...
presentation-simple
presentation-fancy
presentation-...
thesis-model-A
thesis-model-B
thesis-...
misc-..

Best Regards
Waluyo

Re: r35894 - in lyx-devel/trunk/src: frontends/qt4 insets

[Vincent van Ravesteijn]

 Op 29-10-2010 3:18, uwesto...@lyx.org schreef:

Modified: lyx-devel/trunk/src/insets/InsetTabular.cpp
==
--- lyx-devel/trunk/src/insets/InsetTabular.cpp Fri Oct 29 02:46:21 2010
(r35893)
+++ lyx-devel/trunk/src/insets/InsetTabular.cpp Fri Oct 29 03:18:18 2010
(r35894)
@@ -4313,6 +4313,9 @@
break;

case Tabular::SET_LONGTABULAR:
+   // setting as longtable is not allowed when table is 
inside a float
+   if (cur.innerInsetOfType(FLOAT_CODE) != 0)
+   status.setEnabled(false);
status.setOnOff(tabular.is_long_tabular);
break;



What about Wrap floats ? These have the code WRAP_CODE.

Vincent

Re: Inset handling question

[Uwe Stöhr]

The DocIterator stuff is documented somewhere in the Wiki. You must read that 
before doing
anything else.


Indeed! I found this page:
http://wiki.lyx.org/Devel/Diagrams
and I understand now a lot more. Many thanks Pavel, for your devel Wiki pages!
This explains also my question from the last post:


When I replace "++it" by "--it" the compiler quites with the message that there 
are unresolved
externals because a variable beginning with "--" doesn't exist.


InsetIterator is only defined as forward iterator.

---


'this' is 'Inset *' so in this cas you must use '*this'.


I already tried this but this also doesn't compile:

D:\LyXSVN\lyx-devel\src\insets\InsetTabular.cpp(4318) : error C2664: 'lyx::inset_iterator_begin' : 
cannot convert parameter 1 from 'const lyx::InsetTabular' to 'lyx::Inset &'

Conversion loses qualifiers

The pointer stuff is still magic to me.

> I forgot to say: you can just use cursor().innerInsetOfType(FLOAT_CODE)

Thanks, I used this for the fix: http://www.lyx.org/trac/changeset/35894

One last question: How do I explicitly specify that the "0" in my patch is a pointer? I mean "0" 
could also refer an int or double. The compiler doesn't complain and "0" is the default return value 
of innerInsetOfType but I'm wondering why this works.


many thanks and regards
Uwe

Re: r35894 - in lyx-devel/trunk/src: frontends/qt4 insets

[Uwe Stöhr]

Am 29.10.2010 03:23, schrieb Vincent van Ravesteijn:


What about Wrap floats ? These have the code WRAP_CODE.


Thanks, I forgot the wrapped floats and added this now.

regards Uwe

Re: Inset handling question

[Vincent van Ravesteijn]

One last question: How do I explicitly specify that the "0" in my 
patch is a pointer? I mean "0" could also refer an int or double. The 
compiler doesn't complain and "0" is the default return value of 
innerInsetOfType but I'm wondering why this works.


There is also a small section on this in the codeandadvice manual in 
development/coding.


Some code uses NULL to somehow indicate a null pointer, sometimes you 
see (Inset *) 0, but in the end a pointer is just a number and a number 
can be 0 I guess.


Usually we just do:

Inset * inset = getInset(...);
if (inset)
.

leaving out the check for 0.

See InsetFloat::updateBuffer() at line 209 of InsetFloat.cpp

bool const in_subflt = (it.innerInsetOfType(FLOAT_CODE)
 || it.innerInsetOfType(WRAP_CODE));

if (in_subflt)
...

This makes it slightly more readible as the document mentions before 
states that multiline if statements should be avoided.


Vincent

how to change GUI Language

[Christian del Castillo]

I am also posting these suggestions in the developer's mailing list

This is a post I made at the LaTex forum, fortunately for me the issue was
addressed and solved by a kind user showing a picture of how the menu should
look like in English, from there I was able to GUESSTIMATE which menu
entries I should be manipulating, despite not completely understanding the
language my GUI was in.

I was also going to the mail archive, and the way I understandit is that LyX
will detect the system language and adjust GUI accordingly, however in my
case, the system language was in English, my IP address Korean, the only
Japanese setting I had was in 'Language to display non-unicode characters'
in. So, why did the installer decide on Japanese in the first place?

here is a link to my post on the LaTex forum:
http://www.latex-community.org/forum/viewtopic.php?f=19=10613=41052#p41052

=

I think this is a very major issue, as it can affect first time users, and
turn them off completely from the software if not addressed.
This is my first time to try LyX. I installed the package, and while doing
so was not given any option regarding the GUI language. After finally
completing the installation, Voila! the GUI was in JAPANESE!

-Problem 1) I am working in South Korea, I have language sets for my PC set
to enable both Korean and Japanese, but why did the install package choose
to be in Japanese? what would happen if I am Korean, for example, with
absolutely no knowledge of Japanese?
-Problem 2) I can speak, read, and write a LITTLE Japanese, but not that
much. If anybody will give me instructions on how to change the GUI language
I might have trouble looking for the relevant menu entry. If, for some
reason or another the GUI language became Korean, for example, I would have
absolutely no way of being able to look for the menu entry

So I suggest the ff:

Suggestion 1) Give the user the ability to CHOOSE preferred language on
install REGARDLESS of IP address (or whatever method was used to choose GUI
in my current situation)!
Suggestion 2) Make the menu entry to change the GUI language EASY TO FIND
and also IN A LANGUAGE DIFFERENT FROM THE CURRENT GUI, a lot of people would
want to change the GUI because they do not have enough ability in the
language in the first place.

=

Chris del Castillo, PhD
Gyeongsang National University
South Korea




-- 
=
'Christian' Carmelo del Castillo, PhD
Aquatic Biotechnology Center,
Gyeongsang National University, Republic of Korea
TEL: +82-55-751-6732 FAX: +82-55-762-6733
e-mail: chia...@msn.com

Re: Inset handling question

[Uwe Stöhr]

Am 29.10.2010 03:33, schrieb Vincent van Ravesteijn:


One last question: How do I explicitly specify that the "0" in my patch is a pointer? I 
mean "0"
could also refer an int or double. The compiler doesn't complain and "0" is the 
default return
value of innerInsetOfType but I'm wondering why this works.


There is also a small section on this in the codeandadvice manual in 
development/coding.


Thanks, I'll have a look at this manual.


Some code uses NULL to somehow indicate a null pointer, sometimes you see 
(Inset *) 0, but in the
end a pointer is just a number and a number can be 0 I guess.

Usually we just do:...


Thanks for the explanation.

regards Uwe

Re: Inset handling question

[Richard Heck]

 On 10/28/10 9:42 PM, Uwe Stöhr wrote:


Some code uses NULL to somehow indicate a null pointer, sometimes you 
see (Inset *) 0, but in the

end a pointer is just a number and a number can be 0 I guess.

Usually we just do:...


Thanks for the explanation.

To maybe explain a little more, C++ will sometimes do what are called 
"implicit conversions". This is when there is a standard way to convert 
from one type to another. For example, consider this line:

string str = "Hello";
Here, "Hello" is specified as a literal. This means that it is actually 
a const array of characters, specifically, what C++ calls "const char 
*". But there is an obvious sort of conversion from const char * to 
string, and so you can do this without specifying the conversion 
explicitly.


With classes, this happens whenever one class has a constructor that 
takes some other type as an argument. So, for example, suppose we have:

class A {
A();
A(int);
};
So class A has two constructors: A default one, and one that takes an 
int. Then you can do:

A avar;
avar = 2;
This is because the compiler knows how to make an A from an int.

In the string case we have a constructor:
string(const char *);
that is defined in string.h. So the compiler knows how to do that 
conversion.


Essentially the same thing happens with pointers and integers: The 
compiler knows how to make a pointer from an int. These are not classes, 
so there aren't constructors, but the idea is the same.


Richard

Re: externally modified warning

[Stephan Witt]

Am 28.10.2010 um 22:59 schrieb Richard Heck:

> On 10/28/2010 04:30 PM, Stephan Witt wrote:
>> Am 28.10.2010 um 21:05 schrieb Julien Rioux:
>> 
>>   
>>> Hi,
>>> 
>>> Using svn trunk compiled a few days ago (r35874). I am working on a file 
>>> under svn version control. After modifying the file and wanting to save, I 
>>> get a warning that the file has been externally modified. It has not been 
>>> externally modified.
>>> 
>>> Recipe:
>>> Open a lyx file under svn
>>> Change something
>>> Save
>>> 
>> Here it doesn't depend on version control.
>> 
>> I set a break in Buffer::isExternallyModified().
>> The private members timestamp_ and checksum_ equals to 0 (not really 
>> initialized).
>> Consequently LyX does not enter Buffer::saveCheckSum()... this call somehow 
>> gets lost.
>> I'm afraid the last changes regarding Buffer read operations are the culprit.
>>   
> I'll fix this. I'm just trying to figure out the best way

Thanks, you fixed it.

Stephan

Re: #6982: on mispelled work, right click and selecting one option produces a crash

[Stephan Witt]

Am 26.10.2010 um 07:50 schrieb LyX Ticket Tracker:

> #6982: on mispelled work, right click and selecting one option produces a 
> crash
> --+-
> Reporter:  urlwolf   |   Owner:  stwitt  
> Type:  defect|  Status:  accepted
> Priority:  high  |   Milestone:  2.0.0   
> Component:  spell | Version:  2.0.0svn
> Severity:  critical  |Keywords:  crash infoneeded
> --+-
> Changes (by stwitt):
> 
>  * keywords:  crash => crash infoneeded
>  * owner:  lasgouttes => stwitt
>  * status:  new => accepted
> 
> 
> Comment:
> 
> I tried to reproduce and failed.
> Please add some details.
> What is "select one option"?
> I tried "Ignore all" and it did not crash - the spell checker simply
> ignored it afterwards.
> I tried replace with a suggestion - it worked, too.
> What's the platform you are using?
> More detailed instruction to solve this issue would be helpful.
> 
> -- 
> Ticket URL: 
> The LyX Project 
> LyX -- The Document Processor

What's to do with this ticket?
I think it's not urgent.
I don't understand the recipe, cannot reproduce, asked and got no answer.
So at least the priority is not high...

Stephan