subject:"Release status"


Am 18.03.2014 09:02, schrieb Vincent van Ravesteijn:


See its changelog in master - I completely changed the handling of Perl, its
interaction with MikTeX and fixed some bugs. I can also not test all the
different languages (dictionaries and thesaurus) due to lack of time.
Btw. to where can I upload the updated dependency package?


It still resides at sourceforge I guess. Is this the dependency
package which is downloaded automatically by CMake ?


Yes, I want to upload an updated version of it. Where on SourceForge is the 
current version located?

thanks and regards
Uwe

Re: 2.1 release status


Am 18.03.2014 08:53, schrieb Vincent van Ravesteijn:


LyX 2.1 is far past its due data, so, yes, I want to release as soon
as possible.


OK. The installer is ready as I said. I can ship an older version of ImageMagick without the bug and 
hope I get a fixed verson before the final release.



However, before I ca release a Win installer, bug
http://www.lyx.org/trac/ticket/9035
must be fixed. This one is so super annoying and this bug appears for every
viewer, not only for PDFS.


Please don't tell me you can't release a win installer if this bug is
not fixed. Instead, you don't _want_ to release it.


What?! Of course I CAN release an installer of any LyX version but I don't want to release a LyX 
version with an annoying regression.



This annoys me, because probably I'm the only one who can and want to fix this.


My spare time is very limited and my programming skills too so I cannot fix this issue but 
nevertheless want to.


regards Uwe

Re: 2.1 release status


Am 18.03.2014 09:02, schrieb Vincent van Ravesteijn:


See its changelog in master - I completely changed the handling of Perl, its
interaction with MikTeX and fixed some bugs. I can also not test all the
different languages (dictionaries and thesaurus) due to lack of time.
Btw. to where can I upload the updated dependency package?


It still resides at sourceforge I guess. Is this the dependency
package which is downloaded automatically by CMake ?


Yes, I want to upload an updated version of it. Where on SourceForge is the 
current version located?

thanks and regards
Uwe

Re: 2.1 release status


Am 18.03.2014 08:53, schrieb Vincent van Ravesteijn:


LyX 2.1 is far past its due data, so, yes, I want to release as soon
as possible.


OK. The installer is ready as I said. I can ship an older version of ImageMagick without the bug and 
hope I get a fixed verson before the final release.



However, before I ca release a Win installer, bug
http://www.lyx.org/trac/ticket/9035
must be fixed. This one is so super annoying and this bug appears for every
viewer, not only for PDFS.


Please don't tell me you can't release a win installer if this bug is
not fixed. Instead, you don't _want_ to release it.


What?! Of course I CAN release an installer of any LyX version but I don't want to release a LyX 
version with an annoying regression.



This annoys me, because probably I'm the only one who can and want to fix this.


My spare time is very limited and my programming skills too so I cannot fix this issue but 
nevertheless want to.


regards Uwe

Re: 2.1 release status

On Mon, Mar 17, 2014 at 11:29 PM, Uwe Stöhr uwesto...@web.de wrote:
 Am 13.03.2014 09:08, schrieb Vincent van Ravesteijn:


 - the last few Imagemagick have a bug in the handling of PDF files and I
 don't want to release an older IM version because of security bugs they
 fixed (I already contacted the IM developers).


 What is the bug ?


 PDFs with a bounding or mediabox cannot be viewed inside LyX.


Not much we can do about it.

 -

 If you want to release LyX as soon as possible, then I will stop working on
 the docs right now so that the translators have some time to translate.


LyX 2.1 is far past its due data, so, yes, I want to release as soon
as possible.


 However, before I ca release a Win installer, bug
 http://www.lyx.org/trac/ticket/9035
 must be fixed. This one is so super annoying and this bug appears for every
 viewer, not only for PDFS.


Please don't tell me you can't release a win installer if this bug is
not fixed. Instead, you don't _want_ to release it.

This annoys me, because probably I'm the only one who can and want to fix this.

Vincent

Re: 2.1 release status

On Mon, Mar 17, 2014 at 11:46 PM, Uwe Stöhr uwesto...@web.de wrote:
 Am 13.03.2014 09:18, schrieb Vincent van Ravesteijn:


 ... which means that in the ideal future, if you want a new feature
 accepted into LyX, you should provide documentation about it and have
 it well tested


 I am a bit annoyed about this. I only want a working release. I develop LyX
 for 10 years now and helped to release LyX 1.4, 1.5, 1.6 and 2.0. It turned
 out that it is the most effective way to update the docs after the feature
 freeze.

Why are you annoyed ? I just thought it would be easier. And if we
would catch bugs when the documentation is written (as you claim) it
would be a bonus.


 - I need a test release for the win installer. This can be a RC1 release
 but
 I need then some weeks afterwards to get enough feedback.


 We have two beta releases released with a windows installer. What
 changed in the installer that you need a new RC release and you need a
 few weeks to get feedback ?


 See its changelog in master - I completely changed the handling of Perl, its
 interaction with MikTeX and fixed some bugs. I can also not test all the
 different languages (dictionaries and thesaurus) due to lack of time.
 Btw. to where can I upload the updated dependency package?


It still resides at sourceforge I guess. Is this the dependency
package which is downloaded automatically by CMake ?

Vincent

Re: 2.1 release status

2014-03-18 Thread Scott Kostyshak

On Tue, Mar 18, 2014 at 3:53 AM, Vincent van Ravesteijn v...@lyx.org wrote:
 On Mon, Mar 17, 2014 at 11:29 PM, Uwe Stöhr uwesto...@web.de wrote:
 Am 13.03.2014 09:08, schrieb Vincent van Ravesteijn:


 - the last few Imagemagick have a bug in the handling of PDF files and I
 don't want to release an older IM version because of security bugs they
 fixed (I already contacted the IM developers).


 What is the bug ?


 PDFs with a bounding or mediabox cannot be viewed inside LyX.


 Not much we can do about it.

 -

 If you want to release LyX as soon as possible, then I will stop working on
 the docs right now so that the translators have some time to translate.


 LyX 2.1 is far past its due data, so, yes, I want to release as soon
 as possible.


 However, before I ca release a Win installer, bug
 http://www.lyx.org/trac/ticket/9035
 must be fixed. This one is so super annoying and this bug appears for every
 viewer, not only for PDFS.


 Please don't tell me you can't release a win installer if this bug is
 not fixed. Instead, you don't _want_ to release it.

 This annoys me, because probably I'm the only one who can and want to fix 
 this.

The commit could be reverted. It never made it into a release so there
would be no regression, and reverting it would indeed prevent a
regression. Only one person reported the bug: the same person reported
the bug on Ubuntu and on the LyX tracker and he is the same one who
sent in the patch. From what I understand, if zombie processes aren't
collected their memory is still freed, so it is just an accounting
issue. Or no?

Scott

Re: 2.1 release status

2014-03-18 Thread Georg Baum

Enrico Forestieri wrote:

 On Thu, Mar 13, 2014 at 10:43:36PM +0100, Georg Baum wrote:
 
 Vincent van Ravesteijn wrote:
 
  I did some debugging. The problem lies in the use of
  QProcess::startDetached. If you call this function with a the cmd
  prefix, you will inevitably get a command window.
 
 So in some sense it does what it is told to do;-)
 
 This is new to me. On Vista I see no command window. This must be
 a novelty of newer Windows version.

Strange. Maybe this also depends on the used qt version?

  Omitting the cmd could be a solution. Does it have any use to add the
  latexEnvCmdPrefix to a viewer command ?
 
 This looks rather wrong to me. This should only be added when running a
 TeX related converter, e.g. LaTeX, BibTeX etc.
 
 No, all enviroment variables should be correctly made available to all
 subprocesses, and (thanks to QProcess) this is the only way we have to
 modify the environment.

I admit I did not think of xdvi, which might need to fetch stuff from other 
places, because the DVI file may contain references.


Georg

Re: 2.1 release status

2014-03-18 Thread Enrico Forestieri

On Tue, Mar 18, 2014 at 09:16:29PM +0100, Georg Baum wrote:
 Enrico Forestieri wrote:
 
  On Thu, Mar 13, 2014 at 10:43:36PM +0100, Georg Baum wrote:
  
  Vincent van Ravesteijn wrote:
  
   I did some debugging. The problem lies in the use of
   QProcess::startDetached. If you call this function with a the cmd
   prefix, you will inevitably get a command window.
  
  So in some sense it does what it is told to do;-)
  
  This is new to me. On Vista I see no command window. This must be
  a novelty of newer Windows version.
 
 Strange. Maybe this also depends on the used qt version?

No, simply I was testing the native Windows version of LyX 2.0, not 2.1,
where the bug occurs. Sorry, it was not clear to me that this was related
to 2.1 only.

-- 
Enrico

Re: 2.1 release status

On Mon, Mar 17, 2014 at 11:29 PM, Uwe Stöhr  wrote:
> Am 13.03.2014 09:08, schrieb Vincent van Ravesteijn:
>
>
 - the last few Imagemagick have a bug in the handling of PDF files and I
 don't want to release an older IM version because of security bugs they
 fixed (I already contacted the IM developers).
>>
>>
>> What is the bug ?
>
>
> PDFs with a bounding or mediabox cannot be viewed inside LyX.
>

Not much we can do about it.

> -
>
> If you want to release LyX as soon as possible, then I will stop working on
> the docs right now so that the translators have some time to translate.


LyX 2.1 is far past its due data, so, yes, I want to release as soon
as possible.

>
> However, before I ca release a Win installer, bug
> http://www.lyx.org/trac/ticket/9035
> must be fixed. This one is so super annoying and this bug appears for every
> viewer, not only for PDFS.
>

Please don't tell me you can't release a win installer if this bug is
not fixed. Instead, you don't _want_ to release it.

This annoys me, because probably I'm the only one who can and want to fix this.

Vincent

Re: 2.1 release status

On Mon, Mar 17, 2014 at 11:46 PM, Uwe Stöhr  wrote:
> Am 13.03.2014 09:18, schrieb Vincent van Ravesteijn:
>
>
>> ... which means that in the ideal future, if you want a new feature
>> accepted into LyX, you should provide documentation about it and have
>> it well tested
>
>
> I am a bit annoyed about this. I only want a working release. I develop LyX
> for 10 years now and helped to release LyX 1.4, 1.5, 1.6 and 2.0. It turned
> out that it is the most effective way to update the docs after the feature
> freeze.

Why are you annoyed ? I just thought it would be easier. And if we
would catch bugs when the documentation is written (as you claim) it
would be a bonus.

>
>>> - I need a test release for the win installer. This can be a RC1 release
>>> but
>>> I need then some weeks afterwards to get enough feedback.
>>
>>
>> We have two beta releases released with a windows installer. What
>> changed in the installer that you need a new RC release and you need a
>> few weeks to get feedback ?
>
>
> See its changelog in master - I completely changed the handling of Perl, its
> interaction with MikTeX and fixed some bugs. I can also not test all the
> different languages (dictionaries and thesaurus) due to lack of time.
> Btw. to where can I upload the updated dependency package?
>

It still resides at sourceforge I guess. Is this the dependency
package which is downloaded automatically by CMake ?

Vincent

Re: 2.1 release status

2014-03-18 Thread Scott Kostyshak

On Tue, Mar 18, 2014 at 3:53 AM, Vincent van Ravesteijn  wrote:
> On Mon, Mar 17, 2014 at 11:29 PM, Uwe Stöhr  wrote:
>> Am 13.03.2014 09:08, schrieb Vincent van Ravesteijn:
>>
>>
> - the last few Imagemagick have a bug in the handling of PDF files and I
> don't want to release an older IM version because of security bugs they
> fixed (I already contacted the IM developers).
>>>
>>>
>>> What is the bug ?
>>
>>
>> PDFs with a bounding or mediabox cannot be viewed inside LyX.
>>
>
> Not much we can do about it.
>
>> -
>>
>> If you want to release LyX as soon as possible, then I will stop working on
>> the docs right now so that the translators have some time to translate.
>
>
> LyX 2.1 is far past its due data, so, yes, I want to release as soon
> as possible.
>
>>
>> However, before I ca release a Win installer, bug
>> http://www.lyx.org/trac/ticket/9035
>> must be fixed. This one is so super annoying and this bug appears for every
>> viewer, not only for PDFS.
>>
>
> Please don't tell me you can't release a win installer if this bug is
> not fixed. Instead, you don't _want_ to release it.
>
> This annoys me, because probably I'm the only one who can and want to fix 
> this.

The commit could be reverted. It never made it into a release so there
would be no regression, and reverting it would indeed prevent a
regression. Only one person reported the bug: the same person reported
the bug on Ubuntu and on the LyX tracker and he is the same one who
sent in the patch. From what I understand, if zombie processes aren't
collected their memory is still freed, so it is "just" an accounting
issue. Or no?

Scott

Re: 2.1 release status

2014-03-18 Thread Georg Baum

Enrico Forestieri wrote:

> On Thu, Mar 13, 2014 at 10:43:36PM +0100, Georg Baum wrote:
> 
>> Vincent van Ravesteijn wrote:
>> 
>> > I did some debugging. The problem lies in the use of
>> > QProcess::startDetached. If you call this function with a the "cmd"
>> > prefix, you will inevitably get a command window.
>> 
>> So in some sense it does what it is told to do;-)
> 
> This is new to me. On Vista I see no command window. This must be
> a novelty of newer Windows version.

Strange. Maybe this also depends on the used qt version?

>> > Omitting the "cmd" could be a solution. Does it have any use to add the
>> > latexEnvCmdPrefix to a viewer command ?
>> 
>> This looks rather wrong to me. This should only be added when running a
>> TeX related converter, e.g. LaTeX, BibTeX etc.
> 
> No, all enviroment variables should be correctly made available to all
> subprocesses, and (thanks to QProcess) this is the only way we have to
> modify the environment.

I admit I did not think of xdvi, which might need to fetch stuff from other 
places, because the DVI file may contain references.


Georg

Re: 2.1 release status

2014-03-18 Thread Enrico Forestieri

On Tue, Mar 18, 2014 at 09:16:29PM +0100, Georg Baum wrote:
> Enrico Forestieri wrote:
> 
> > On Thu, Mar 13, 2014 at 10:43:36PM +0100, Georg Baum wrote:
> > 
> >> Vincent van Ravesteijn wrote:
> >> 
> >> > I did some debugging. The problem lies in the use of
> >> > QProcess::startDetached. If you call this function with a the "cmd"
> >> > prefix, you will inevitably get a command window.
> >> 
> >> So in some sense it does what it is told to do;-)
> > 
> > This is new to me. On Vista I see no command window. This must be
> > a novelty of newer Windows version.
> 
> Strange. Maybe this also depends on the used qt version?

No, simply I was testing the native Windows version of LyX 2.0, not 2.1,
where the bug occurs. Sorry, it was not clear to me that this was related
to 2.1 only.

-- 
Enrico

Re: 2.1 release status


Am 13.03.2014 09:08, schrieb Vincent van Ravesteijn:


- the last few Imagemagick have a bug in the handling of PDF files and I
don't want to release an older IM version because of security bugs they
fixed (I already contacted the IM developers).


What is the bug ?


PDFs with a bounding or mediabox cannot be viewed inside LyX.

-

If you want to release LyX as soon as possible, then I will stop working on the docs right now so 
that the translators have some time to translate.


However, before I ca release a Win installer, bug
http://www.lyx.org/trac/ticket/9035
must be fixed. This one is so super annoying and this bug appears for every 
viewer, not only for PDFS.

regards Uwe

Re: 2.1 release status


Am 13.03.2014 09:11, schrieb Vincent van Ravesteijn:


The bug is only in LyX 2.1git and yes, it is super annoying.
I created now a bug:
http://www.lyx.org/trac/ticket/9035


I agree it is super annoying, but at the same time I agree with Georg:
the issue didn't really make it to lyx-devel or trac, so people are
not annoyed enough ;).


The testers even might have expected a console because they tested beta versions and in the past I 
packaged LyX beta version compiled so that there was always a console.


Before discussing the annoyance we should better try to fix this one.

regards Uwe

Re: 2.1 release status

Am 13.03.2014 09:18, schrieb Vincent van Ravesteijn:

... which means that in the ideal future, if you want a new feature
accepted into LyX, you should provide documentation about it and have
it well tested

I am a bit annoyed about this. I only want a working release. I develop LyX for 10 years now and
helped to release LyX 1.4, 1.5, 1.6 and 2.0. It turned out that it is the most effective way to
update the docs after the feature freeze. Formerly we added the documentation immediately but this
was error-prone because

- the feature contributer wrote the documentation
- the documentation was written long before other features went in
It is normal that the contributer of a feature see it with different eyes than others and normal
users. This also applies for my own contributions and I am happy to have people like Ignacio and
Jean-Pierre who point me to issues in the doc texts so that normal users can understand them.
However, many bugs arise months after the feature contribution because e.g. the framework later was
changed etc. So the final documentation helps to test every feature with the feature-ready release.

- I need a test release for the win installer. This can be a RC1 release but
I need then some weeks afterwards to get enough feedback.

We have two beta releases released with a windows installer. What
changed in the installer that you need a new RC release and you need a
few weeks to get feedback ?

See its changelog in master - I completely changed the handling of Perl, its interaction with MikTeX
and fixed some bugs. I can also not test all the different languages (dictionaries and thesaurus)
due to lack of time.

Btw. to where can I upload the updated dependency package?

@ everybody: Can you please review
http://wiki.lyx.org/LyX/NewInLyX21
if all new features are listed so that I know what to document.

These are not blocking issues, but thanks for reminding people.

I of course know that this is no blocker but why does nobody wants to enrich
the page?

regards Uwe

Re: 2.1 release status


Am 13.03.2014 09:08, schrieb Vincent van Ravesteijn:


- the last few Imagemagick have a bug in the handling of PDF files and I
don't want to release an older IM version because of security bugs they
fixed (I already contacted the IM developers).


What is the bug ?


PDFs with a bounding or mediabox cannot be viewed inside LyX.

-

If you want to release LyX as soon as possible, then I will stop working on the docs right now so 
that the translators have some time to translate.


However, before I ca release a Win installer, bug
http://www.lyx.org/trac/ticket/9035
must be fixed. This one is so super annoying and this bug appears for every 
viewer, not only for PDFS.

regards Uwe

Re: 2.1 release status


Am 13.03.2014 09:11, schrieb Vincent van Ravesteijn:


The bug is only in LyX 2.1git and yes, it is super annoying.
I created now a bug:
http://www.lyx.org/trac/ticket/9035


I agree it is super annoying, but at the same time I agree with Georg:
the issue didn't really make it to lyx-devel or trac, so people are
not annoyed enough ;).


The testers even might have expected a console because they tested beta versions and in the past I 
packaged LyX beta version compiled so that there was always a console.


Before discussing the annoyance we should better try to fix this one.

regards Uwe

Re: 2.1 release status

Am 13.03.2014 09:18, schrieb Vincent van Ravesteijn:

... which means that in the ideal future, if you want a new feature
accepted into LyX, you should provide documentation about it and have
it well tested

- I need a test release for the win installer. This can be a RC1 release but
I need then some weeks afterwards to get enough feedback.

We have two beta releases released with a windows installer. What
changed in the installer that you need a new RC release and you need a
few weeks to get feedback ?

Btw. to where can I upload the updated dependency package?

@ everybody: Can you please review
http://wiki.lyx.org/LyX/NewInLyX21
if all new features are listed so that I know what to document.

These are not blocking issues, but thanks for reminding people.

I of course know that this is no blocker but why does nobody wants to enrich
the page?

regards Uwe

Re: 2.1 release status

On 13 Mar 2014 at 21:48:16 , Georg Baum (georg.b...@post.rwth-aachen.de) wrote:
Benjamin Piwowarski wrote: 

 I have another question (this was what I was trying to fix also): 
 - why the python2() code in os.cpp (line 41) does not prevent the wrong 
 python to be selected. 

I think this is the most important question. After all, we do not have 
control over PATH, and in many cases we cannot set a sensible path prefix 
(e.g. on many linux systems).  


 In particular, why is the test out.first  0 and 
 not out.first != 0 ? 

Because out.first is -1 on error. It is either a hard coded -1 in LyX, or 
the return value of pclose(), _pclose() or fclose(). Which one is used on OS 
X? What does it retun on error? 
This is the in the documentation of popen/pclose: the pclose() function waits 
for the associated process to terminate; it returns the exit status of the 
command, as returned by wait4(2).



 This would have prevented the python3 version from being selected. 

Why? This means that prefixIs(out.second, Python 2) returns true for 
python 3. How can that happen? 


You are right. Just read to fast the condition.

Re: 2.1 release status

On 13 Mar 2014 at 21:48:16 , Georg Baum (georg.b...@post.rwth-aachen.de) wrote:
Benjamin Piwowarski wrote:  

 I have another question (this was what I was trying to fix also):  
 - why the python2() code in os.cpp (line 41) does not prevent the wrong  
 python to be selected.  

I think this is the most important question. After all, we do not have  
control over PATH, and in many cases we cannot set a sensible path prefix  
(e.g. on many linux systems).  

OK, I think I know what is happening: when calling the first time the function 
python2(), the path was not modified according to the lyxrc file. It checks 
that python in the PATH is the a python2 one and just stores a relative path 
(“python”). Then the PATH is modified, and if we are unlucky, python 3 is now 
the first one in the list of PATH (this is what was happening on OP of #8925) 
and is used for subsequent calls to python.

Attached is a patch that simply forces python to be an absolute PATH by 
removing the default “python” command. I am unsure whether this is the best 
thing to do, but at least it fixes the problem.
 

Benjamin

0001-Forces-to-use-a-full-path-for-python.patch
Description: Binary data

Re: 2.1 release status

On Thu, Mar 13, 2014 at 10:29:29PM +0100, Vincent van Ravesteijn wrote:
 
 I did some debugging. The problem lies in the use of
 QProcess::startDetached. If you call this function with a the cmd
 prefix, you will inevitably get a command window.

That's the only way to use batch files on Windows with QProcess.

 Omitting the cmd could be a solution. Does it have any use to add
 the latexEnvCmdPrefix to a viewer command ?

Yes, it has. Any spawned subprocess should receive a copy of the relevant
environment variables. This was initially done using Qt, but due to
https://bugreports.qt-project.org/browse/QTBUG-19885
we have to use this workaround.

As an example, I attach a wrapper I use to launch xdvi. It relies on
TEXINPUTS being correctly set.

-- 
Enrico
#!/bin/sh
#
# Visualizza un file dvi in portrait o landscape

file=
args=
for arg in $@; do
case $arg in
-*) args=$args $arg ;;
*)  if [ -f $arg -o -f $arg.dvi ]; then
dir=`dirname $arg`
file=`basename $arg`
cd $dir
if [ ! -f $file ]; then
file=$file.dvi
fi
args=$args \$file\
else
args=$args $arg
fi ;;
esac
done

if test -f LYXINPUTPATH; then
  # we were called from LyX, so the input path is in LYXINPUTPATH
  PWD=`cat LYXINPUTPATH`
else
  PWD=.
  PWD=$PWD:$PWD/figs
fi

if test -z $TEXINPUTS; then
  TEXINPUTS=$PWD:
else
  case $TEXINPUTS in
:*) TEXINPUTS=:$PWD$TEXINPUTS ;;
*:) TEXINPUTS=$TEXINPUTS$PWD: ;;
  esac
fi
export TEXINPUTS

paper=
if [ -f $file ]; then
  # use landscape if horiz = vert dimension in dvi file
  line=`dvitype $file | grep maxv=`
  maxv=`expr $line : 'maxv=\(.*\), maxh.*'`
  maxh=`expr $line : '.*maxh=\(.*\), maxstack.*'`
  if [ $maxh -ge $maxv ]; then
paper=-paper a4r
  else
paper=-geometry 638 -margins 1.5
  fi
fi

eval exec /usr/bin/xdvi $paper -gamma 2 -expert $args

Re: 2.1 release status

On Thu, Mar 13, 2014 at 10:43:36PM +0100, Georg Baum wrote:

 Vincent van Ravesteijn wrote:
 
  I did some debugging. The problem lies in the use of
  QProcess::startDetached. If you call this function with a the cmd
  prefix, you will inevitably get a command window.
 
 So in some sense it does what it is told to do;-)

This is new to me. On Vista I see no command window. This must be
a novelty of newer Windows version.

  Omitting the cmd could be a solution. Does it have any use to add the
  latexEnvCmdPrefix to a viewer command ?
 
 This looks rather wrong to me. This should only be added when running a TeX 
 related converter, e.g. LaTeX, BibTeX etc.

No, all enviroment variables should be correctly made available to all
subprocesses, and (thanks to QProcess) this is the only way we have to
modify the environment.

 There are more dangerous code parts, e.g. 
 
 subst(command, cmd /d /c , );
 
 looks quite fragile.

That code is #ifdef'd out, normally.

-- 
Enrico

Re: 2.1 release status

On 13 Mar 2014 at 21:48:16 , Georg Baum (georg.b...@post.rwth-aachen.de) wrote:
Benjamin Piwowarski wrote: 

> I have another question (this was what I was trying to fix also): 
> - why the python2() code in os.cpp (line 41) does not prevent the wrong 
> python to be selected. 

I think this is the most important question. After all, we do not have 
control over PATH, and in many cases we cannot set a sensible path prefix 
(e.g. on many linux systems).  

> In particular, why is the test out.first < 0 and 
> not out.first != 0 ? 

Because out.first is -1 on error. It is either a hard coded -1 in LyX, or 
the return value of pclose(), _pclose() or fclose(). Which one is used on OS 
X? What does it retun on error? 
This is the in the documentation of popen/pclose: the pclose() function waits 
for the associated process to terminate; it returns the exit status of the 
command, as returned by wait4(2).

> This would have prevented the python3 version from being selected. 

Why? This means that prefixIs(out.second, "Python 2") returns true for 
python 3. How can that happen? 

You are right. Just read to fast the condition.

Re: 2.1 release status

On 13 Mar 2014 at 21:48:16 , Georg Baum (georg.b...@post.rwth-aachen.de) wrote:
Benjamin Piwowarski wrote:  

> I have another question (this was what I was trying to fix also):  
> - why the python2() code in os.cpp (line 41) does not prevent the wrong  
> python to be selected.  

I think this is the most important question. After all, we do not have  
control over PATH, and in many cases we cannot set a sensible path prefix  
(e.g. on many linux systems).  

OK, I think I know what is happening: when calling the first time the function 
python2(), the path was not modified according to the lyxrc file. It checks 
that python in the PATH is the a python2 one and just stores a relative path 
(“python”). Then the PATH is modified, and if we are unlucky, python 3 is now 
the first one in the list of PATH (this is what was happening on OP of #8925) 
and is used for subsequent calls to python.

Attached is a patch that simply forces python to be an absolute PATH by 
removing the default “python” command. I am unsure whether this is the best 
thing to do, but at least it fixes the problem.

Benjamin

0001-Forces-to-use-a-full-path-for-python.patch
Description: Binary data

Re: 2.1 release status

On Thu, Mar 13, 2014 at 10:29:29PM +0100, Vincent van Ravesteijn wrote:
> 
> I did some debugging. The problem lies in the use of
> QProcess::startDetached. If you call this function with a the "cmd"
> prefix, you will inevitably get a command window.

That's the only way to use batch files on Windows with QProcess.

> Omitting the "cmd" could be a solution. Does it have any use to add
> the latexEnvCmdPrefix to a viewer command ?

Yes, it has. Any spawned subprocess should receive a copy of the relevant
environment variables. This was initially done using Qt, but due to
https://bugreports.qt-project.org/browse/QTBUG-19885
we have to use this workaround.

As an example, I attach a wrapper I use to launch xdvi. It relies on
TEXINPUTS being correctly set.

-- 
Enrico
#!/bin/sh
#
# Visualizza un file dvi in portrait o landscape

file=""
args=""
for arg in "$@"; do
case $arg in
-*) args="$args $arg" ;;
*)  if [ -f "$arg" -o -f "$arg.dvi" ]; then
dir=`dirname "$arg"`
file=`basename "$arg"`
cd "$dir"
if [ ! -f "$file" ]; then
file=$file.dvi
fi
args="$args \"$file\""
else
args="$args $arg"
fi ;;
esac
done

if test -f LYXINPUTPATH; then
  # we were called from LyX, so the input path is in LYXINPUTPATH
  PWD=`cat LYXINPUTPATH`
else
  PWD="."
  PWD=$PWD:$PWD/figs
fi

if test -z "$TEXINPUTS"; then
  TEXINPUTS=$PWD:
else
  case $TEXINPUTS in
:*) TEXINPUTS=:$PWD$TEXINPUTS ;;
*:) TEXINPUTS=$TEXINPUTS$PWD: ;;
  esac
fi
export TEXINPUTS

paper=
if [ -f "$file" ]; then
  # use landscape if horiz >= vert dimension in dvi file
  line=`dvitype "$file" | grep maxv=`
  maxv=`expr "$line" : 'maxv=\(.*\), maxh.*'`
  maxh=`expr "$line" : '.*maxh=\(.*\), maxstack.*'`
  if [ $maxh -ge $maxv ]; then
paper="-paper a4r"
  else
paper="-geometry 638 -margins 1.5"
  fi
fi

eval exec /usr/bin/xdvi $paper -gamma 2 -expert $args

Re: 2.1 release status

On Thu, Mar 13, 2014 at 10:43:36PM +0100, Georg Baum wrote:

> Vincent van Ravesteijn wrote:
> 
> > I did some debugging. The problem lies in the use of
> > QProcess::startDetached. If you call this function with a the "cmd"
> > prefix, you will inevitably get a command window.
> 
> So in some sense it does what it is told to do;-)

This is new to me. On Vista I see no command window. This must be
a novelty of newer Windows version.

> > Omitting the "cmd" could be a solution. Does it have any use to add the
> > latexEnvCmdPrefix to a viewer command ?
> 
> This looks rather wrong to me. This should only be added when running a TeX 
> related converter, e.g. LaTeX, BibTeX etc.

No, all enviroment variables should be correctly made available to all
subprocesses, and (thanks to QProcess) this is the only way we have to
modify the environment.

> There are more dangerous code parts, e.g. 
> 
> subst(command, "cmd /d /c ", "");
> 
> looks quite fragile.

That code is #ifdef'd out, normally.

-- 
Enrico

Re: 2.1 release status


 Besides this I have 2 further issues open:
 - pdfcrop, that we use for cropped PDF output does not work on Windows
 64bit (I sent a fix to the maintainer)


Using pdfcrop is a new feature and this will not be blocking the release.


 This is not a LyX bug, so we should not wait for it. If it's fixed, we can
 of course update the installer.

... which is also true.



 - the last few Imagemagick have a bug in the handling of PDF files and I
 don't want to release an older IM version because of security bugs they
 fixed (I already contacted the IM developers).


What is the bug ?

Vincent

Re: 2.1 release status

On Thu, Mar 13, 2014 at 1:01 AM, Uwe Stöhr uwesto...@web.de wrote:
 Am 12.03.2014 22:01, schrieb Georg Baum:

 Uwe Stöhr wrote:


 I asked already for a list of features with missing documentation, but got
 no reply, so here is the question again: Which features are not yet
 documented?


 the red ones in
 http://wiki.lyx.org/LyX/NewInLyX21


 - Windows-specific: when you view a PDF a console window pops up and does
 not disappear. This a super annoying regression to LyX 2.0


 It can't be super annoying. This is known for several months, and there is
 no bug entry targeted to 2.1.0 (if my search was correct there is no bug
 entry at all about this problem).


 The bug is only in LyX 2.1git and yes, it is super annoying.
 I created now a bug:
 http://www.lyx.org/trac/ticket/9035



I agree it is super annoying, but at the same time I agree with Georg:
the issue didn't really make it to lyx-devel or trac, so people are
not annoyed enough ;).

Vincent

Re: 2.1 release status

On Mon, Mar 10, 2014 at 11:10 PM, Uwe Stöhr uwesto...@web.de wrote:
 Am 10.03.2014 21:47, schrieb Vincent van Ravesteijn:


 I'm now confused on the status on Windows. For me it looks rather ok.


 I just finished the Win installer for LyX 2.1. But LyX itself cannot be
 released as it is because:

 - the documentation is not yet fully updated and I recently found bugs for
 every new feature I
 described in the docs.

... which means that in the ideal future, if you want a new feature
accepted into LyX, you should provide documentation about it and have
it well tested


 - Windows-specific: when you view a PDF a console window pops up and does
 not disappear. This a super annoying regression to LyX 2.0

 - I need a test release for the win installer. This can be a RC1 release but
 I need then some weeks afterwards to get enough feedback.

We have two beta releases released with a windows installer. What
changed in the installer that you need a new RC release and you need a
few weeks to get feedback ?



 - we need here some more images to advertise our new release! ;-):
 http://wiki.lyx.org/LyX/NewInLyX21
 I mean only 2 images and a desert of letters is not very pleasant. Compare
 this to
 http://wiki.lyx.org/LyX/NewInLyX20

 @ everybody: Can you please review
 http://wiki.lyx.org/LyX/NewInLyX21
 if all new features are listed so that I know what to document.

These are not blocking issues, but thanks for reminding people.

Vincent

Re: 2.1 release status

 Is it correct that the MacOS problems are now all solved except for some 
 cosmetic issues ?

 I don't know. Currently it's not clear. The package I've build is usable on 
 Benjamin's 10.9
 and it's not usable on the machine of the OP of ticket 8925. That's very 
 strange.

[...]

 We have to provide more than one package for different Mac OS versions.
 The package build on 10.8 doesn't run on 10.5 and I had problems with
 the package build on 10.6 (works on 10.5 too) on higher OS versions.

 Stephan

If I understand correctly:

- you are able to produce packages for 10.6, and for 10.8;
- these two packages work on all versions.

However, it still doesn't work for the OP of #8925. 5 days ago, he
couldn't find a patched dmg. I don't know what is patched, but are
you still sure the new package doesn't work on his machine ?

Vincent

Re: 2.1 release status

2014-03-13 Thread Stephan Witt


Am 13.03.2014 um 10:41 schrieb Vincent van Ravesteijn v...@lyx.org:

 Is it correct that the MacOS problems are now all solved except for some 
 cosmetic issues ?
 
 I don't know. Currently it's not clear. The package I've build is usable on 
 Benjamin's 10.9
 and it's not usable on the machine of the OP of ticket 8925. That's very 
 strange.
 
 [...]
 
 We have to provide more than one package for different Mac OS versions.
 The package build on 10.8 doesn't run on 10.5 and I had problems with
 the package build on 10.6 (works on 10.5 too) on higher OS versions.
 
 Stephan
 
 If I understand correctly:
 
 - you are able to produce packages for 10.6, and for 10.8;
 - these two packages work on all versions.

One of those two packages works on the given version, I hope.

 However, it still doesn't work for the OP of #8925. 5 days ago, he
 couldn't find a patched dmg. I don't know what is patched, but are
 you still sure the new package doesn't work on his machine ?

The OP had python3 from macports installed.

The path_prefix of LyX on Mac sets /opt/local/bin before /usr/bin and
therefor LyX was using python3 instead of the python2 in /usr/bin.
LyX wasn't able to configure itself and no window were opened.

This opens some questions:
* Why is /opt/local/bin in path_prefix?
* Why is there no feedback given for automatic initial configure run?
* Why is there no feedback given for a failure with this configure run?
* What should be done to prevent this scenario?

I'd cleanup the path_prefix in development/MacOSX/lyxrc.dist.in and
let the OP try the resulting package.

Stephan

Re: 2.1 release status

2014-03-13 Thread Benjamin Piwowarski



  However, it still doesn't work for the OP of #8925. 5 days ago, he
  couldn't find a patched dmg. I don't know what is patched, but are
  you still sure the new package doesn't work on his machine ?

 The OP had python3 from macports installed.

 The path_prefix of LyX on Mac sets /opt/local/bin before /usr/bin and
 therefor LyX was using python3 instead of the python2 in /usr/bin.
 LyX wasn't able to configure itself and no window were opened.

 This opens some questions:
 * Why is /opt/local/bin in path_prefix?
 * Why is there no feedback given for automatic initial configure run?
 * Why is there no feedback given for a failure with this configure run?
 * What should be done to prevent this scenario?

 I'd cleanup the path_prefix in development/MacOSX/lyxrc.dist.in and
 let the OP try the resulting package.

I have another question (this was what I was trying to fix also):
- why the python2() code in os.cpp  (line 41) does not prevent the wrong
python to be selected. In particular, why is the test out.first  0 and
not out.first != 0 ?

This would have prevented the python3 version from being selected.

Benjamin

Re: 2.1 release status

Benjamin Piwowarski wrote:

 I have another question (this was what I was trying to fix also):
 - why the python2() code in os.cpp  (line 41) does not prevent the wrong
 python to be selected.

I think this is the most important question. After all, we do not have 
control over PATH, and in many cases we cannot set a sensible path prefix 
(e.g. on many linux systems).

 In particular, why is the test out.first  0 and
 not out.first != 0 ?

Because out.first is -1 on error. It is either a hard coded -1 in LyX, or 
the return value of pclose(), _pclose() or fclose(). Which one is used on OS 
X? What does it retun on error?

 This would have prevented the python3 version from being selected.

Why? This means that prefixIs(out.second, Python 2) returns true for 
python 3. How can that happen?


Georg

Re: 2.1 release status

aparsloe wrote:

 For instance, under the format LyX in the Viewer slots I have put Custom
 and notepad++ (a Windows text editor). Clicking on the View other
 formats  View LyX button displays the LyX file in its native format in
 the text editor but with the command window also showing. However, if I
 make notepad++ the default .lyx file viewer in Windows and change the
 Viewer slots to Custom and auto, save and now click  View other formats
   View LyX, notepad++ is launched, displaying the LyX file in its
 native format but with no command window showing.  (Incidentally this
 makes a good alternative to the Source pane for viewing LyX files in
 native format.)

This is interesting, but I did not quite understand what exactly you 
configured. Could you please send us the lines of your preferences file 
related to both options (the working one and the not working one)? This 
would make debugging easier, and maybe there is an easy solution.


Georg

Re: 2.1 release status


Georg Baum schreef op 13-3-2014 22:20:

aparsloe wrote:


For instance, under the format LyX in the Viewer slots I have put Custom
and notepad++ (a Windows text editor). Clicking on the View other
formats  View LyX button displays the LyX file in its native format in
the text editor but with the command window also showing. However, if I
make notepad++ the default .lyx file viewer in Windows and change the
Viewer slots to Custom and auto, save and now click  View other formats
   View LyX, notepad++ is launched, displaying the LyX file in its
native format but with no command window showing.  (Incidentally this
makes a good alternative to the Source pane for viewing LyX files in
native format.)

This is interesting, but I did not quite understand what exactly you
configured. Could you please send us the lines of your preferences file
related to both options (the working one and the not working one)? This
would make debugging easier, and maybe there is an easy solution.


Georg


I did some debugging. The problem lies in the use of 
QProcess::startDetached. If you call this function with a the cmd 
prefix, you will inevitably get a command window.


Omitting the cmd could be a solution. Does it have any use to add the 
latexEnvCmdPrefix to a viewer command ?


Other solutions using QProcess::start did not work as I never seem to 
get a finished() signal to be able to delete the process. This deletion 
of the Qprocess object was the reason to change this in commit 52258212.


Vincent

Re: 2.1 release status

Vincent van Ravesteijn wrote:

 I did some debugging. The problem lies in the use of
 QProcess::startDetached. If you call this function with a the cmd
 prefix, you will inevitably get a command window.

So in some sense it does what it is told to do;-)

 Omitting the cmd could be a solution. Does it have any use to add the
 latexEnvCmdPrefix to a viewer command ?

This looks rather wrong to me. This should only be added when running a TeX 
related converter, e.g. LaTeX, BibTeX etc.

There are more dangerous code parts, e.g. 

subst(command, cmd /d /c , );

looks quite fragile.

 Other solutions using QProcess::start did not work as I never seem to
 get a finished() signal to be able to delete the process. This deletion
 of the Qprocess object was the reason to change this in commit 52258212.

Yes, there are many ways to do subtle errors when creating child processes 
(a long time ago I wrote cross-platform wrapper for that which took quite 
long to get it right), so we should not change this right now. However, if 
there is an easy way to use latexEnvCmdPrefix only for converters it would 
probably be good to do that.


Georg

Re: 2.1 release status

2014-03-13 Thread Scott Kostyshak

On Thu, Mar 13, 2014 at 5:29 PM, Vincent van Ravesteijn v...@lyx.org wrote:

 I did some debugging. The problem lies in the use of
 QProcess::startDetached. If you call this function with a the cmd prefix,
 you will inevitably get a command window.

 Omitting the cmd could be a solution. Does it have any use to add the
 latexEnvCmdPrefix to a viewer command ?

 Other solutions using QProcess::start did not work as I never seem to get a
 finished() signal to be able to delete the process. This deletion of the
 Qprocess object was the reason to change this in commit 52258212.

I posted this information on #9035 and CC'ed Guy who wrote that patch.
This way he can test that a fix to #9035 does not bring back the bug
that he fixed.

Scott

Re: 2.1 release status

2014-03-13 Thread aparsloe



On 14/03/2014 10:20 a.m., Georg Baum wrote:

aparsloe wrote:


For instance, under the format LyX in the Viewer slots I have put Custom
and notepad++ (a Windows text editor). Clicking on the View other
formats  View LyX button displays the LyX file in its native format in
the text editor but with the command window also showing. However, if I
make notepad++ the default .lyx file viewer in Windows and change the
Viewer slots to Custom and auto, save and now click  View other formats
   View LyX, notepad++ is launched, displaying the LyX file in its
native format but with no command window showing.  (Incidentally this
makes a good alternative to the Source pane for viewing LyX files in
native format.)

This is interesting, but I did not quite understand what exactly you
configured. Could you please send us the lines of your preferences file
related to both options (the working one and the not working one)? This
would make debugging easier, and maybe there is an easy solution.


Georg
I see that Vincent has made progress with this so this is outdated, but 
I did a multitude of trials. The persistence of the console window is 
not a pdf problem. Summarizing:


when LyX uses a Windows default viewer to display a file, no console 
window shows (Tools  Preferences  File Formats with Custom auto 
entered in the Viewer slots);


only when an explicit viewer is entered in the Viewer slots is the 
console window displayed;


generally it stays open, but for some programs (e.g. notepad++, a text 
editor, and Texworks pdf viewer which comes with MiKTeX) it displays 
briefly then closes.


Andrew

***
File Formats  Format: Rich Text Format

Windows default .rtf viewer: Abiword

C1.
File Formats  Viewer: Custom auto
Preferences: not listed in prefs
Result: doc displays in Abiword; No console window

C2.
File Formats  Viewer: Custom Abiword (must be added to the PATH)
Preferences: \format rtf rtf Rich Text Format  Abiword  
document,vector,menu=export application/rtf

Result: doc displays in Abiword; console window stays open
***
Windows default .rtf viewer: Wordpad

D1.
File Formats  Viewer: Custom auto
Preferences: not listed
Result: doc displays in Wordpad; NO console window

D2.
File Formats  Viewer: Custom Wordpad (must be added to the PATH to 
function)
\format rtf rtf Rich Text Format  Wordpad  
document,vector,menu=export application/rtf

Result: doc displays in Wordpad; console window stays open
*
File Formats  Format: PDF (pdflatex)

Windows default .pdf viewer: Adobe Reader

E1.
File Formats  Viewer: Custom auto
Preferences: \format pdf2 pdf PDF (pdflatex) F auto  
document,vector,menu=export application/pdf
Result: pdf displayed in Adobe Reader; NO console window shows; Update 
button generates I can't write on file `newfile1.pdf'. error


E2.
File Formats  Viewer: pdfview
Preferences: not listed
Result: pdf displayed in Adobe; console window stays open; Update button 
works


E3.
File Formats  Viewer: Custom texworks
Preferences: \format pdf2 pdf PDF (pdflatex) F texworks  
document,vector,menu=export application/pdf
Result: pdf displays in texworks; console window stays open; Update 
button works

***
Windows default .pdf viewer: texworks

F1.
File Formats  Viewer: Custom auto
Preferences: \format pdf2 pdf PDF (pdflatex) F auto  
document,vector,menu=export application/pdf
Result: pdf displayed in texworks; NO console window shows; Update 
button works


F2.
File Formats  Viewer: pdfview
Preferences: not listed
Result: pdf displayed in texworks; console window opens briefly then 
closes; Update button works


F3.
File Formats  Viewer: Custom texworks
Preferences: \format pdf2 pdf PDF (pdflatex) F texworks  
document,vector,menu=export application/pdf
Result: pdf displayed in texworks; console window opens briefly then 
closes; Update button works

Re: 2.1 release status

>
>> Besides this I have 2 further issues open:
>> - pdfcrop, that we use for cropped PDF output does not work on Windows
>> 64bit (I sent a fix to the maintainer)
>

Using pdfcrop is a new feature and this will not be blocking the release.

>
> This is not a LyX bug, so we should not wait for it. If it's fixed, we can
> of course update the installer.

... which is also true.

>
>
>> - the last few Imagemagick have a bug in the handling of PDF files and I
>> don't want to release an older IM version because of security bugs they
>> fixed (I already contacted the IM developers).
>

What is the bug ?

Vincent

Re: 2.1 release status

On Thu, Mar 13, 2014 at 1:01 AM, Uwe Stöhr  wrote:
> Am 12.03.2014 22:01, schrieb Georg Baum:
>
>> Uwe Stöhr wrote:
>
>
>> I asked already for a list of features with missing documentation, but got
>> no reply, so here is the question again: Which features are not yet
>> documented?
>
>
> the red ones in
> http://wiki.lyx.org/LyX/NewInLyX21
>
>
>>> - Windows-specific: when you view a PDF a console window pops up and does
>>> not disappear. This a super annoying regression to LyX 2.0
>>
>>
>> It can't be super annoying. This is known for several months, and there is
>> no bug entry targeted to 2.1.0 (if my search was correct there is no bug
>> entry at all about this problem).
>
>
> The bug is only in LyX 2.1git and yes, it is super annoying.
> I created now a bug:
> http://www.lyx.org/trac/ticket/9035
>
>

I agree it is super annoying, but at the same time I agree with Georg:
the issue didn't really make it to lyx-devel or trac, so people are
not annoyed enough ;).

Vincent

Re: 2.1 release status

On Mon, Mar 10, 2014 at 11:10 PM, Uwe Stöhr  wrote:
> Am 10.03.2014 21:47, schrieb Vincent van Ravesteijn:
>
>
>> I'm now confused on the status on Windows. For me it looks rather ok.
>
>
> I just finished the Win installer for LyX 2.1. But LyX itself cannot be
> released as it is because:
>
> - the documentation is not yet fully updated and I recently found bugs for
> every new feature I
> described in the docs.

... which means that in the ideal future, if you want a new feature
accepted into LyX, you should provide documentation about it and have
it well tested

>
> - Windows-specific: when you view a PDF a console window pops up and does
> not disappear. This a super annoying regression to LyX 2.0
>
> - I need a test release for the win installer. This can be a RC1 release but
> I need then some weeks afterwards to get enough feedback.

We have two beta releases released with a windows installer. What
changed in the installer that you need a new RC release and you need a
few weeks to get feedback ?


>
> - we need here some more images to advertise our new release! ;-):
> http://wiki.lyx.org/LyX/NewInLyX21
> I mean only 2 images and a desert of letters is not very pleasant. Compare
> this to
> http://wiki.lyx.org/LyX/NewInLyX20
>
> @ everybody: Can you please review
> http://wiki.lyx.org/LyX/NewInLyX21
> if all new features are listed so that I know what to document.

These are not blocking issues, but thanks for reminding people.

Vincent

Re: 2.1 release status

>> Is it correct that the MacOS problems are now all solved except for some 
>> cosmetic issues ?
>
> I don't know. Currently it's not clear. The package I've build is usable on 
> Benjamin's 10.9
> and it's not usable on the machine of the OP of ticket 8925. That's very 
> strange.

[...]

> We have to provide more than one package for different Mac OS versions.
> The package build on 10.8 doesn't run on 10.5 and I had problems with
> the package build on 10.6 (works on 10.5 too) on higher OS versions.
>
> Stephan

If I understand correctly:

- you are able to produce packages for 10.6, and for 10.8;
- these two packages work on all versions.

However, it still doesn't work for the OP of #8925. 5 days ago, he
couldn't find a "patched" dmg. I don't know what is patched, but are
you still sure the new package doesn't work on his machine ?

Vincent

Re: 2.1 release status

2014-03-13 Thread Stephan Witt


Am 13.03.2014 um 10:41 schrieb Vincent van Ravesteijn :

>>> Is it correct that the MacOS problems are now all solved except for some 
>>> cosmetic issues ?
>> 
>> I don't know. Currently it's not clear. The package I've build is usable on 
>> Benjamin's 10.9
>> and it's not usable on the machine of the OP of ticket 8925. That's very 
>> strange.
> 
> [...]
> 
>> We have to provide more than one package for different Mac OS versions.
>> The package build on 10.8 doesn't run on 10.5 and I had problems with
>> the package build on 10.6 (works on 10.5 too) on higher OS versions.
>> 
>> Stephan
> 
> If I understand correctly:
> 
> - you are able to produce packages for 10.6, and for 10.8;
> - these two packages work on all versions.

One of those two packages works on the given version, I hope.

> However, it still doesn't work for the OP of #8925. 5 days ago, he
> couldn't find a "patched" dmg. I don't know what is patched, but are
> you still sure the new package doesn't work on his machine ?

The OP had python3 from macports installed.

The path_prefix of LyX on Mac sets /opt/local/bin before /usr/bin and
therefor LyX was using python3 instead of the python2 in /usr/bin.
LyX wasn't able to configure itself and no window were opened.

This opens some questions:
* Why is /opt/local/bin in path_prefix?
* Why is there no feedback given for automatic initial configure run?
* Why is there no feedback given for a failure with this configure run?
* What should be done to prevent this scenario?

I'd cleanup the path_prefix in development/MacOSX/lyxrc.dist.in and
let the OP try the resulting package.

Stephan

Re: 2.1 release status

2014-03-13 Thread Benjamin Piwowarski

>
>
> > However, it still doesn't work for the OP of #8925. 5 days ago, he
> > couldn't find a "patched" dmg. I don't know what is patched, but are
> > you still sure the new package doesn't work on his machine ?
>
> The OP had python3 from macports installed.
>
> The path_prefix of LyX on Mac sets /opt/local/bin before /usr/bin and
> therefor LyX was using python3 instead of the python2 in /usr/bin.
> LyX wasn't able to configure itself and no window were opened.
>
> This opens some questions:
> * Why is /opt/local/bin in path_prefix?
> * Why is there no feedback given for automatic initial configure run?
> * Why is there no feedback given for a failure with this configure run?
> * What should be done to prevent this scenario?
>
> I'd cleanup the path_prefix in development/MacOSX/lyxrc.dist.in and
> let the OP try the resulting package.
>
I have another question (this was what I was trying to fix also):
- why the python2() code in os.cpp  (line 41) does not prevent the wrong
python to be selected. In particular, why is the test out.first < 0 and
not out.first != 0 ?

This would have prevented the python3 version from being selected.

Benjamin

Re: 2.1 release status

Benjamin Piwowarski wrote:

> I have another question (this was what I was trying to fix also):
> - why the python2() code in os.cpp  (line 41) does not prevent the wrong
> python to be selected.

I think this is the most important question. After all, we do not have 
control over PATH, and in many cases we cannot set a sensible path prefix 
(e.g. on many linux systems).

> In particular, why is the test out.first < 0 and
> not out.first != 0 ?

Because out.first is -1 on error. It is either a hard coded -1 in LyX, or 
the return value of pclose(), _pclose() or fclose(). Which one is used on OS 
X? What does it retun on error?

> This would have prevented the python3 version from being selected.

Why? This means that prefixIs(out.second, "Python 2") returns true for 
python 3. How can that happen?

Georg

Re: 2.1 release status

aparsloe wrote:

> For instance, under the format LyX in the Viewer slots I have put Custom
> and notepad++ (a Windows text editor). Clicking on the View other
> formats > View LyX button displays the LyX file in its native format in
> the text editor but with the command window also showing. However, if I
> make notepad++ the default .lyx file viewer in Windows and change the
> Viewer slots to Custom and auto, save and now click  View other formats
>  > View LyX, notepad++ is launched, displaying the LyX file in its
> native format but with no command window showing.  (Incidentally this
> makes a good alternative to the Source pane for viewing LyX files in
> native format.)

This is interesting, but I did not quite understand what exactly you 
configured. Could you please send us the lines of your preferences file 
related to both options (the working one and the not working one)? This 
would make debugging easier, and maybe there is an easy solution.


Georg

Re: 2.1 release status


Georg Baum schreef op 13-3-2014 22:20:

aparsloe wrote:


For instance, under the format LyX in the Viewer slots I have put Custom
and notepad++ (a Windows text editor). Clicking on the View other
formats > View LyX button displays the LyX file in its native format in
the text editor but with the command window also showing. However, if I
make notepad++ the default .lyx file viewer in Windows and change the
Viewer slots to Custom and auto, save and now click  View other formats
  > View LyX, notepad++ is launched, displaying the LyX file in its
native format but with no command window showing.  (Incidentally this
makes a good alternative to the Source pane for viewing LyX files in
native format.)

This is interesting, but I did not quite understand what exactly you
configured. Could you please send us the lines of your preferences file
related to both options (the working one and the not working one)? This
would make debugging easier, and maybe there is an easy solution.


Georg


I did some debugging. The problem lies in the use of 
QProcess::startDetached. If you call this function with a the "cmd" 
prefix, you will inevitably get a command window.


Omitting the "cmd" could be a solution. Does it have any use to add the 
latexEnvCmdPrefix to a viewer command ?


Other solutions using QProcess::start did not work as I never seem to 
get a finished() signal to be able to delete the process. This deletion 
of the Qprocess object was the reason to change this in commit 52258212.


Vincent

Re: 2.1 release status

Vincent van Ravesteijn wrote:

> I did some debugging. The problem lies in the use of
> QProcess::startDetached. If you call this function with a the "cmd"
> prefix, you will inevitably get a command window.

So in some sense it does what it is told to do;-)

> Omitting the "cmd" could be a solution. Does it have any use to add the
> latexEnvCmdPrefix to a viewer command ?

This looks rather wrong to me. This should only be added when running a TeX 
related converter, e.g. LaTeX, BibTeX etc.

There are more dangerous code parts, e.g. 

subst(command, "cmd /d /c ", "");

looks quite fragile.

> Other solutions using QProcess::start did not work as I never seem to
> get a finished() signal to be able to delete the process. This deletion
> of the Qprocess object was the reason to change this in commit 52258212.

Yes, there are many ways to do subtle errors when creating child processes 
(a long time ago I wrote cross-platform wrapper for that which took quite 
long to get it right), so we should not change this right now. However, if 
there is an easy way to use latexEnvCmdPrefix only for converters it would 
probably be good to do that.

Georg

Re: 2.1 release status

2014-03-13 Thread Scott Kostyshak

On Thu, Mar 13, 2014 at 5:29 PM, Vincent van Ravesteijn  wrote:

> I did some debugging. The problem lies in the use of
> QProcess::startDetached. If you call this function with a the "cmd" prefix,
> you will inevitably get a command window.
>
> Omitting the "cmd" could be a solution. Does it have any use to add the
> latexEnvCmdPrefix to a viewer command ?
>
> Other solutions using QProcess::start did not work as I never seem to get a
> finished() signal to be able to delete the process. This deletion of the
> Qprocess object was the reason to change this in commit 52258212.

I posted this information on #9035 and CC'ed Guy who wrote that patch.
This way he can test that a fix to #9035 does not bring back the bug
that he fixed.

Scott

Re: 2.1 release status

2014-03-13 Thread aparsloe



On 14/03/2014 10:20 a.m., Georg Baum wrote:

aparsloe wrote:


For instance, under the format LyX in the Viewer slots I have put Custom
and notepad++ (a Windows text editor). Clicking on the View other
formats > View LyX button displays the LyX file in its native format in
the text editor but with the command window also showing. However, if I
make notepad++ the default .lyx file viewer in Windows and change the
Viewer slots to Custom and auto, save and now click  View other formats
  > View LyX, notepad++ is launched, displaying the LyX file in its
native format but with no command window showing.  (Incidentally this
makes a good alternative to the Source pane for viewing LyX files in
native format.)

This is interesting, but I did not quite understand what exactly you
configured. Could you please send us the lines of your preferences file
related to both options (the working one and the not working one)? This
would make debugging easier, and maybe there is an easy solution.


Georg
I see that Vincent has made progress with this so this is outdated, but 
I did a multitude of trials. The persistence of the console window is 
not a pdf problem. Summarizing:


when LyX uses a Windows default viewer to display a file, no console 
window shows (Tools > Preferences > File Formats with "Custom auto" 
entered in the Viewer slots);


only when an explicit viewer is entered in the Viewer slots is the 
console window displayed;


generally it stays open, but for some programs (e.g. notepad++, a text 
editor, and Texworks pdf viewer which comes with MiKTeX) it displays 
briefly then closes.


Andrew

***
File Formats > Format: Rich Text Format

Windows default .rtf viewer: Abiword

C1.
File Formats > Viewer: Custom auto
Preferences: not listed in prefs
Result: doc displays in Abiword; No console window

C2.
File Formats > Viewer: Custom Abiword (must be added to the PATH)
Preferences: \format "rtf" "rtf" "Rich Text Format" "" "Abiword" "" 
"document,vector,menu=export" "application/rtf"

Result: doc displays in Abiword; console window stays open
***
Windows default .rtf viewer: Wordpad

D1.
File Formats > Viewer: Custom auto
Preferences: not listed
Result: doc displays in Wordpad; NO console window

D2.
File Formats > Viewer: Custom Wordpad (must be added to the PATH to 
function)
\format "rtf" "rtf" "Rich Text Format" "" "Wordpad" "" 
"document,vector,menu=export" "application/rtf"

Result: doc displays in Wordpad; console window stays open
*
File Formats > Format: PDF (pdflatex)

Windows default .pdf viewer: Adobe Reader

E1.
File Formats > Viewer: Custom auto
Preferences: \format "pdf2" "pdf" "PDF (pdflatex)" "F" "auto" "" 
"document,vector,menu=export" "application/pdf"
Result: pdf displayed in Adobe Reader; NO console window shows; Update 
button generates "I can't write on file `newfile1.pdf'." error


E2.
File Formats > Viewer: pdfview
Preferences: not listed
Result: pdf displayed in Adobe; console window stays open; Update button 
works


E3.
File Formats > Viewer: Custom texworks
Preferences: \format "pdf2" "pdf" "PDF (pdflatex)" "F" "texworks" "" 
"document,vector,menu=export" "application/pdf"
Result: pdf displays in texworks; console window stays open; Update 
button works

***
Windows default .pdf viewer: texworks

F1.
File Formats > Viewer: Custom auto
Preferences: \format "pdf2" "pdf" "PDF (pdflatex)" "F" "auto" "" 
"document,vector,menu=export" "application/pdf"
Result: pdf displayed in texworks; NO console window shows; Update 
button works


F2.
File Formats > Viewer: pdfview
Preferences: not listed
Result: pdf displayed in texworks; console window opens briefly then 
closes; Update button works


F3.
File Formats > Viewer: Custom texworks
Preferences: \format "pdf2" "pdf" "PDF (pdflatex)" "F" "texworks" "" 
"document,vector,menu=export" "application/pdf"
Result: pdf displayed in texworks; console window opens briefly then 
closes; Update button works

Re: 2.1 release status

2014-03-12 Thread Georg Baum

Uwe Stöhr wrote:

 I just finished the Win installer for LyX 2.1. But LyX itself cannot be
 released as it is because:
 
 - the documentation is not yet fully updated and I recently found bugs for
 every new feature I described in the docs.

I you aim for a bug free release then it will never happen. We need to 
prioritize the bugs, and if you do not find bugs for some minor new features 
because you don't document them then this is not nice, but better than a 
2.1.0 release in 2015.

I asked already for a list of features with missing documentation, but got 
no reply, so here is the question again: Which features are not yet 
documented?

 - Windows-specific: when you view a PDF a console window pops up and does
 not disappear. This a super annoying regression to LyX 2.0

It can't be super annoying. This is known for several months, and there is 
no bug entry targeted to 2.1.0 (if my search was correct there is no bug 
entry at all about this problem).

 - I need a test release for the win installer. This can be a RC1 release
 but I need then some weeks afterwards to get enough feedback.

This is fine, I guess it applies not only to the installer, but also the 
sources itself.

 - we need here some more images to advertise our new release! ;-):
 http://wiki.lyx.org/LyX/NewInLyX21

Would be nice to have but not essential (and could easily be enhanced 
between the RC and the final release).


Georg

Re: 2.1 release status

2014-03-12 Thread aparsloe



On 13/03/2014 10:01 a.m., Georg Baum wrote:

Uwe Stöhr wrote:
- Windows-specific: when you view a PDF a console window pops up and does
not disappear. This a super annoying regression to LyX 2.0
It can't be super annoying. This is known for several months, and there is
no bug entry targeted to 2.1.0 (if my search was correct there is no bug
entry at all about this problem).

I've lived with this for months now (on Windows 7). It is an irritation 
but only a minor one. It doesn't affect only the launch of a pdf viewer 
but also other formats where, in the File Formats window, in the Viewer 
slots, an explicit program is named (like pdfview). If instead Custom 
and auto are placed in these slots (so that as I understand it Windows 
uses its default viewers) the command window is not present.


For instance, under the format LyX in the Viewer slots I have put Custom 
and notepad++ (a Windows text editor). Clicking on the View other 
formats  View LyX button displays the LyX file in its native format in 
the text editor but with the command window also showing. However, if I 
make notepad++ the default .lyx file viewer in Windows and change the 
Viewer slots to Custom and auto, save and now click  View other formats 
 View LyX, notepad++ is launched, displaying the LyX file in its 
native format but with no command window showing.  (Incidentally this 
makes a good alternative to the Source pane for viewing LyX files in 
native format.)


Andrew

Re: 2.1 release status

2014-03-12 Thread Uwe Stöhr

Am 12.03.2014 22:01, schrieb Georg Baum:

Uwe Stöhr wrote:

I asked already for a list of features with missing documentation, but got
no reply, so here is the question again: Which features are not yet
documented?

the red ones in
http://wiki.lyx.org/LyX/NewInLyX21

- Windows-specific: when you view a PDF a console window pops up and does
not disappear. This a super annoying regression to LyX 2.0

It can't be super annoying. This is known for several months, and there is
no bug entry targeted to 2.1.0 (if my search was correct there is no bug
entry at all about this problem).

The bug is only in LyX 2.1git and yes, it is super annoying.
I created now a bug:
http://www.lyx.org/trac/ticket/9035

- I need a test release for the win installer. This can be a RC1 release
but I need then some weeks afterwards to get enough feedback.

This is fine, I guess it applies not only to the installer, but also the
sources itself.

- we need here some more images to advertise our new release! ;-):
http://wiki.lyx.org/LyX/NewInLyX21

Would be nice to have but not essential (and could easily be enhanced
between the RC and the final release).

Fine with me, but why not now?

Besides this I have 2 further issues open:
- pdfcrop, that we use for cropped PDF output does not work on Windows 64bit (I sent a fix to the
maintainer)
- the last few Imagemagick have a bug in the handling of PDF files and I don't want to release an
older IM version because of security bugs they fixed (I already contacted the IM developers).

regards Uwe

Re: 2.1 release status

2014-03-12 Thread Richard Heck


On 03/12/2014 08:01 PM, Uwe Stöhr wrote:

Am 12.03.2014 22:01, schrieb Georg Baum:

Uwe Stöhr wrote:


I asked already for a list of features with missing documentation, 
but got

no reply, so here is the question again: Which features are not yet
documented?


the red ones in
http://wiki.lyx.org/LyX/NewInLyX21


We are a month away, I think, so there is plenty of time. If you need 
help with

some of this, let others know.


Besides this I have 2 further issues open:
- pdfcrop, that we use for cropped PDF output does not work on Windows 
64bit (I sent a fix to the maintainer)


This is not a LyX bug, so we should not wait for it. If it's fixed, we 
can of course update the installer.


- the last few Imagemagick have a bug in the handling of PDF files and 
I don't want to release an older IM version because of security bugs 
they fixed (I already contacted the IM developers).


Same.

Richard

Re: 2.1 release status

2014-03-12 Thread Georg Baum

Uwe Stöhr wrote:

> I just finished the Win installer for LyX 2.1. But LyX itself cannot be
> released as it is because:
> 
> - the documentation is not yet fully updated and I recently found bugs for
> every new feature I described in the docs.

I you aim for a bug free release then it will never happen. We need to 
prioritize the bugs, and if you do not find bugs for some minor new features 
because you don't document them then this is not nice, but better than a 
2.1.0 release in 2015.

I asked already for a list of features with missing documentation, but got 
no reply, so here is the question again: Which features are not yet 
documented?

> - Windows-specific: when you view a PDF a console window pops up and does
> not disappear. This a super annoying regression to LyX 2.0

It can't be super annoying. This is known for several months, and there is 
no bug entry targeted to 2.1.0 (if my search was correct there is no bug 
entry at all about this problem).

> - I need a test release for the win installer. This can be a RC1 release
> but I need then some weeks afterwards to get enough feedback.

This is fine, I guess it applies not only to the installer, but also the 
sources itself.

> - we need here some more images to advertise our new release! ;-):
> http://wiki.lyx.org/LyX/NewInLyX21

Would be nice to have but not essential (and could easily be enhanced 
between the RC and the final release).

Georg

Re: 2.1 release status

2014-03-12 Thread aparsloe



On 13/03/2014 10:01 a.m., Georg Baum wrote:

Uwe Stöhr wrote:
- Windows-specific: when you view a PDF a console window pops up and does
not disappear. This a super annoying regression to LyX 2.0
It can't be super annoying. This is known for several months, and there is
no bug entry targeted to 2.1.0 (if my search was correct there is no bug
entry at all about this problem).

I've lived with this for months now (on Windows 7). It is an irritation 
but only a minor one. It doesn't affect only the launch of a pdf viewer 
but also other formats where, in the File Formats window, in the Viewer 
slots, an explicit program is named (like pdfview). If instead Custom 
and auto are placed in these slots (so that as I understand it Windows 
uses its default viewers) the command window is not present.


For instance, under the format LyX in the Viewer slots I have put Custom 
and notepad++ (a Windows text editor). Clicking on the View other 
formats > View LyX button displays the LyX file in its native format in 
the text editor but with the command window also showing. However, if I 
make notepad++ the default .lyx file viewer in Windows and change the 
Viewer slots to Custom and auto, save and now click  View other formats 
> View LyX, notepad++ is launched, displaying the LyX file in its 
native format but with no command window showing.  (Incidentally this 
makes a good alternative to the Source pane for viewing LyX files in 
native format.)


Andrew

Re: 2.1 release status

2014-03-12 Thread Uwe Stöhr

Am 12.03.2014 22:01, schrieb Georg Baum:

Uwe Stöhr wrote:

I asked already for a list of features with missing documentation, but got
no reply, so here is the question again: Which features are not yet
documented?

the red ones in
http://wiki.lyx.org/LyX/NewInLyX21

- Windows-specific: when you view a PDF a console window pops up and does
not disappear. This a super annoying regression to LyX 2.0

It can't be super annoying. This is known for several months, and there is
no bug entry targeted to 2.1.0 (if my search was correct there is no bug
entry at all about this problem).

The bug is only in LyX 2.1git and yes, it is super annoying.
I created now a bug:
http://www.lyx.org/trac/ticket/9035

- I need a test release for the win installer. This can be a RC1 release
but I need then some weeks afterwards to get enough feedback.

This is fine, I guess it applies not only to the installer, but also the
sources itself.

- we need here some more images to advertise our new release! ;-):
http://wiki.lyx.org/LyX/NewInLyX21

Would be nice to have but not essential (and could easily be enhanced
between the RC and the final release).

Fine with me, but why not now?

regards Uwe

Re: 2.1 release status

2014-03-12 Thread Richard Heck


On 03/12/2014 08:01 PM, Uwe Stöhr wrote:

Am 12.03.2014 22:01, schrieb Georg Baum:

Uwe Stöhr wrote:


I asked already for a list of features with missing documentation, 
but got

no reply, so here is the question again: Which features are not yet
documented?


the red ones in
http://wiki.lyx.org/LyX/NewInLyX21


We are a month away, I think, so there is plenty of time. If you need 
help with

some of this, let others know.


Besides this I have 2 further issues open:
- pdfcrop, that we use for cropped PDF output does not work on Windows 
64bit (I sent a fix to the maintainer)


This is not a LyX bug, so we should not wait for it. If it's fixed, we 
can of course update the installer.


- the last few Imagemagick have a bug in the handling of PDF files and 
I don't want to release an older IM version because of security bugs 
they fixed (I already contacted the IM developers).


Same.

Richard

Re: 2.1 release status

2014-03-11 Thread Stephan Witt

Am 10.03.2014 um 21:47 schrieb Vincent van Ravesteijn v...@lyx.org:

 Georg Baum schreef op 3-3-2014 22:28:
 Jürgen Spitzmüller wrote:
 
 The status now is that we can release 2.1 as soon as the Mac Cocoa
 problems listed in #8959 are resolved:
 
 I think we should aim at a release in March. Do a RC in mid March, and
 then release two weeks later, if no urgent problems are reported.
 Thanks for the update, Jürgen, I agree. Uwe, are you finished with the
 documentation until then? IMHO it would be OK if the major changes are
 done. Some finetuning, or some minor new feature documentation could follow
 in a minor release.
 
 I agree with you. IMO, the critical bugs left in the bug tracker are 
 difficult to fix, and have been around for a long time.
 
 Is it correct that the MacOS problems are now all solved except for some 
 cosmetic issues ?

I don't know. Currently it's not clear. The package I've build is usable on 
Benjamin's 10.9
and it's not usable on the machine of the OP of ticket 8925. That's very 
strange.

 Stefan, are you ok with release a version with Qt4 given that LyX 2.2. will 
 be here much faster than LyX 2.1 came after LyX 2.0 ?

Yes, we should do a 2.1 release with 4.8.x. (4.8.4 or 4.8.5)

We have to provide more than one package for different Mac OS versions.
The package build on 10.8 doesn't run on 10.5 and I had problems with
the package build on 10.6 (works on 10.5 too) on higher OS versions.

Stephan

 I'm now confused on the status on Windows. For me it looks rather ok.
 
 Things to be fixed IMO:
 - the master-child bug caused by used the master's BufferParams,
 
 Last thing, do you still want me to do the final release ? I really want to 
 get it out as soon as possible.
 
 Vincent

Re: 2.1 release status

2014-03-11 Thread Stephan Witt

Am 10.03.2014 um 21:47 schrieb Vincent van Ravesteijn :

> Georg Baum schreef op 3-3-2014 22:28:
>> Jürgen Spitzmüller wrote:
>> 
>>> The status now is that we can release 2.1 as soon as the Mac Cocoa
>>> problems listed in #8959 are resolved:
>>> 
>>> I think we should aim at a release in March. Do a RC in mid March, and
>>> then release two weeks later, if no urgent problems are reported.
>> Thanks for the update, Jürgen, I agree. Uwe, are you finished with the
>> documentation until then? IMHO it would be OK if the major changes are
>> done. Some finetuning, or some minor new feature documentation could follow
>> in a minor release.
> 
> I agree with you. IMO, the critical bugs left in the bug tracker are 
> difficult to fix, and have been around for a long time.
> 
> Is it correct that the MacOS problems are now all solved except for some 
> cosmetic issues ?

I don't know. Currently it's not clear. The package I've build is usable on 
Benjamin's 10.9
and it's not usable on the machine of the OP of ticket 8925. That's very 
strange.

> Stefan, are you ok with release a version with Qt4 given that LyX 2.2. will 
> be here much faster than LyX 2.1 came after LyX 2.0 ?

Yes, we should do a 2.1 release with 4.8.x. (4.8.4 or 4.8.5)

We have to provide more than one package for different Mac OS versions.
The package build on 10.8 doesn't run on 10.5 and I had problems with
the package build on 10.6 (works on 10.5 too) on higher OS versions.

Stephan

> I'm now confused on the status on Windows. For me it looks rather ok.
> 
> Things to be fixed IMO:
> - the master-child bug caused by used the master's BufferParams,
> 
> Last thing, do you still want me to do the final release ? I really want to 
> get it out as soon as possible.
> 
> Vincent
>

Re: 2.1 release status


Uwe Stöhr schreef op 4-3-2014 0:20:

Am 03.03.2014 22:28, schrieb Georg Baum:


Thanks for the update, Jürgen, I agree. Uwe, are you finished with the
documentation until then?


No. There is still too much to do and the translators also need time. 
I will see what I can do this week.
Is it really that pressing? I mean I will for sure find further issues 
while updating the docs and I think we should take the time to fix as 
many bugs as possible.


LyX 2.1 still crashes frequently (I have no recipe to reproduce these 
crashes yet) and there are some Windows-specific issues Vincent and I 
could not solve (e.g. that LyX's console is now always shown when 
viewing a PDF. But the most important issue is that LyX does still 
require Python 2.7. This limitation is kind of a nightmare for me 
because more and more PCs come with a pre-installed Python 3.x which 
will of course interfere with Python 2.7.x so that LyX 2.1beta2 was 
not configurable for some users. Or do I missed something and LyX is 
now Python 3.x-ready? If so I will stress-test that.


I don't understand. We package Python with LyX and we install Python in 
a subdir of the C:\Program Files (x86)\LyX. Then we add this directory 
to the path ourselves. How come that we suddenly use Python3.0 ?


Vincent

Re: 2.1 release status


Georg Baum schreef op 21-2-2014 21:55:

Hi,

fortunately there was a lot of activity in trac during the last days/weeks,
so although it might look on the list that the upcoming release is not being
worked on this is not true. However, I believe it would be good to get a
clear picture of what is missing here on the list, therefore I'd like to
collect information about the show stoppers. What needs to be done?

Georg


Thanks Georg for doing this work which I should have done.

Vincent

Re: 2.1 release status


Georg Baum schreef op 3-3-2014 22:28:

Jürgen Spitzmüller wrote:


The status now is that we can release 2.1 as soon as the Mac Cocoa
problems listed in #8959 are resolved:

I think we should aim at a release in March. Do a RC in mid March, and
then release two weeks later, if no urgent problems are reported.

Thanks for the update, Jürgen, I agree. Uwe, are you finished with the
documentation until then? IMHO it would be OK if the major changes are
done. Some finetuning, or some minor new feature documentation could follow
in a minor release.


I agree with you. IMO, the critical bugs left in the bug tracker are 
difficult to fix, and have been around for a long time.


Is it correct that the MacOS problems are now all solved except for some 
cosmetic issues ? Stefan, are you ok with release a version with Qt4 
given that LyX 2.2. will be here much faster than LyX 2.1 came after LyX 
2.0 ?


I'm now confused on the status on Windows. For me it looks rather ok.

Things to be fixed IMO:
- the master-child bug caused by used the master's BufferParams,

Last thing, do you still want me to do the final release ? I really want 
to get it out as soon as possible.


Vincent

Re: 2.1 release status

2014-03-10 Thread Richard Heck


On 03/10/2014 04:47 PM, Vincent van Ravesteijn wrote:

Georg Baum schreef op 3-3-2014 22:28:

Jürgen Spitzmüller wrote:


The status now is that we can release 2.1 as soon as the Mac Cocoa
problems listed in #8959 are resolved:

I think we should aim at a release in March. Do a RC in mid March, and
then release two weeks later, if no urgent problems are reported.

Thanks for the update, Jürgen, I agree. Uwe, are you finished with the
documentation until then? IMHO it would be OK if the major changes are
done. Some finetuning, or some minor new feature documentation could 
follow

in a minor release.


I agree with you. IMO, the critical bugs left in the bug tracker are 
difficult to fix, and have been around for a long time.


Is it correct that the MacOS problems are now all solved except for 
some cosmetic issues ? Stefan, are you ok with release a version with 
Qt4 given that LyX 2.2. will be here much faster than LyX 2.1 came 
after LyX 2.0 ?


I'm now confused on the status on Windows. For me it looks rather ok.

Things to be fixed IMO:
- the master-child bug caused by used the master's BufferParams,

Last thing, do you still want me to do the final release ? I really 
want to get it out as soon as possible.


I think we should fix this and then release RC1. We should probably 
contact translators ASAP and give them a deadline. I gather there is 
more to do with that than with a branch release (something with layout 
translations), so perhaps a month?


Richard

Re: 2.1 release status

Vincent van Ravesteijn wrote:

 I don't understand. We package Python with LyX and we install Python in
 a subdir of the C:\Program Files (x86)\LyX. Then we add this directory
 to the path ourselves. How come that we suddenly use Python3.0 ?

Probably because the windows system path takes precendence over the windows 
user path (and the LyX path prefix which is prepended to the user path 
AFAIK). For details see the other thread Python problems on windows - some 
debugging hints, especially my messages from today 21:36 CET and from 
yesterday 20:47 CET. IMHO it would be really good if somebody who can build 
LyX on windows could investigate whether this is correct.


Georg

Re: 2.1 release status

Vincent van Ravesteijn wrote:

 I agree with you. IMO, the critical bugs left in the bug tracker are
 difficult to fix, and have been around for a long time.
 
 Is it correct that the MacOS problems are now all solved except for some
 cosmetic issues ? Stefan, are you ok with release a version with Qt4
 given that LyX 2.2. will be here much faster than LyX 2.1 came after LyX
 2.0 ?
 
 I'm now confused on the status on Windows. For me it looks rather ok.

Unless we get a call stack or other usable information we cannot do anything 
IMHO.

 Things to be fixed IMO:
 - the master-child bug caused by used the master's BufferParams,

I agree with everything.

 Last thing, do you still want me to do the final release ? I really want
 to get it out as soon as possible.

Yes please, if you really have the time. If you don't have the time, or run 
out of time after starting the whole process, please tell as soon as 
possible, we'll find a different solution then.


Georg

Re: 2.1 release status


Am 10.03.2014 20:52, schrieb Vincent van Ravesteijn:


I don't understand. We package Python with LyX and we install Python in a subdir of 
the C:\Program
Files (x86)\LyX. Then we add this directory to the path ourselves. How come 
that we suddenly use
Python3.0 ?


Yes, it seems that the bug reports I got have another origin because the installation of Python is 
the same as in LyX 2.0.x and I did not get any related bug report. (See my discussion with Georg).


regards Uwe

Re: 2.1 release status


Am 10.03.2014 21:47, schrieb Vincent van Ravesteijn:


I'm now confused on the status on Windows. For me it looks rather ok.


I just finished the Win installer for LyX 2.1. But LyX itself cannot be 
released as it is because:

- the documentation is not yet fully updated and I recently found bugs for 
every new feature I
described in the docs.

- Windows-specific: when you view a PDF a console window pops up and does not disappear. This a 
super annoying regression to LyX 2.0


- I need a test release for the win installer. This can be a RC1 release but I need then some weeks 
afterwards to get enough feedback.


- we need here some more images to advertise our new release! ;-):
http://wiki.lyx.org/LyX/NewInLyX21
I mean only 2 images and a desert of letters is not very pleasant. Compare this 
to
http://wiki.lyx.org/LyX/NewInLyX20

@ everybody: Can you please review
http://wiki.lyx.org/LyX/NewInLyX21
if all new features are listed so that I know what to document.

thanks and regards
Uwe

Re: 2.1 release status


Uwe Stöhr schreef op 4-3-2014 0:20:

Am 03.03.2014 22:28, schrieb Georg Baum:


Thanks for the update, Jürgen, I agree. Uwe, are you finished with the
documentation until then?


No. There is still too much to do and the translators also need time. 
I will see what I can do this week.
Is it really that pressing? I mean I will for sure find further issues 
while updating the docs and I think we should take the time to fix as 
many bugs as possible.


LyX 2.1 still crashes frequently (I have no recipe to reproduce these 
crashes yet) and there are some Windows-specific issues Vincent and I 
could not solve (e.g. that LyX's console is now always shown when 
viewing a PDF. But the most important issue is that LyX does still 
require Python 2.7. This limitation is kind of a nightmare for me 
because more and more PCs come with a pre-installed Python 3.x which 
will of course interfere with Python 2.7.x so that LyX 2.1beta2 was 
not configurable for some users. Or do I missed something and LyX is 
now Python 3.x-ready? If so I will stress-test that.


I don't understand. We package Python with LyX and we install Python in 
a subdir of the "C:\Program Files (x86)\LyX". Then we add this directory 
to the path ourselves. How come that we suddenly use Python3.0 ?


Vincent

Re: 2.1 release status


Georg Baum schreef op 21-2-2014 21:55:

Hi,

fortunately there was a lot of activity in trac during the last days/weeks,
so although it might look on the list that the upcoming release is not being
worked on this is not true. However, I believe it would be good to get a
clear picture of what is missing here on the list, therefore I'd like to
collect information about the show stoppers. What needs to be done?

Georg


Thanks Georg for doing this work which I should have done.

Vincent

Re: 2.1 release status


Georg Baum schreef op 3-3-2014 22:28:

Jürgen Spitzmüller wrote:


The status now is that we can release 2.1 as soon as the Mac Cocoa
problems listed in #8959 are resolved:

I think we should aim at a release in March. Do a RC in mid March, and
then release two weeks later, if no urgent problems are reported.

Thanks for the update, Jürgen, I agree. Uwe, are you finished with the
documentation until then? IMHO it would be OK if the major changes are
done. Some finetuning, or some minor new feature documentation could follow
in a minor release.


I agree with you. IMO, the critical bugs left in the bug tracker are 
difficult to fix, and have been around for a long time.


Is it correct that the MacOS problems are now all solved except for some 
cosmetic issues ? Stefan, are you ok with release a version with Qt4 
given that LyX 2.2. will be here much faster than LyX 2.1 came after LyX 
2.0 ?


I'm now confused on the status on Windows. For me it looks rather ok.

Things to be fixed IMO:
- the master-child bug caused by used the master's BufferParams,

Last thing, do you still want me to do the final release ? I really want 
to get it out as soon as possible.


Vincent

Re: 2.1 release status

2014-03-10 Thread Richard Heck


On 03/10/2014 04:47 PM, Vincent van Ravesteijn wrote:

Georg Baum schreef op 3-3-2014 22:28:

Jürgen Spitzmüller wrote:


The status now is that we can release 2.1 as soon as the Mac Cocoa
problems listed in #8959 are resolved:

I think we should aim at a release in March. Do a RC in mid March, and
then release two weeks later, if no urgent problems are reported.

Thanks for the update, Jürgen, I agree. Uwe, are you finished with the
documentation until then? IMHO it would be OK if the major changes are
done. Some finetuning, or some minor new feature documentation could 
follow

in a minor release.


I agree with you. IMO, the critical bugs left in the bug tracker are 
difficult to fix, and have been around for a long time.


Is it correct that the MacOS problems are now all solved except for 
some cosmetic issues ? Stefan, are you ok with release a version with 
Qt4 given that LyX 2.2. will be here much faster than LyX 2.1 came 
after LyX 2.0 ?


I'm now confused on the status on Windows. For me it looks rather ok.

Things to be fixed IMO:
- the master-child bug caused by used the master's BufferParams,

Last thing, do you still want me to do the final release ? I really 
want to get it out as soon as possible.


I think we should fix this and then release RC1. We should probably 
contact translators ASAP and give them a deadline. I gather there is 
more to do with that than with a branch release (something with layout 
translations), so perhaps a month?


Richard

Re: 2.1 release status

Vincent van Ravesteijn wrote:

> I don't understand. We package Python with LyX and we install Python in
> a subdir of the "C:\Program Files (x86)\LyX". Then we add this directory
> to the path ourselves. How come that we suddenly use Python3.0 ?

Probably because the windows system path takes precendence over the windows 
user path (and the LyX path prefix which is prepended to the user path 
AFAIK). For details see the other thread "Python problems on windows - some 
debugging hints", especially my messages from today 21:36 CET and from 
yesterday 20:47 CET. IMHO it would be really good if somebody who can build 
LyX on windows could investigate whether this is correct.

Georg

Re: 2.1 release status

Vincent van Ravesteijn wrote:

> I agree with you. IMO, the critical bugs left in the bug tracker are
> difficult to fix, and have been around for a long time.
> 
> Is it correct that the MacOS problems are now all solved except for some
> cosmetic issues ? Stefan, are you ok with release a version with Qt4
> given that LyX 2.2. will be here much faster than LyX 2.1 came after LyX
> 2.0 ?
> 
> I'm now confused on the status on Windows. For me it looks rather ok.

Unless we get a call stack or other usable information we cannot do anything 
IMHO.

> Things to be fixed IMO:
> - the master-child bug caused by used the master's BufferParams,

I agree with everything.

> Last thing, do you still want me to do the final release ? I really want
> to get it out as soon as possible.

Yes please, if you really have the time. If you don't have the time, or run 
out of time after starting the whole process, please tell as soon as 
possible, we'll find a different solution then.

Georg

Re: 2.1 release status


Am 10.03.2014 20:52, schrieb Vincent van Ravesteijn:


I don't understand. We package Python with LyX and we install Python in a subdir of 
the "C:\Program
Files (x86)\LyX". Then we add this directory to the path ourselves. How come 
that we suddenly use
Python3.0 ?


Yes, it seems that the bug reports I got have another origin because the installation of Python is 
the same as in LyX 2.0.x and I did not get any related bug report. (See my discussion with Georg).


regards Uwe

Re: 2.1 release status


Am 10.03.2014 21:47, schrieb Vincent van Ravesteijn:


I'm now confused on the status on Windows. For me it looks rather ok.


I just finished the Win installer for LyX 2.1. But LyX itself cannot be 
released as it is because:

- the documentation is not yet fully updated and I recently found bugs for 
every new feature I
described in the docs.

- Windows-specific: when you view a PDF a console window pops up and does not disappear. This a 
super annoying regression to LyX 2.0


- I need a test release for the win installer. This can be a RC1 release but I need then some weeks 
afterwards to get enough feedback.


- we need here some more images to advertise our new release! ;-):
http://wiki.lyx.org/LyX/NewInLyX21
I mean only 2 images and a desert of letters is not very pleasant. Compare this 
to
http://wiki.lyx.org/LyX/NewInLyX20

@ everybody: Can you please review
http://wiki.lyx.org/LyX/NewInLyX21
if all new features are listed so that I know what to document.

thanks and regards
Uwe

Re: 2.1 release status

2014-03-05 Thread Stephan Witt

Am 05.03.2014 um 00:25 schrieb Stephan Witt st.w...@gmx.net:

 Am 04.03.2014 um 23:45 schrieb Benjamin Piwowarski 
 benjamin.piwowar...@gmail.com:
 
 For some unknown reason, on OS X 10.9, I can reproduce the Omega bug with 
 Stephan's  QT4/cocoa build but not with the QT5/cocoa one…
 
 So, they've changed the QTextEngine. No magic. That's one of the pros to use 
 Qt-5.
 
 Stephan


Ticket http://http://www.lyx.org/trac/ticket/6902 is fixed in branch.

It's part of change 5a5d6a524ca8335149f394824bcdc307f70ebfc7.

It's not fixed in head. I'd like to solve it for 2.1. Patch is attached.

Stephan



macMenuBar-2a.patch
Description: Binary data

Re: 2.1 release status

2014-03-05 Thread Stephan Witt

Am 05.03.2014 um 00:25 schrieb Stephan Witt :

> Am 04.03.2014 um 23:45 schrieb Benjamin Piwowarski 
> :
> 
>> For some unknown reason, on OS X 10.9, I can reproduce the Omega bug with 
>> Stephan's  QT4/cocoa build but not with the QT5/cocoa one…
> 
> So, they've changed the QTextEngine. No magic. That's one of the pros to use 
> Qt-5.
> 
> Stephan


Ticket http://http://www.lyx.org/trac/ticket/6902 is fixed in branch.

It's part of change 5a5d6a524ca8335149f394824bcdc307f70ebfc7.

It's not fixed in head. I'd like to solve it for 2.1. Patch is attached.

Stephan



macMenuBar-2a.patch
Description: Binary data

Re: 2.1 release status

2014-03-04 Thread Jean-Marc Lasgouttes


04/03/2014 00:20, Uwe Stöhr:

No. There is still too much to do and the translators also need time. I
will see what I can do this week.
Is it really that pressing? I mean I will for sure find further issues
while updating the docs and I think we should take the time to fix as
many bugs as possible.


I think that the docs can continue to be updated after 2.1.0 is 
released. Concerning bugs, the best way to find out about them is to 
make a release.



But the most important issue is that LyX does still
require Python 2.7. This limitation is kind of a nightmare for me
because more and more PCs come with a pre-installed Python 3.x which
will of course interfere with Python 2.7.x so that LyX 2.1beta2 was not
configurable for some users. Or do I missed something and LyX is now
Python 3.x-ready? If so I will stress-test that.


I am surprised that there is no way to ensure that LyX finds its own 
python before the system one. In autoconf we have tests to make sure 
that we use the right python, I am sure this can be done in the windows 
installer and is less intrusive than updating and testing _all_ of our 
python scripts.


How come that 2.1.0beta2 was not configurable for some users but 2.0.x 
works fine?


I am not against moving to python 3.0, but there are better time for 
asking for that than when somebody says OK let's release this month.


JMarc

Re: 2.1 release status

2014-03-04 Thread Georg Baum

Uwe Stöhr wrote:

 Am 03.03.2014 22:28, schrieb Georg Baum:
 
 Thanks for the update, Jürgen, I agree. Uwe, are you finished with the
 documentation until then?
 
 No. There is still too much to do and the translators also need time. I
 will see what I can do this week.

What is missing? I agree completely with Jean-Marc here: it is no problem to 
continue with updating the docs in the stable 2.1 series as long as the 
major features are documented correctly. I also do not see any problems to 
extend the translation period after the RC, translations could not destroy 
the release.

 Is it really that pressing? I mean I will for sure find further issues
 while updating the docs and I think we should take the time to fix as many
 bugs as possible.

Yes, it is really that pressing. Adding a few days is no problem, but if we 
add weeks we won't release in the forseeable future. During the past weeks, 
several developers (including you) brought the release a big step forward. I 
really like how this worked (and would like to thank everybody who was 
involved), almost without coordination several people picked some problem to 
work on, and several show stoppers could be fixed. LyX 2.1 is in a really 
good shape now, and if we do not release soon, people will start to fix 
minor bugs and destabilize it again. This would also mean that we would 
basically need to repeat the beta testing and throw the beta testing effort 
of the past months away.

 LyX 2.1 still crashes frequently (I have no recipe to reproduce these
 crashes yet)

This is of course a problem (which I don't see on linux btw). It would be 
interesting to get a call stack of these crashes (either run the debug 
version, or compile the release version with debug symbols and attach the 
debugger to the running process after it crashed). Maybe the call stack 
would ring a bell in the head of somebody.

 and there are some Windows-specific issues Vincent and I
 could not solve (e.g. that LyX's console is now always shown when viewing
 a PDF.

I consider this a cosmetic issue which can also be solved later. Is there a 
bug report for this?

 But the most important issue is that LyX does still require Python
 2.7. This limitation is kind of a nightmare for me because more and more
 PCs come with a pre-installed Python 3.x which will of course interfere
 with Python 2.7.x so that LyX 2.1beta2 was not configurable for some
 users. Or do I missed something and LyX is now Python 3.x-ready? If so I
 will stress-test that.

LyX requires python 2, and as long as python 2 is maintained I don't see any 
pressing need to upgrade. python 2 and python 3 can be installed in parallel 
on windows, and this works without problems (BTDT). They store their 
configuration in versioned registry paths, the installer does not put 
anything into the PATH variable, the only thing you have to do (as a user) 
is to call the version you want.

As far as LyX is concerned, python 3 can be completely ignored. The LyX 
installer needs to check for a supported python 2.x, install it if it is 
missing, and put it into the LyX path prefix, so that it takes precedence 
about any python found in the system PATH (which could btw also be a cygwin 
python).

I don't see anything which could cause trouble with LyX and python 3, and 
even if there is a problem, I don't see how this would be different than in 
LyX 2.0.x, and how python 3 would behave differently than any other 
nonsuitable python version e.g. from cygwin (as far as LyX is concerned). 

What problem do you see exactly if python 3 is installed?


Georg

Re: 2.1 release status

OK, I updated the documentation - there are now two patches (one to update the 
code for a better version - I hope it can make it for 2.1, one for the 
documentation) attached to issue #8185.

http://lyx.lyx.org/trac/ticket/8185

Benjamin

On 03 Mar 2014, at 16:12 , Richard Heck rgh...@lyx.org wrote:

 On 03/03/2014 04:19 AM, Benjamin Piwowarski wrote:
 Regarding OS X, there is a new functionality - applescript support - which 
 is not documented at all. As I submitted the patch, I could also modify the 
 documentation but where should I put this?
 
 I would add it to the Additional Features manual, possibly as part of the LyX 
 Server chapter. Or you could make it a separate chapter after that one.
 
 Richard
 
 
 benjamin
 
 On 03 Mar 2014, at 08:41 , Jürgen Spitzmüller sp...@lyx.org wrote:
 
 Georg Baum wrote:
 fortunately there was a lot of activity in trac during the last days/weeks,
 so although it might look on the list that the upcoming release is not 
 being
 worked on this is not true. However, I believe it would be good to get a
 clear picture of what is missing here on the list, therefore I'd like to
 collect information about the show stoppers. What needs to be done?
 The status now is that we can release 2.1 as soon as the Mac Cocoa problems
 listed in #8959 are resolved:
 
 I think we should aim at a release in March. Do a RC in mid March, and then
 release two weeks later, if no urgent problems are reported.
 
 Stephan, Benjamin, is this realistic?
 
 Jürgen
 
 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: 2.1 release status

For some unknown reason, on OS X 10.9, I can reproduce the Omega bug with 
Stephan's  QT4/cocoa build but not with the QT5/cocoa one...

benjamin

On 03 Mar 2014, at 21:48 , Georg Baum georg.b...@post.rwth-aachen.de wrote:

 Jürgen Spitzmüller wrote:
 
 Benjamin Piwowarski wrote:
 with the latest build that Stephan sent me (qt4+cocoa), on OS X 10.9,
 
 - glyphs bugs are still there (7954 and 8945) - I have no idea of the
 difficulty of solving those issues,
 
 I suggest you first check whether the problem is with the workaround in
 GuiPainter.cpp:355, which forces QT to display characters at 0x00ad. Maybe
 this method fails for some reason with Cocoa.
 
 I think this bug is understood. It is caused by a combination of our hackish 
 channeling of math symbols through wrong unicode code points and some code 
 in qt which is identified in http://www.lyx.org/trac/ticket/7954#comment:11.
 
 A safe workaround for now would be to remap the affected glyphs in cmr.ttf 
 (which we ship) and change the numeric value in lib/symbols. Actually I 
 wonder why I did not realize before that we ship the affected fronts, since 
 I did such remapping for other fonts already. I can do that if you want.
 
 
 Georg



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: 2.1 release status

2014-03-04 Thread Stephan Witt

Am 04.03.2014 um 23:45 schrieb Benjamin Piwowarski 
benjamin.piwowar...@gmail.com:

 For some unknown reason, on OS X 10.9, I can reproduce the Omega bug with 
 Stephan's  QT4/cocoa build but not with the QT5/cocoa one…

So, they've changed the QTextEngine. No magic. That's one of the pros to use 
Qt-5.

Stephan

 On 03 Mar 2014, at 21:48 , Georg Baum georg.b...@post.rwth-aachen.de wrote:
 
 Jürgen Spitzmüller wrote:
 
 Benjamin Piwowarski wrote:
 with the latest build that Stephan sent me (qt4+cocoa), on OS X 10.9,
 
 - glyphs bugs are still there (7954 and 8945) - I have no idea of the
 difficulty of solving those issues,
 
 I suggest you first check whether the problem is with the workaround in
 GuiPainter.cpp:355, which forces QT to display characters at 0x00ad. Maybe
 this method fails for some reason with Cocoa.
 
 I think this bug is understood. It is caused by a combination of our hackish 
 channeling of math symbols through wrong unicode code points and some code 
 in qt which is identified in http://www.lyx.org/trac/ticket/7954#comment:11.
 
 A safe workaround for now would be to remap the affected glyphs in cmr.ttf 
 (which we ship) and change the numeric value in lib/symbols. Actually I 
 wonder why I did not realize before that we ship the affected fronts, since 
 I did such remapping for other fonts already. I can do that if you want.
 
 
 Georg

Re: 2.1 release status

2014-03-04 Thread Jean-Marc Lasgouttes


04/03/2014 00:20, Uwe Stöhr:

No. There is still too much to do and the translators also need time. I
will see what I can do this week.
Is it really that pressing? I mean I will for sure find further issues
while updating the docs and I think we should take the time to fix as
many bugs as possible.


I think that the docs can continue to be updated after 2.1.0 is 
released. Concerning bugs, the best way to find out about them is to 
make a release.



But the most important issue is that LyX does still
require Python 2.7. This limitation is kind of a nightmare for me
because more and more PCs come with a pre-installed Python 3.x which
will of course interfere with Python 2.7.x so that LyX 2.1beta2 was not
configurable for some users. Or do I missed something and LyX is now
Python 3.x-ready? If so I will stress-test that.


I am surprised that there is no way to ensure that LyX finds its own 
python before the system one. In autoconf we have tests to make sure 
that we use the right python, I am sure this can be done in the windows 
installer and is less intrusive than updating and testing _all_ of our 
python scripts.


How come that 2.1.0beta2 was not configurable for some users but 2.0.x 
works fine?


I am not against moving to python 3.0, but there are better time for 
asking for that than when somebody says "OK let's release this month".


JMarc

Re: 2.1 release status

2014-03-04 Thread Georg Baum

Uwe Stöhr wrote:

> Am 03.03.2014 22:28, schrieb Georg Baum:
> 
>> Thanks for the update, Jürgen, I agree. Uwe, are you finished with the
>> documentation until then?
> 
> No. There is still too much to do and the translators also need time. I
> will see what I can do this week.

What is missing? I agree completely with Jean-Marc here: it is no problem to 
continue with updating the docs in the stable 2.1 series as long as the 
major features are documented correctly. I also do not see any problems to 
extend the translation period after the RC, translations could not destroy 
the release.

> Is it really that pressing? I mean I will for sure find further issues
> while updating the docs and I think we should take the time to fix as many
> bugs as possible.

Yes, it is really that pressing. Adding a few days is no problem, but if we 
add weeks we won't release in the forseeable future. During the past weeks, 
several developers (including you) brought the release a big step forward. I 
really like how this worked (and would like to thank everybody who was 
involved), almost without coordination several people picked some problem to 
work on, and several show stoppers could be fixed. LyX 2.1 is in a really 
good shape now, and if we do not release soon, people will start to fix 
minor bugs and destabilize it again. This would also mean that we would 
basically need to repeat the beta testing and throw the beta testing effort 
of the past months away.

> LyX 2.1 still crashes frequently (I have no recipe to reproduce these
> crashes yet)

This is of course a problem (which I don't see on linux btw). It would be 
interesting to get a call stack of these crashes (either run the debug 
version, or compile the release version with debug symbols and attach the 
debugger to the running process after it crashed). Maybe the call stack 
would ring a bell in the head of somebody.

> and there are some Windows-specific issues Vincent and I
> could not solve (e.g. that LyX's console is now always shown when viewing
> a PDF.

I consider this a cosmetic issue which can also be solved later. Is there a 
bug report for this?

> But the most important issue is that LyX does still require Python
> 2.7. This limitation is kind of a nightmare for me because more and more
> PCs come with a pre-installed Python 3.x which will of course interfere
> with Python 2.7.x so that LyX 2.1beta2 was not configurable for some
> users. Or do I missed something and LyX is now Python 3.x-ready? If so I
> will stress-test that.

LyX requires python 2, and as long as python 2 is maintained I don't see any 
pressing need to upgrade. python 2 and python 3 can be installed in parallel 
on windows, and this works without problems (BTDT). They store their 
configuration in versioned registry paths, the installer does not put 
anything into the PATH variable, the only thing you have to do (as a user) 
is to call the version you want.

As far as LyX is concerned, python 3 can be completely ignored. The LyX 
installer needs to check for a supported python 2.x, install it if it is 
missing, and put it into the LyX path prefix, so that it takes precedence 
about any python found in the system PATH (which could btw also be a cygwin 
python).

I don't see anything which could cause trouble with LyX and python 3, and 
even if there is a problem, I don't see how this would be different than in 
LyX 2.0.x, and how python 3 would behave differently than any other 
nonsuitable python version e.g. from cygwin (as far as LyX is concerned). 

What problem do you see exactly if python 3 is installed?

Georg

Re: 2.1 release status

OK, I updated the documentation - there are now two patches (one to update the 
code for a better version - I hope it can make it for 2.1, one for the 
documentation) attached to issue #8185.

http://lyx.lyx.org/trac/ticket/8185

Benjamin

On 03 Mar 2014, at 16:12 , Richard Heck  wrote:

> On 03/03/2014 04:19 AM, Benjamin Piwowarski wrote:
>> Regarding OS X, there is a new functionality - applescript support - which 
>> is not documented at all. As I submitted the patch, I could also modify the 
>> documentation but where should I put this?
> 
> I would add it to the Additional Features manual, possibly as part of the LyX 
> Server chapter. Or you could make it a separate chapter after that one.
> 
> Richard
> 
>> 
>> benjamin
>> 
>> On 03 Mar 2014, at 08:41 , Jürgen Spitzmüller  wrote:
>> 
>>> Georg Baum wrote:
 fortunately there was a lot of activity in trac during the last days/weeks,
 so although it might look on the list that the upcoming release is not 
 being
 worked on this is not true. However, I believe it would be good to get a
 clear picture of what is missing here on the list, therefore I'd like to
 collect information about the show stoppers. What needs to be done?
>>> The status now is that we can release 2.1 as soon as the Mac Cocoa problems
>>> listed in #8959 are resolved:
>>> 
>>> I think we should aim at a release in March. Do a RC in mid March, and then
>>> release two weeks later, if no urgent problems are reported.
>>> 
>>> Stephan, Benjamin, is this realistic?
>>> 
>>> Jürgen
>>> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: 2.1 release status