Re: Language problems ... again

2017-11-02 Thread Scott Kostyshak
On Thu, Nov 02, 2017 at 08:43:35PM +, Kornel Benko wrote:
> Am Donnerstag, 2. November 2017 um 21:37:25, schrieb Jürgen Spitzmüller 
> 
> > Am Donnerstag, den 02.11.2017, 21:17 +0100 schrieb Kornel Benko:
> > > examples/ja/sweave.lyx not compilable. Resetting the English text at
> > > section 5
> > >   'The user manual ofSweave is at'
> > > cures the problem.
> > 
> > A more sane solution is to set "Language package" in Document Settings
> > from "None" to "Automatically".
> > 
> > Jürgen
> 
> Yes, this works. +1

Works here also. I would say +1 for 2.3.x.

Scott


signature.asc
Description: PGP signature


Re: [LyX/master] Sort the language nesting mess with polyglossia

2017-11-02 Thread Kornel Benko
Am Donnerstag, 2. November 2017 um 21:38:31, schrieb Jean-Pierre 

> >> > Here are the errors that I get;
> >> >   LaTeX Error: \begin{otherlanguage} on input line 173 ended by 
> >> > \end{letter}.
> >> >   LaTeX Error: \begin{letter} on input line 173 ended by \end{document}.
> >> >
> >> > To trigger these, just load lib/templates/lettre.lyx, set 'use non-TeX 
> >> fonts' in
> >> > Document>Settings>Fonts and compile.
> >> >
> >>
> >> Looks like the same as in commit 1d0794e for  es/Additional.lyx
> >>
> >
> > Ping ...
> >
> > The error for export/templates/lettre_pdf5_systemF persist.
> > Should this be ignored?
> >
> Yes, the origin of this issue is quite involved because it is due to the 
> extra code which has been added in the preamble. The letter class is not 
> the culprit by itself.
> 
> I'm investigating this.
> 
> -- 
> Jean-Pierre

Am Donnerstag, 2. November 2017 um 21:59:54, schrieb Jürgen Spitzmüller 

> > The error for export/templates/lettre_pdf5_systemF persist.
> > Should this be ignored?
> 
> No, but this has nothing to do with LyX's language nesting, but is
> rather a consequence of lettre's overly complicated preamble hacking
> (\lettre, \findemessage etc.). I think one could re-write this layout
> file in a more clean manner using LyX's current layout means.
> 
> Jürgen

Thanks Jean-Pierre and Jürgen.

Kornel

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


Re: Slow opening of Document Settings in RC1

2017-11-02 Thread racoon

On 02.11.2017 19:15, Jürgen Spitzmüller wrote:

Am Donnerstag, den 02.11.2017, 18:41 +0200 schrieb racoon:

On 02.11.2017 19:22, Jürgen Spitzmüller wrote:

Am Donnerstag, den 02.11.2017, 17:21 +0200 schrieb racoon:

The opening of Document Settings takes about 8 seconds for some
Documents on my system. LyX becomes unresponsive in the
meanwhile.
(Core
2 Duo, Win7)

I noticed that the delay became longer in beta1. But it was much
faster
still.


Do you have local layout setting in these documents? If so, does
the
speed improve if you convert these to the current format (via the
"Convert" button)?


No local layout present.


Could you provide us with such a document?


Not at the moment. But I'll look into that.

Daniel



Jürgen






Re: Slow opening of Document Settings in RC1

2017-11-02 Thread racoon

On 02.11.2017 21:34, Andrew Parsloe wrote:



On 3/11/2017 5:44 a.m., racoon wrote:

On 02.11.2017 17:21, racoon wrote:
The opening of Document Settings takes about 8 seconds for some 
Documents on my system. LyX becomes unresponsive in the meanwhile. 
(Core 2 Duo, Win7)


I noticed that the delay became longer in beta1. But it was much 
faster still.


Seems like these delays change. After a fresh start of LyX it takes 
about 8 seconds. But sometimes this gets quicker when LyX has been in 
use for a while.


Daniel
I can't reproduce. I'm running rc1 (Uwe's installer), Windows 7, 
standard 'High Street' laptop from about 4 years ago. I start LyX, open 
a document, access Document Settings and it shows in a second or less.


Did you see the "for some documents" part? It is definitely quicker for 
new files (just a bit over a second). I haven't figured out what it 
correlates with. For example, the User Manual seems fine.


Daniel



Andrew

PS Following this thread results in weird timings on my computer.

racoon  4:21 a.m.
racoon  5:40 a.m. (reply to Scott 6:02)
racoon  5:41 a.m. (reply to Juergen 6:22)
racoon  5:44 a.m.
Scott   6:02 a.m.
Juergen 6:22 a.m.
Juergen 7:15 a.m.


Could be that my computer was on the wrong settings after switching time 
zones...




I once spent some weeks inadvertently using US Pacific time but I've 
checked and it is correctly set for New Zealand.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus







Re: #10779: LyX crashes when inserting cross references

2017-11-02 Thread Jürgen Spitzmüller
Am Donnerstag, den 02.11.2017, 16:49 -0400 schrieb Lev Ioffe:
> can you provide the email of a developer?

You can use mine (see sender of this mail).

Jürgen

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


Re: [LyX/master] Sort the language nesting mess with polyglossia

2017-11-02 Thread Jürgen Spitzmüller
Am Donnerstag, den 02.11.2017, 21:33 +0100 schrieb Kornel Benko:
> > > It seems that the Xetex error that I get with the lettre template
> is of that 
> > > kind. I was about to write to the class author about this, but it
> seems thus 
> > > that is is a LyX bug, right?
> > > 
> > > Here are the errors that I get;
> > >   LaTeX Error: \begin{otherlanguage} on input line 173 ended by
> \end{letter}.
> > >   LaTeX Error: \begin{letter} on input line 173 ended by
> \end{document}.
> > > 
> > > To trigger these, just load lib/templates/lettre.lyx, set 'use
> non-TeX fonts' in 
> > > Document>Settings>Fonts and compile.
> > > 
> > 
> > Looks like the same as in commit 1d0794e for  es/Additional.lyx
> > 
> 
> Ping ...
> 
> The error for export/templates/lettre_pdf5_systemF persist.
> Should this be ignored?

No, but this has nothing to do with LyX's language nesting, but is
rather a consequence of lettre's overly complicated preamble hacking
(\lettre, \findemessage etc.). I think one could re-write this layout
file in a more clean manner using LyX's current layout means.

Jürgen

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


Re: #10779: LyX crashes when inserting cross references

2017-11-02 Thread Lev Ioffe
can you provide the email of a developer?

On Nov 2, 2017 3:26 PM, "LyX Ticket Tracker"  wrote:

> #10779: LyX crashes when inserting cross references
> ---+-
>  Reporter:  levbioffe  |   Owner:  lasgouttes
>  Type:  defect |  Status:  new
>  Priority:  high   |   Milestone:
> Component:  general| Version:  2.2.3
>  Severity:  major  |  Resolution:
>  Keywords: |
> ---+-
>
> Comment (by spitz):
>
>  It will be very hard to debug this without an example file. Can you
>  provide an anonymized version of a file that crashes (maybe replace all
>  characters by "x"), or alternatively, send the file to a developer by
>  private mail?
>
> --
> Ticket URL: 
> The LyX Project 
> LyX -- The Document Processor
>


Re: Language problems ... again

2017-11-02 Thread Kornel Benko
Am Donnerstag, 2. November 2017 um 21:37:25, schrieb Jürgen Spitzmüller 

> Am Donnerstag, den 02.11.2017, 21:17 +0100 schrieb Kornel Benko:
> > examples/ja/sweave.lyx not compilable. Resetting the English text at
> > section 5
> > 'The user manual ofSweave is at'
> > cures the problem.
> 
> A more sane solution is to set "Language package" in Document Settings
> from "None" to "Automatically".
> 
> Jürgen

Yes, this works. +1

Kornel

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


Re: Language problems ... again

2017-11-02 Thread Jürgen Spitzmüller
Am Donnerstag, den 02.11.2017, 21:17 +0100 schrieb Kornel Benko:
> examples/ja/sweave.lyx not compilable. Resetting the English text at
> section 5
>   'The user manual ofSweave is at'
> cures the problem.

A more sane solution is to set "Language package" in Document Settings
from "None" to "Automatically".

Jürgen

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


Re: Slow opening of Document Settings in RC1

2017-11-02 Thread Andrew Parsloe



On 3/11/2017 5:44 a.m., racoon wrote:

On 02.11.2017 17:21, racoon wrote:
The opening of Document Settings takes about 8 seconds for some 
Documents on my system. LyX becomes unresponsive in the meanwhile. 
(Core 2 Duo, Win7)


I noticed that the delay became longer in beta1. But it was much 
faster still.


Seems like these delays change. After a fresh start of LyX it takes 
about 8 seconds. But sometimes this gets quicker when LyX has been in 
use for a while.


Daniel
I can't reproduce. I'm running rc1 (Uwe's installer), Windows 7, 
standard 'High Street' laptop from about 4 years ago. I start LyX, open 
a document, access Document Settings and it shows in a second or less.


Andrew

PS Following this thread results in weird timings on my computer.

racoon  4:21 a.m.
racoon  5:40 a.m. (reply to Scott 6:02)
racoon  5:41 a.m. (reply to Juergen 6:22)
racoon  5:44 a.m.
Scott   6:02 a.m.
Juergen 6:22 a.m.
Juergen 7:15 a.m.

I once spent some weeks inadvertently using US Pacific time but I've 
checked and it is correctly set for New Zealand.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



Re: [LyX/master] Sort the language nesting mess with polyglossia

2017-11-02 Thread Kornel Benko
Am Sonntag, 8. Oktober 2017 um 23:05:29, schrieb Kornel Benko 
> Am Sonntag, 8. Oktober 2017 um 22:59:47, schrieb Jean-Pierre Chrétien 
> 
> > Le 08/10/2017 à 05:39, Scott Kostyshak a écrit :
> > > On Sat, Sep 24, 2016 at 01:25:42AM +, Enrico Forestieri wrote:
> > >> commit 3bc08a76c42cd350a3141f00f37082bc9fab8967
> > >> Author: Enrico Forestieri 
> > >> Date:   Sat Sep 24 03:15:02 2016 +0200
> > >>
> > >>  Sort the language nesting mess with polyglossia
> > >>  
> > >>  When using polyglossia, lyx was making a real mess when changing
> > >>  language inside nested insets. The \begin{language} and
> > >>  \end{language} commands were not well paired such that they could
> > >>  easily occur just before and after the start or end of an
> > >>  environment. Of course this was causing latex errors such that
> > >>  "\begin{otherlanguage} ended by \end{environment}".
> > >>  There may still be some cases I did not take into account.
> > 
> > It seems that the Xetex error that I get with the lettre template is of 
> > that 
> > kind. I was about to write to the class author about this, but it seems 
> > thus 
> > that is is a LyX bug, right?
> > 
> > Here are the errors that I get;
> >   LaTeX Error: \begin{otherlanguage} on input line 173 ended by 
> > \end{letter}.
> >   LaTeX Error: \begin{letter} on input line 173 ended by \end{document}.
> > 
> > To trigger these, just load lib/templates/lettre.lyx, set 'use non-TeX 
> > fonts' in 
> > Document>Settings>Fonts and compile.
> > 
> 
> Looks like the same as in commit 1d0794e for  es/Additional.lyx
> 

Ping ...

The error for export/templates/lettre_pdf5_systemF persist.
Should this be ignored?

Kornel

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


Re: Language problems ... again

2017-11-02 Thread Scott Kostyshak
On Thu, Nov 02, 2017 at 08:17:16PM +, Kornel Benko wrote:
> examples/ja/sweave.lyx not compilable. Resetting the English text at section 5
>   'The user manual ofSweave is at'
> cures the problem.
> 
> The error message is
>
>   l.280 \selectlanguage{english}
>   %
>   You may proceed, but expect wrong results
> 
>   ! Package babel Error: Unknown language `english'. Either you have

I can reproduce. So the error should go away once the new text is
translated. Should we open a trac ticket with a MWE?

Scott


signature.asc
Description: PGP signature


Re: \sideset gui wrong?

2017-11-02 Thread Scott Kostyshak
On Thu, Nov 02, 2017 at 05:40:59PM +, Jürgen Spitzmüller wrote:
> Am Donnerstag, den 02.11.2017, 18:34 +0100 schrieb Pavel Sanda:
> > Scott Kostyshak wrote:
> > > is after the freeze. But if translators need to make new
> > > translations
> > > anyway (because of more important string changes), is it bad to
> > > consider
> > > less important string changes?
> > 
> > If the string freeze was already issued, I'd say don't break it.
> > This change can go to master and later to 2.3.1 if Richard wants it.
> 
> Since this is probably not a regression to 2.2, I'd +1 this.

OK thanks,

Scott


signature.asc
Description: PGP signature


Language problems ... again

2017-11-02 Thread Kornel Benko
examples/ja/sweave.lyx not compilable. Resetting the English text at section 5
'The user manual ofSweave is at'
cures the problem.

The error message is
 
l.280 \selectlanguage{english}
  %
You may proceed, but expect wrong results

! Package babel Error: Unknown language `english'. Either you have
...

Kornel


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


Re: Slow opening of Document Settings in RC1

2017-11-02 Thread Jürgen Spitzmüller
Am Donnerstag, den 02.11.2017, 18:41 +0200 schrieb racoon:
> On 02.11.2017 19:22, Jürgen Spitzmüller wrote:
> > Am Donnerstag, den 02.11.2017, 17:21 +0200 schrieb racoon:
> > > The opening of Document Settings takes about 8 seconds for some
> > > Documents on my system. LyX becomes unresponsive in the
> > > meanwhile.
> > > (Core
> > > 2 Duo, Win7)
> > > 
> > > I noticed that the delay became longer in beta1. But it was much
> > > faster
> > > still.
> > 
> > Do you have local layout setting in these documents? If so, does
> > the
> > speed improve if you convert these to the current format (via the
> > "Convert" button)?
> 
> No local layout present.

Could you provide us with such a document?

Jürgen

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


Re: Slow opening of Document Settings in RC1

2017-11-02 Thread racoon

On 02.11.2017 19:22, Jürgen Spitzmüller wrote:

Am Donnerstag, den 02.11.2017, 17:21 +0200 schrieb racoon:

The opening of Document Settings takes about 8 seconds for some
Documents on my system. LyX becomes unresponsive in the meanwhile.
(Core
2 Duo, Win7)

I noticed that the delay became longer in beta1. But it was much
faster
still.


Do you have local layout setting in these documents? If so, does the
speed improve if you convert these to the current format (via the
"Convert" button)?


No local layout present.

Daniel



Jürgen



Daniel





Re: Slow opening of Document Settings in RC1

2017-11-02 Thread racoon

On 02.11.2017 17:21, racoon wrote:
The opening of Document Settings takes about 8 seconds for some 
Documents on my system. LyX becomes unresponsive in the meanwhile. (Core 
2 Duo, Win7)


I noticed that the delay became longer in beta1. But it was much faster 
still.


Seems like these delays change. After a fresh start of LyX it takes 
about 8 seconds. But sometimes this gets quicker when LyX has been in 
use for a while.


Daniel




Re: \sideset gui wrong?

2017-11-02 Thread Jürgen Spitzmüller
Am Donnerstag, den 02.11.2017, 18:34 +0100 schrieb Pavel Sanda:
> Scott Kostyshak wrote:
> > is after the freeze. But if translators need to make new
> > translations
> > anyway (because of more important string changes), is it bad to
> > consider
> > less important string changes?
> 
> If the string freeze was already issued, I'd say don't break it.
> This change can go to master and later to 2.3.1 if Richard wants it.

Since this is probably not a regression to 2.2, I'd +1 this.

Jürgen

> Pavel

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


Re: Slow opening of Document Settings in RC1

2017-11-02 Thread racoon

On 02.11.2017 19:02, Scott Kostyshak wrote:

On Thu, Nov 02, 2017 at 03:21:02PM +, racoon wrote:

The opening of Document Settings takes about 8 seconds for some Documents on
my system. LyX becomes unresponsive in the meanwhile. (Core 2 Duo, Win7)

I noticed that the delay became longer in beta1. But it was much faster
still.


Can you give an approximate guess on how long it was in each version?

2.3.0rc1: 8 seconds

2.3.0beta1 about how long??
2.3.0alpha1 about how long?
In 2.2.3 about how long?


For sure I did not notice such a long delay before. My guess is about 
2-4 seconds. With LyX 2.2.3 at the lower and beta 1at the upper 
boundary. I don't know about alpha1.


Daniel


I thought Uwe had reported something like this particularly for document
settings, but I could not find the trac ticket.

Thanks,

Scott






Re: \sideset gui wrong?

2017-11-02 Thread Pavel Sanda
Scott Kostyshak wrote:
> is after the freeze. But if translators need to make new translations
> anyway (because of more important string changes), is it bad to consider
> less important string changes?

If the string freeze was already issued, I'd say don't break it.
This change can go to master and later to 2.3.1 if Richard wants it.

Pavel


Re: \sideset gui wrong?

2017-11-02 Thread Scott Kostyshak
On Thu, Nov 02, 2017 at 02:13:49PM +, Pavel Sanda wrote:
> Apologizy if I got it wrong, but shouldn't by inserting math \sideset side 
> operator
> "Insert left/right side script" show center box and four small corner boxes 
> around
> instead of only two? If no, I don't see any gui difference to "Insert side 
> script".
> 
> Apart from that, there is no toolbar hint of used macro in gui as we usually 
> have,
> which would fix the following patch.
> I do not remember if we are in string freeze, so this might be master only 
> material.

We are past the string freeze. But we have pending string changes anyway
so we will have another round of translations anyway. I was planning to
send an email to translators today. I can wait a couple of days if you
think we should consider this patch. I don't have a good feeling for
when we should consider string changes after the string freeze. My first
response is that we should not consider patches like this one since it
is after the freeze. But if translators need to make new translations
anyway (because of more important string changes), is it bad to consider
less important string changes?

I guess the answer to that question depends on the behavior of
translators. Suppose we have a couple of "important" string changes,
that were committed after the string freeze because they were considered
important for having in 2.3.0. My opinion is that an "important" string
change is a string that shows up often in the average user work flow.

Suppose we are considering an additional exception to the string freeze
that is not an "important" string change (i.e. does not show up often).
To me the question comes down to: are translators less likely to
translate the important string change, in the presence of less important
string changes? i.e. do some translators see 10 string changes and think
that it would take them longer than they had planned to allocate to LyX
translations so they simply do not submit a po change; whereas if we
only had the 5 important string changes they would have submitted a po
change?

I'm curious what others think of this, since I'm trying to learn more
about the translation process. I'm trying to find the best way to be
respectful of translators' time and still get as many translations as
possible.

Scott


signature.asc
Description: PGP signature


Re: \sideset gui wrong?

2017-11-02 Thread Pavel Sanda
Pavel Sanda wrote:
> Apology if I got it wrong, but shouldn't inserting math \sideset side operator
> "Insert left/right side script" show center box and four small corner boxes 
> around
> instead of only two? If no, I don't see any gui difference to "Insert side 
> script".

If I enter "\sideset" as a string in mathed it actually works.
So it is wrong only when toolbar is used. I checked the sources little bit
and the reason seems to be that tolbar triggers Parser::parse1 which in turn
calls \sideset with params set to "Insert side scripts" version of inset,
while various "\sideset*" strings are not processed via parser when issued
directly in mathed. I think it stems from the fact that latex knows
only sideset while we distiguish gui-wise 4 cases...

CC-ing Georg.

Pavel

> Apart from that, there is no toolbar hint of used macro in gui as we usually 
> have,
> which would fix the following patch.
> I do not remember if we are in string freeze, so this might be master only 
> material.
> 
> Pavel

> diff --git a/lib/ui/stdtoolbars.inc b/lib/ui/stdtoolbars.inc
> index 9da37ecf75..8f0f6dce3f 100644
> --- a/lib/ui/stdtoolbars.inc
> +++ b/lib/ui/stdtoolbars.inc
> @@ -465,10 +465,10 @@ ToolbarSet
>   Item "bcancel" "math-insert \bcancel"
>   Item "xcancel" "math-insert \xcancel"
>   Item "cancelto" "math-insert \cancelto"
> - Item "Insert left/right side scripts" "math-insert \sideset"
> - Item "Insert right side scripts" "math-insert \sidesetr"
> - Item "Insert left side scripts" "math-insert \sidesetl"
> - Item "Insert side scripts" "math-insert \sidesetn"
> + Item "Insert left/right side scripts (sideset)" "math-insert 
> \sideset"
> + Item "Insert right side scripts (sidesetr)" "math-insert 
> \sidesetr"
> + Item "Insert left side scripts (sidesetl)" "math-insert 
> \sidesetl"
> + Item "Insert side scripts (sidesetn)" "math-insert \sidesetn"
>   Item "overset" "math-insert \overset"
>   Item "underset" "math-insert \underset"
>   Item "stackrel" "math-insert \stackrel"



Re: Slow opening of Document Settings in RC1

2017-11-02 Thread Jürgen Spitzmüller
Am Donnerstag, den 02.11.2017, 17:21 +0200 schrieb racoon:
> The opening of Document Settings takes about 8 seconds for some 
> Documents on my system. LyX becomes unresponsive in the meanwhile.
> (Core 
> 2 Duo, Win7)
> 
> I noticed that the delay became longer in beta1. But it was much
> faster 
> still.

Do you have local layout setting in these documents? If so, does the
speed improve if you convert these to the current format (via the
"Convert" button)?

Jürgen

> 
> Daniel
> 

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


Re: Beta1 is slow on undo

2017-11-02 Thread Scott Kostyshak
On Thu, Nov 02, 2017 at 03:47:21PM +, racoon wrote:
> On 07.10.2017 19:09, racoon wrote:
> > Hi,
> > 
> > I noticed that beta1 shows some slowness when undoing with some of my
> > documents. While undoing is instantaneous in 2.2.3, 2.3 takes about a
> > second to respond to it.
> > 
> > Did anyone notice this? I don't have a very fast computer though.
> 
> In RC1 the undo speed is back to normal, i.e. barely noticeable delay.
> Thanks!

Thanks for your great testing Daniel. I particularly appreciate that you
follow up on issues and let us know that certain ones are fixed.

Thanks for your attention to detail,

Scott


signature.asc
Description: PGP signature


Re: Slow opening of Document Settings in RC1

2017-11-02 Thread Scott Kostyshak
On Thu, Nov 02, 2017 at 03:21:02PM +, racoon wrote:
> The opening of Document Settings takes about 8 seconds for some Documents on
> my system. LyX becomes unresponsive in the meanwhile. (Core 2 Duo, Win7)
> 
> I noticed that the delay became longer in beta1. But it was much faster
> still.

Can you give an approximate guess on how long it was in each version?

2.3.0rc1: 8 seconds

2.3.0beta1 about how long??
2.3.0alpha1 about how long?
In 2.2.3 about how long?

I thought Uwe had reported something like this particularly for document
settings, but I could not find the trac ticket.

Thanks,

Scott


signature.asc
Description: PGP signature


Re: Beta1 is slow on undo

2017-11-02 Thread racoon

On 07.10.2017 19:09, racoon wrote:

Hi,

I noticed that beta1 shows some slowness when undoing with some of my 
documents. While undoing is instantaneous in 2.2.3, 2.3 takes about a 
second to respond to it.


Did anyone notice this? I don't have a very fast computer though.


In RC1 the undo speed is back to normal, i.e. barely noticeable delay. 
Thanks!


Daniel



Best,

Daniel







Re: Color reset in 2.3.0rc1

2017-11-02 Thread racoon

On 02.11.2017 17:30, Jürgen Spitzmüller wrote:

Am Donnerstag, den 02.11.2017, 13:55 +0200 schrieb racoon:

It seems that rc1 resets a couple of colors for some reason.


The reason is the renaming of the colors collapsable and
collapsableframe to collapsible and collapsibleframe, respectively. We
forgot to increase the prefs format.

Fixed now in master. We should backport this to 2.3.x as well, Scott.


The other I noticed was the frame of insets. Unfortunately, none of
the
colors in Preferences seems to change that frame color back. Was the
possibility of a customization of the frame abandoned?


collapsibleframe should work.


Thanks. I can verify that using collapsibleframe in the preferences file 
works.




Jürgen


Daniel





Slow opening of Document Settings in RC1

2017-11-02 Thread racoon
The opening of Document Settings takes about 8 seconds for some 
Documents on my system. LyX becomes unresponsive in the meanwhile. (Core 
2 Duo, Win7)


I noticed that the delay became longer in beta1. But it was much faster 
still.


Daniel



Re: Initial view of document (master)

2017-11-02 Thread Pavel Sanda
Jean-Marc Lasgouttes wrote:
> No it is not a recursion issue, but about knowing who asked for update. I

Then I did not get the underlying problem correctly, anyway proceed as you wish 
;)
P


Re: Initial view of document (master)

2017-11-02 Thread Jean-Marc Lasgouttes
Le 2 novembre 2017 11:24:19 GMT+01:00, Pavel Sanda  a écrit :
>Jean-Marc Lasgouttes wrote:
>> Le 31 octobre 2017 13:36:47 GMT+01:00, Jean-Marc Lasgouttes
> a écrit :
>> >Yes 2 is good for fixing the symptom, but it is very fragile...
>> 
>> We could also try
>> 4. Note when we have requested a repaint and exit early from
>paintEvent() when we did not ask for this repaint. (Or even boldlier do
>a full metrics+draw).
>
>like this?
>
>int process=0; //0 - not updating; 1 - just in update; >1 update
>requested while in update
>fun update(){
>  //not a thread safe
>  if (process) {process++; return;}
>  process++;
>
>  do_updates();
>
>  process--;
>  if (process) {process=0; assynchronously_trigger_new_update();}
>  
>}

No it is not a recursion issue, but about knowing who asked for update. I would 
set a Boolean request_redraw in requestRedraw() and reset it to false after 
redraw is done.

JMarc

Re: Color reset in 2.3.0rc1

2017-11-02 Thread Scott Kostyshak
On Thu, Nov 02, 2017 at 03:30:58PM +, Jürgen Spitzmüller wrote:

> Fixed now in master. We should backport this to 2.3.x as well, Scott.

Go ahead.

Thanks,

Scott


signature.asc
Description: PGP signature


Re: Color reset in 2.3.0rc1

2017-11-02 Thread Jürgen Spitzmüller
Am Donnerstag, den 02.11.2017, 13:55 +0200 schrieb racoon:
> It seems that rc1 resets a couple of colors for some reason.

The reason is the renaming of the colors collapsable and
collapsableframe to collapsible and collapsibleframe, respectively. We
forgot to increase the prefs format.

Fixed now in master. We should backport this to 2.3.x as well, Scott.

> The other I noticed was the frame of insets. Unfortunately, none of
> the 
> colors in Preferences seems to change that frame color back. Was the 
> possibility of a customization of the frame abandoned?

collapsibleframe should work.

Jürgen

> Daniel
> 
> 

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


Re: [LyX/master] * cs.po

2017-11-02 Thread Kornel Benko
Am Donnerstag, 2. November 2017 um 13:37:03, schrieb Pavel Sanda 
> Kornel Benko wrote:
> > Am Donnerstag, 2. November 2017 um 10:14:52, schrieb Pavel Sanda 
> > 
> > > commit 534b1e9c9062b9e526566115dd5816cea220feab
> > > Author: Pavel Sanda 
> > > Date:   Thu Nov 2 10:14:28 2017 +0100
> > > 
> > > * cs.po
> > 
> > Is it intended that you have so many (122!) tooltip messages marked as 
> > translated
> > but still in the English version?
> 
> Since I do not expect many submissions to Journal of American Chemical Society
> to happen in czech language (or reasonable usage of similar esoterical 
> layouts)
> I deliberately do not translate those -- and if you value your time, you 
> should
> do the same :)
> 
> Pavel

At least it was a good exercise to create a script for check for all tooltip 
translations :).

Kornel


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


\sideset gui wrong?

2017-11-02 Thread Pavel Sanda
Apologizy if I got it wrong, but shouldn't by inserting math \sideset side 
operator
"Insert left/right side script" show center box and four small corner boxes 
around
instead of only two? If no, I don't see any gui difference to "Insert side 
script".

Apart from that, there is no toolbar hint of used macro in gui as we usually 
have,
which would fix the following patch.
I do not remember if we are in string freeze, so this might be master only 
material.

Pavel
diff --git a/lib/ui/stdtoolbars.inc b/lib/ui/stdtoolbars.inc
index 9da37ecf75..8f0f6dce3f 100644
--- a/lib/ui/stdtoolbars.inc
+++ b/lib/ui/stdtoolbars.inc
@@ -465,10 +465,10 @@ ToolbarSet
Item "bcancel" "math-insert \bcancel"
Item "xcancel" "math-insert \xcancel"
Item "cancelto" "math-insert \cancelto"
-   Item "Insert left/right side scripts" "math-insert \sideset"
-   Item "Insert right side scripts" "math-insert \sidesetr"
-   Item "Insert left side scripts" "math-insert \sidesetl"
-   Item "Insert side scripts" "math-insert \sidesetn"
+   Item "Insert left/right side scripts (sideset)" "math-insert 
\sideset"
+   Item "Insert right side scripts (sidesetr)" "math-insert 
\sidesetr"
+   Item "Insert left side scripts (sidesetl)" "math-insert 
\sidesetl"
+   Item "Insert side scripts (sidesetn)" "math-insert \sidesetn"
Item "overset" "math-insert \overset"
Item "underset" "math-insert \underset"
Item "stackrel" "math-insert \stackrel"


Color reset in 2.3.0rc1

2017-11-02 Thread racoon
It seems that rc1 resets a couple of colors for some reason. (I don't 
know about beta1 since I started with fresh settings with that version.)


One was collapsable, aka "collapsible inset text".

The other I noticed was the frame of insets. Unfortunately, none of the 
colors in Preferences seems to change that frame color back. Was the 
possibility of a customization of the frame abandoned?


Daniel




Re: [LyX/master] * cs.po

2017-11-02 Thread Pavel Sanda
Kornel Benko wrote:
> Am Donnerstag, 2. November 2017 um 10:14:52, schrieb Pavel Sanda 
> 
> > commit 534b1e9c9062b9e526566115dd5816cea220feab
> > Author: Pavel Sanda 
> > Date:   Thu Nov 2 10:14:28 2017 +0100
> > 
> > * cs.po
> 
> Is it intended that you have so many (122!) tooltip messages marked as 
> translated
> but still in the English version?

Since I do not expect many submissions to Journal of American Chemical Society
to happen in czech language (or reasonable usage of similar esoterical layouts)
I deliberately do not translate those -- and if you value your time, you should
do the same :)

Pavel


Re: [LyX/master] * cs.po

2017-11-02 Thread Kornel Benko
Am Donnerstag, 2. November 2017 um 10:14:52, schrieb Pavel Sanda 
> commit 534b1e9c9062b9e526566115dd5816cea220feab
> Author: Pavel Sanda 
> Date:   Thu Nov 2 10:14:28 2017 +0100
> 
> * cs.po

Is it intended that you have so many (122!) tooltip messages marked as 
translated
but still in the English version?

Kornel

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


Re: Initial view of document (master)

2017-11-02 Thread Pavel Sanda
Jean-Marc Lasgouttes wrote:
> Le 31 octobre 2017 13:36:47 GMT+01:00, Jean-Marc Lasgouttes 
>  a écrit :
> >Yes 2 is good for fixing the symptom, but it is very fragile...
> 
> We could also try
> 4. Note when we have requested a repaint and exit early from paintEvent() 
> when we did not ask for this repaint. (Or even boldlier do a full 
> metrics+draw).

like this?

int process=0; //0 - not updating; 1 - just in update; >1 update requested 
while in update
fun update(){
  //not a thread safe
  if (process) {process++; return;}
  process++;

  do_updates();

  process--;
  if (process) {process=0; assynchronously_trigger_new_update();}
  
}


Re: Aw: Re: #10778: lyx aborts with CheckTeX

2017-11-02 Thread Jürgen Spitzmüller
Am Donnerstag, den 02.11.2017, 10:17 +0100 schrieb Jürgen Spitzmüller:
> Am Donnerstag, den 02.11.2017, 06:21 +0100 schrieb Martin Rötting:
> > Dear All,
> > thank you so much for all replies. Do I understand correct that I
> > might be able to continue to work when I remove the koren parts
> > (CJK
> > envionment) form my text? At the moment I can not procuce any
> > output.
> > Lyx crashes.
> 
> For the time being, yes.

BTW it should be sufficient if you wrap the Korean parts in Note
insets.

Jürgen

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


Re: Please test rc1 tars

2017-11-02 Thread Pavel Sanda
Scott Kostyshak wrote:
> Tars for 2.3.0rc1 are up:
> 
> ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.3/lyx-2.3.0rc1/
> 
> Please download the tars and test compilation, installation, and basic
> functionality. Let us know how it goes.
> 
> If all goes well and there are no major problems, I'll plan to announce
> rc1 in a few days.

Compilation works on x86 & qt4 / amd64 & qt5.

Not a showstopper for rc, but I couldn't start lyx on the machine which
has .lyx/preferences saved from master.
Is this intended or we have some missing part to be done in prefs2prefs.py?

Pavel


Re: Aw: Re: #10778: lyx aborts with CheckTeX

2017-11-02 Thread Jürgen Spitzmüller
Am Donnerstag, den 02.11.2017, 06:21 +0100 schrieb Martin Rötting:
> Dear All,
> thank you so much for all replies. Do I understand correct that I
> might be able to continue to work when I remove the koren parts (CJK
> envionment) form my text? At the moment I can not procuce any output.
> Lyx crashes.

For the time being, yes.

We know what the problem is and will fix it for the next release of
LyX.

Jürgen



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


Re: Will release 2.3.0rc1 tomorrow

2017-11-02 Thread Pavel Sanda
Richard Heck wrote:
> Do you have in mind Liviu's repo? What else is there that we in any way
> control?

Not really, I think he is building from git not tarballs, I have in mind
the usual request "here is tarbal on ftp, please check that it works
on your system before I announce it in next days". Pavel


[RFC] [PATCH] Fix configuration problems with python3 on the Mac

2017-11-02 Thread Jürgen Spitzmüller
The attached patch fixes the rather nasty problems Joel Kulesza
reported at http://www.lyx.org/trac/ticket/10671 (configure failed for
him on the Mac when LyX was launched from the finder or icon as opposed
to the terminal).

It turned out in the given case configure opened files (with open()) in
ascii encoding and bailed out at non ascii characters (my very name,
for that matter).

The patch basically extends Enrico's work at 8f70d551482a69b and uses
binary mode for reading files, rather than relying on an input
encoding.

The patch fixes the problems for Joel and it doesn't break anything
here. However, I'd appreciate double-checking from a Pythonist, since
the changes are non-trivial (to me).

Thanks
Jürgendiff --git a/lib/configure.py b/lib/configure.py
index 63b88f7bbb..e9df2e878c 100644
--- a/lib/configure.py
+++ b/lib/configure.py
@@ -1283,43 +1283,43 @@ def processLayoutFile(file, bool_docbook):
 def checkForClassExtension(x):
 '''if the extension for a latex class is not
provided, add .cls to the classname'''
-if not '.' in x:
-return x.strip() + '.cls'
+if not b'.' in x:
+return x.strip() + b'.cls'
 else:
 return x.strip()
 classname = file.split(os.sep)[-1].split('.')[0]
 # return ('LaTeX', '[a,b]', 'a', ',b,c', 'article') for \DeclareLaTeXClass[a,b,c]{article}
-p = re.compile(r'^\s*#\s*\\Declare(LaTeX|DocBook)Class\s*(\[([^,]*)(,.*)*\])*\s*{(.*)}\s*$')
-q = re.compile(r'^\s*#\s*\\DeclareCategory{(.*)}\s*$')
-classdeclaration = ""
-categorydeclaration = '""'
-for line in open(file).readlines():
+p = re.compile(b'^\s*#\s*\\Declare(LaTeX|DocBook)Class\s*(\[([^,]*)(,.*)*\])*\s*{(.*)}\s*$')
+q = re.compile(b'^\s*#\s*\\DeclareCategory{(.*)}\s*$')
+classdeclaration = b""
+categorydeclaration = b'""'
+for line in open(file, 'rb').readlines():
 res = p.search(line)
 qres = q.search(line)
 if res != None:
 (classtype, optAll, opt, opt1, desc) = res.groups()
-avai = {'LaTeX':'false', 'DocBook':bool_docbook}[classtype]
+avai = {b'LaTeX':b'false', b'DocBook':bool_docbook.encode('ascii')}[classtype]
 if opt == None:
-opt = classname
-prereq_latex = checkForClassExtension(classname)
+opt = classname.encode('ascii')
+prereq_latex = checkForClassExtension(classname.encode('ascii'))
 else:
-prereq_list = optAll[1:-1].split(',')
+prereq_list = optAll[1:-1].split(b',')
 prereq_list = list(map(checkForClassExtension, prereq_list))
-prereq_latex = ','.join(prereq_list)
-prereq_docbook = {'true':'', 'false':'docbook'}[bool_docbook]
-prereq = {'LaTeX':prereq_latex, 'DocBook':prereq_docbook}[classtype]
-classdeclaration = ('"%s" "%s" "%s" "%s" "%s"'
+prereq_latex = b','.join(prereq_list)
+prereq_docbook = {'true':b'', 'false':b'docbook'}[bool_docbook]
+prereq = {b'LaTeX':prereq_latex, b'DocBook':prereq_docbook}[classtype]
+classdeclaration = (b'"%s" "%s" "%s" "%s" "%s"'
% (classname, opt, desc, avai, prereq))
-if categorydeclaration != '""':
-return classdeclaration + " " + categorydeclaration
+if categorydeclaration != b'""':
+return classdeclaration + b" " + categorydeclaration
 if qres != None:
- categorydeclaration = '"%s"' % (qres.groups()[0])
- if classdeclaration != "":
- return classdeclaration + " " + categorydeclaration
-if classdeclaration != "":
-return classdeclaration + " " + categorydeclaration
+ categorydeclaration = b'"%s"' % (qres.groups()[0])
+ if classdeclaration != b"":
+ return classdeclaration + b" " + categorydeclaration
+if classdeclaration != b"":
+return classdeclaration + b" " + categorydeclaration
 logger.warning("Layout file " + file + " has no \DeclareXXClass line. ")
-return ""
+return b""
 
 
 def checkLatexConfig(check_config, bool_docbook):
@@ -1337,8 +1337,8 @@ def checkLatexConfig(check_config, bool_docbook):
 # fails, we still have something to start lyx.
 logger.info(msg + ' default values')
 logger.info('+checking list of textclasses... ')
-tx = open('textclass.lst', 'w')
-tx.write('''
+tx = open('textclass.lst', 'wb')
+tx.write(b'''
 # This file declares layouts and their associated definition files
 # (include dir. relative to the place where this file is).
 # It contains only default values, since chkconfig.ltx could not be run
@@ -1362,7 +1362,7 @@ def checkLatexConfig(check_config, bool_docbook):
 if foundClasses.count(cleanclass) == 0: # not found before