Discussion:
LyX 2.0.1 Sources Available
Richard Heck
2011-08-31 18:23:18 UTC
Permalink
I have put what I hope will be LyX 2.0.1 here:
http://frege.brown.edu/lyx/lyx-2.0.1.tar.gz
http://frege.brown.edu/lyx/lyx-2.0.1.tar.gz.sig
http://frege.brown.edu/lyx/lyx-2.0.1.tar.xz
http://frege.brown.edu/lyx/lyx-2.0.1.tar.xz.sig
for testing. Please let me know if you have any trouble building it.
Assuming there are no problems, I will officially release in the
morning, Thursday, my time.

Please use the xz file if you can, to minimize bandwidth.

Also, a question. What do people think about releasing patch files? Does
anyone use them? They are not that difficult to create, I would suppose,
but they do take time.

Richard
Stephan Witt
2011-09-01 09:31:28 UTC
Permalink
Post by Richard Heck
http://frege.brown.edu/lyx/lyx-2.0.1.tar.gz
http://frege.brown.edu/lyx/lyx-2.0.1.tar.gz.sig
http://frege.brown.edu/lyx/lyx-2.0.1.tar.xz
http://frege.brown.edu/lyx/lyx-2.0.1.tar.xz.sig
for testing. Please let me know if you have any trouble building it.
Assuming there are no problems, I will officially release in the
morning, Thursday, my time.
I have no problem on Mac OS X. The build went fine.
Post by Richard Heck
Please use the xz file if you can, to minimize bandwidth.
Also, a question. What do people think about releasing patch files? Does
anyone use them? They are not that difficult to create, I would suppose,
but they do take time.
I'd say it's not necessary.

Stephan
Pavel Sanda
2011-09-01 11:43:19 UTC
Permalink
Post by Stephan Witt
Post by Richard Heck
for testing. Please let me know if you have any trouble building it.
Assuming there are no problems, I will officially release in the
morning, Thursday, my time.
I have no problem on Mac OS X. The build went fine.
build went fine on x86 linux, everything seems to work.

no showstopper but iirc this message was not there in 1.6 builds:
Server.cpp:1018: warning: ignoring return value of 'ssize_t write(int, const void*, size_t)', declared with attribute warn_unused_result

pavel
Richard Heck
2011-09-01 14:19:25 UTC
Permalink
Post by Pavel Sanda
Post by Stephan Witt
Post by Richard Heck
for testing. Please let me know if you have any trouble building it.
Assuming there are no problems, I will officially release in the
morning, Thursday, my time.
I have no problem on Mac OS X. The build went fine.
build went fine on x86 linux, everything seems to work.
Server.cpp:1018: warning: ignoring return value of 'ssize_t write(int, const void*, size_t)', declared with attribute warn_unused_result
We should fix this, though it is presumably harmless.

Richard
Jean-Pierre Chrétien
2011-09-01 08:55:54 UTC
Permalink
Post by Richard Heck
http://frege.brown.edu/lyx/lyx-2.0.1.tar.xz
http://frege.brown.edu/lyx/lyx-2.0.1.tar.xz.sighttp://frege.brown.edu/lyx/lyx-2.0.1.tar.xz.sig
Post by Richard Heck
for testing. Please let me know if you have any trouble building it.
Builds flawlessly here (Debian Squeeze):

Configuration
Host type: i686-pc-linux-gnu
Special build flags: build=release use-aspell
C Compiler: gcc
C Compiler LyX flags:
C Compiler flags: -O2
C++ Compiler: g++ (4.4.5)
C++ Compiler LyX flags:
C++ Compiler flags: -O2
Linker flags:
Linker user flags:
Qt 4 Frontend:
Qt 4 version: 4.6.3
Packaging: posix
LyX binary dir: /usr/local/bin
LyX files dir: /usr/local/share/lyx-2.0.1

The new verbosity of the makefiles is fine.

Compilation of French versions of UserGuide and EmbeddedObjects fail for a
similar reason: bad language change location in a sectioning heading. I guess
this can wait for 2.0.2, in the meanwhile a correct pdf can be committed in the
wiki.
Post by Richard Heck
Also, a question. What do people think about releasing patch files? Does
anyone use them? They are not that difficult to create, I would suppose,
but they do take time.
I never use it, full distribution upload time is quite short compared to
compilation time.
--
Jean-Pierre
Uwe Stöhr
2011-09-01 14:15:14 UTC
Permalink
Post by Jean-Pierre Chrétien
Compilation of French versions of UserGuide and EmbeddedObjects fail for a
similar reason: bad language change location in a sectioning heading.
Where? For me all documentation files for all languages compile.

regards Uwe
Jean-Pierre Chrétien
2011-09-05 06:49:00 UTC
Permalink
Post by Uwe Stöhr
Post by Jean-Pierre Chrétien
Compilation of French versions of UserGuide and EmbeddedObjects fail for a
similar reason: bad language change location in a sectioning heading.
Where? For me all documentation files for all languages compile.
On Linux/TexLive I get the following errors.

In UserGuide:

<cite>
Overfull \hbox (10.96574pt too wide) in paragraph at lines 103--104
[]\T1/lmr/bx/n/12 Environnements de Pa-ra-graphe, [][]18[][]--
[]

! Extra }, or forgotten \endgroup.
l.125 \subitem Details}
\selectlanguage {english} , \hyperpage{77}
I've deleted a group-closing symbol because it seems to be
spurious, as in `$x}$'. But perhaps the } is legitimate and
you forgot something else, as in `\hbox{$x}'. In such cases
the way to recover is to insert both the forgotten and the
deleted material, e.g., by typing `I$}'.
</cite>

After investigation, this error is due to the fact that the word 'Flottants' is
in French in the index inset within title of section 4.6.3. The exported latex
construct

\subsection{More Information\index{Flottants@\selectlanguage{french}%
Flottants\foreignlanguage{english}{!***@Details}\selectlanguage{english}
}}

creates the abovementioned error, as texindy creates line

\subitem Details}\selectlanguage{english} , \hyperpage{79}

in UserGuide.ind.

This will be corrected when the section will be translated, but does this
deserve a ticket ? I wonder whether this is a LyX bug in the exported LaTeX
syntax or a index generator bug, which should not export
'}\selectlanguage{english}'.

In EmbeddedObjects:

<cite>
Chapter 6.
Runaway argument?
! Paragraph ended before \def was complete.
<to be read again>
\par
l.5632 ...anguage{french}{Flottants d'enrobage}}}}

I suspect you've forgotten a `}', causing me to apply this
control sequence to too much text. How can we recover?
My plan is to forget the whole thing and hope for the best.
</cite>

and a set of errors triggered by the first one.

Change of language in a header title again, the offending code reads in LaTeX:

\section{Flottant d'enrobage\label{sec:Flottant-d'enrobage}
\index{Flottants!Flottants d'enrobage}\foreignlanguage{english}
{\index{Surrounded by text!Flottants d'enrobage@\foreignlanguage{french}
{Flottants d'enrobage}}}}

on one single line.

Again the error is due to an incompletely translated index entry, but this time
the error occurs at the first pdflatex pass. The recursive \foreignlanguage
construct in an index entry seems there incorrect in LaTeX (no more errors if I
remove the external \foreignlanguage{english}{...} command).

I wonder why you do not see these errors ? In the first case, this may be due to
the indexing engine, but in the second one, this seems a native TeX error.
--
Jean-Pierre
Uwe Stöhr
2011-09-05 15:09:13 UTC
Permalink
After investigation, this error is due to the fact that the word 'Flottants' is in French in the
index inset within title of section 4.6.3. The exported latex construct
}}
creates the abovementioned error, as texindy creates line
\subitem Details}\selectlanguage{english} , \hyperpage{79}
in UserGuide.ind.
This will be corrected when the section will be translated, but does this
deserve a ticket ?
I'm not seeing these issues because xindy is not available under Windows and thus makeindex is used
as indexing program.
It seems that xindy doesn't support multiple languages in index entries while this works without
problems with makeindex.
There is nothing we can do about it because denying multiple languages would change existing LyX
files that compile fine with makeindex.
We have this problematic in other cases too, for example with tables. Depending on the document
settings, multiple languages work, sometimes not.

For now, can you please translate the problematic cases right now?

Richard, what about LyX 2.0.1? Is it delayed, so that I can put this in?

regards Uwe
Helge Hafting
2011-09-09 09:04:39 UTC
Permalink
On 05. sep. 2011 08:49, Jean-Pierre Chrétien wrote:
[...]
Post by Jean-Pierre Chrétien
After investigation, this error is due to the fact that the word
'Flottants' is in French in the index inset within title of section
4.6.3. The exported latex construct
}}
creates the abovementioned error, as texindy creates line
\subitem Details}\selectlanguage{english} , \hyperpage{79}
in UserGuide.ind.
This will be corrected when the section will be translated, but does this
deserve a ticket ? I wonder whether this is a LyX bug in the exported LaTeX
syntax or a index generator bug, which should not export
'}\selectlanguage{english}'.
Seems like a LyX bug to me, but a workaround is possible.

We see that "selectlanguage" inside an index entry cause trouble.
Therefore, LyX should not emit language change commands inside index
entries. This is probably not necessary either - an index entry will
not be hyphenated so language support is not needed there.
So you may write a bug report - unless someone can point out
a need for language commands inside index entries. Maybe these
commands sometimes do more than hyphenation?

The workaround is to make index entries free of language commands.
Use "View->code" and make sure your index entries are language-free.
Some ways:
* Revert language. May not work, sometimes a \selectlanguage
remains at the end of the index entry. Possibly also a bug.

* Rewrite the index entries in some part of the document
that uses the "document language".
Then cut&paste the entries to where they should be.

This way, index entries will not be marked with the correct
language (which doesn't matter), but they will at least print.

Helge Hafting
Jürgen Spitzmüller
2011-09-09 09:32:44 UTC
Permalink
Post by Helge Hafting
We see that "selectlanguage" inside an index entry cause trouble.
Therefore, LyX should not emit language change commands inside index
entries. This is probably not necessary either - an index entry will
not be hyphenated so language support is not needed there.
Unless you have a justified index and therefore _want_ to hyphenate entries.
We should rather fix the LaTeX output than omit it.
Post by Helge Hafting
The workaround is to make index entries free of language commands.
Use "View->code" and make sure your index entries are language-free.
* Revert language. May not work, sometimes a \selectlanguage
remains at the end of the index entry. Possibly also a bug.
* Rewrite the index entries in some part of the document
that uses the "document language".
Then cut&paste the entries to where they should be.
This way, index entries will not be marked with the correct
language (which doesn't matter), but they will at least print.
Of course it does matter as soon as you want to spellcheck your document.

Jürgen
Jürgen Spitzmüller
2011-09-01 12:17:41 UTC
Permalink
Post by Richard Heck
Also, a question. What do people think about releasing patch files? Does
anyone use them? They are not that difficult to create, I would suppose,
but they do take time.
I don't know if anybody really uses it, but I always used them to check the
changes in advance of a release. And it's some kind of a service for
interested users.

Jürgen
Uwe Stöhr
2011-09-01 14:19:56 UTC
Permalink
Works fine and a Win installer is ready (the merged one). I'll leave the installer for LyX 2.0.1 to
Joost because the merged installer is not yet able to install LyX if you install it without admin
privileges (due to a Imagemagick issue).
I will nevertheless release LyX 2.0.1 with the merged installer via my berlios account to get some
feedback from the users about possible bugs. From my point of view it is already stable enough since
I tested it a lot on different Windows and computers.
In case that Joost cannot provide an installer soon, you can set a link to my berlios page at
www.lyx.org if you like.

regards Uwe
Julien Rioux
2011-09-01 14:40:55 UTC
Permalink
From my point of view it is already stable enough since I tested it a
lot on different Windows and computers.
In case that Joost cannot provide an installer soo
Was this bug fixed?
http://www.lyx.org/trac/ticket/7737
--
Julien
Vincent van Ravesteijn
2011-09-01 14:46:22 UTC
Permalink
Post by Julien Rioux
From my point of view it is already stable enough since I tested it a
lot on different Windows and computers.
In case that Joost cannot provide an installer soo
Was this bug fixed?
http://www.lyx.org/trac/ticket/7737
Why do we keep specifying the build number for MikTex. If they release a
new version with a new build number, our link breaks.

Why not just link to /path/to/miktex/basic-installer.exe (or how it is
called ?)

Vincent
Uwe Stöhr
2011-09-01 17:48:47 UTC
Permalink
Post by Julien Rioux
Was this bug fixed?
http://www.lyx.org/trac/ticket/7737
I don't know what this is about. guess that Joost is downloading MiKTeX fro somewhere. I'll have a
look.

In th merged installer MiKTeX is directly included. So even if you don't have Internet access, you
can install LyX and it will work with its basic features. There were some reasonable user requests
in the past to include MiKTeX directly and the MiKTeX maintainer kindly built in some features for
us in his basic installer.
Why do we keep specifying the build number for MikTex. If they release a new version with a new
build number, our link breaks.
This number in the merged installer is part of the executable. This will be called to install
MiKTeX. What I can do is to get rid of this number and rename the MiKTeX basic executable and
include this one in the installer. But the amount of work for packaging will be the same: either
update the version number in the setup script or rename the executable. The first method has the
advantage that if there are problems we can ask the user which MiKTeX installer version they used.

regards Uwe
Vincent van Ravesteijn
2011-09-02 06:41:49 UTC
Permalink
Post by Julien Rioux
Was this bug fixed?
Post by Vincent van Ravesteijn
http://www.lyx.org/trac/**ticket/7737<http://www.lyx.org/trac/ticket/7737>
I don't know what this is about. guess that Joost is downloading MiKTeX
fro somewhere. I'll have a look.
In th merged installer MiKTeX is directly included. So even if you don't
have Internet access, you can install LyX and it will work with its basic
features. There were some reasonable user requests in the past to include
MiKTeX directly and the MiKTeX maintainer kindly built in some features for
us in his basic installer.
I would prefer not to include MikTeX in the installer. Most people that
download LyX already have MikTeX installed, so why would you bother them
with a huge download.
Post by Julien Rioux
Why do we keep specifying the build number for MikTex. If they release a
Post by Vincent van Ravesteijn
new version with a new
build number, our link breaks.
This number in the merged installer is part of the executable. This will be
called to install MiKTeX. What I can do is to get rid of this number and
rename the MiKTeX basic executable and include this one in the installer.
But the amount of work for packaging will be the same: either update the
version number in the setup script or rename the executable. The first
method has the advantage that if there are problems we can ask the user
which MiKTeX installer version they used.
Ah so.. but when the installer downloads MikTeX from the web, we better can
use the link without a build number. That was my point. It has happened too
often that the MikTeX link fails.


Vincent
Uwe Stöhr
2011-09-05 15:05:42 UTC
Permalink
Post by Vincent van Ravesteijn
Post by Uwe Stöhr
In th merged installer MiKTeX is directly included. So even if you don't
have Internet access, you can install LyX and it will work with its basic
features. There were some reasonable user requests in the past to include
MiKTeX directly and the MiKTeX maintainer kindly built in some features for
us in his basic installer.
I would prefer not to include MikTeX in the installer. Most people that
download LyX already have MikTeX installed, so why would you bother them
with a huge download.
For these people we have the standard installer. The bundle installer is especially designed for new
installations and therefore includes MiKTeX and JabRef (is optional). So the standard installer will
not bother the user and is as small as possible to update existing LyX installations. This variant
therefore expects an installed MiKTeX. If no MiKTeX or TeXLive is found, it will throw a warning
that the bundle installer should be used.
Post by Vincent van Ravesteijn
Ah so.. but when the installer downloads MikTeX from the web, we better can
use the link without a build number. That was my point.
Sure, but this is only the case in Joost's installer not in the merged one which will be our new
installer, hopefully to be ready for LyX 2.0.2. Despite of the installation without admin
privileges, it is ready to use in my opinion, please check it out, if you find some time.

regards Uwe
Vincent van Ravesteijn
2011-09-05 18:01:48 UTC
Permalink
Post by Uwe Stöhr
Post by Vincent van Ravesteijn
Post by Uwe Stöhr
In th merged installer MiKTeX is directly included. So even if you don't
have Internet access, you can install LyX and it will work with its basic
features. There were some reasonable user requests in the past to include
MiKTeX directly and the MiKTeX maintainer kindly built in some features for
us in his basic installer.
I would prefer not to include MikTeX in the installer. Most people that
download LyX already have MikTeX installed, so why would you bother them
with a huge download.
For these people we have the standard installer. The bundle installer
is especially designed for new installations and therefore includes
MiKTeX and JabRef (is optional). So the standard installer will not
bother the user and is as small as possible to update existing LyX
installations. This variant therefore expects an installed MiKTeX. If
no MiKTeX or TeXLive is found, it will throw a warning that the bundle
installer should be used.
Why don't we download it anymore then ? We did this as long as I
remember having Windows installers.

Vincent
Uwe Stöhr
2011-09-06 03:37:38 UTC
Permalink
Post by Vincent van Ravesteijn
Post by Uwe Stöhr
For these people we have the standard installer. The bundle installer is especially designed for
new installations and therefore includes MiKTeX and JabRef (is optional). So the standard
installer will not bother the user and is as small as possible to update existing LyX
installations. This variant therefore expects an installed MiKTeX. If no MiKTeX or TeXLive is
found, it will throw a warning that the bundle installer should be used.
Why don't we download it anymore then ?
Then we would have the same trouble as we have now in the installer for 2.0.0 with broken download
links and we need more complicated installer code.
Besides this there are from time to time bugs in MiKTeX releases that break LaTeX packages. By
including MiKTeX we assure that we are shipping a tested MiKTeX build.
Post by Vincent van Ravesteijn
We did this as long as I remember having Windows installers.
Never with my installer. I provide the solution with the two installer variants since I'm involved
to LyX and I never had complaints that new users used the standard installer without having LaTeX
installed.

regards Uwe
Vincent van Ravesteijn
2011-09-02 13:46:59 UTC
Permalink
Post by Uwe Stöhr
Works fine and a Win installer is ready (the merged one).
Can you send me a link to this installer. I want to test it.

Vincent
Stephan Witt
2011-09-03 13:36:56 UTC
Permalink
I've been fiddling around endlessly to get the Application menu translated.. without succces.. Unfortunately LyX has the same problem.
Are you aware that the documentation is not localized for LyX ? Was there a reason for or did you not came to it yet ?
The relevant code to choose the correct online help file is in i18nLibFileSearch.
I've armed it with debug - both for 1.6.10 and 2.0.1 - like below:

--- lyx-2.0.1/src/support/filetools.cpp 2011-08-28 20:44:53.000000000 +0200
+++ lyx-2.0.1-locale/src/support/filetools.cpp 2011-09-03 13:16:00.000000000 +0200
@@ -273,6 +273,7 @@

string lang = to_ascii(_(languageTestString()));
string const language = getEnv("LANGUAGE");
+ LYXERR(Debug::LOCALE, "i18nLibFileSearch: lang = " << lang);
if (!lang.empty() && !language.empty())
lang = language;


The output is very different!

% locale
LANG="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_CTYPE="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_ALL=

% LyX-1.6.10.app/Contents/MacOS/lyx -dbg locale
Setting debug level to locale
Debugging `locale' (Locale/Internationalisation)
/Users/Shared/LyX/lyx-1.6.10/src/support/filetools.cpp(252): i18nLibFileSearch: lang = de
...

% LyX-2.0.1.app/Contents/MacOS/lyx -dbg locale
Festlegen des Test-Levels auf locale
Testen von `locale' (Spracheinstellungen/Internationalisierung)
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(97): language(ignore)
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(150): Setting LANGUAGE to ignore
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(160): Setting LC_ALL to en_US
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(195): restoring LANGUAGE from ignore to
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(199): restoring LC_ALL from en_US to
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(97): language(latex)
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(150): Setting LANGUAGE to latex
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(160): Setting LC_ALL to en_US
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(195): restoring LANGUAGE from latex to
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(199): restoring LC_ALL from en_US to
...
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(97): language(cy_GB)
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(150): Setting LANGUAGE to cy_GB
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(160): Setting LC_ALL to en_US
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(195): restoring LANGUAGE from cy_GB to
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(199): restoring LC_ALL from en_US to
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/filetools.cpp(276): i18nLibFileSearch: lang = en
...

Somehow the locale environment is not honored by LyX in i18nLibFileSearch. I don't know if this is intended.
The result is LyX opening the online help files in english. One has to set the interface language explicitly
in the prefs to get the online help in sync with the menu language.

BTW, this is a regression already in LyX-2.0.0...

Stephan
Richard Heck
2011-09-03 14:18:22 UTC
Permalink
Post by Stephan Witt
I've been fiddling around endlessly to get the Application menu translated.. without succces.. Unfortunately LyX has the same problem.
Are you aware that the documentation is not localized for LyX ? Was there a reason for or did you not came to it yet ?
The relevant code to choose the correct online help file is in i18nLibFileSearch.
--- lyx-2.0.1/src/support/filetools.cpp 2011-08-28 20:44:53.000000000 +0200
+++ lyx-2.0.1-locale/src/support/filetools.cpp 2011-09-03 13:16:00.000000000 +0200
@@ -273,6 +273,7 @@
string lang = to_ascii(_(languageTestString()));
string const language = getEnv("LANGUAGE");
+ LYXERR(Debug::LOCALE, "i18nLibFileSearch: lang = " << lang);
if (!lang.empty() && !language.empty())
lang = language;
The output is very different!
% locale
LANG="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_CTYPE="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_ALL=
% LyX-1.6.10.app/Contents/MacOS/lyx -dbg locale
Setting debug level to locale
Debugging `locale' (Locale/Internationalisation)
/Users/Shared/LyX/lyx-1.6.10/src/support/filetools.cpp(252): i18nLibFileSearch: lang = de
...
% LyX-2.0.1.app/Contents/MacOS/lyx -dbg locale
Festlegen des Test-Levels auf locale
Testen von `locale' (Spracheinstellungen/Internationalisierung)
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(97): language(ignore)
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(150): Setting LANGUAGE to ignore
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(160): Setting LC_ALL to en_US
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(195): restoring LANGUAGE from ignore to
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(199): restoring LC_ALL from en_US to
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(97): language(latex)
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(150): Setting LANGUAGE to latex
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(160): Setting LC_ALL to en_US
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(195): restoring LANGUAGE from latex to
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(199): restoring LC_ALL from en_US to
...
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(97): language(cy_GB)
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(150): Setting LANGUAGE to cy_GB
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(160): Setting LC_ALL to en_US
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(195): restoring LANGUAGE from cy_GB to
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(199): restoring LC_ALL from en_US to
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/filetools.cpp(276): i18nLibFileSearch: lang = en
...
Somehow the locale environment is not honored by LyX in i18nLibFileSearch. I don't know if this is intended.
The result is LyX opening the online help files in english. One has to set the interface language explicitly
in the prefs to get the online help in sync with the menu language.
BTW, this is a regression already in LyX-2.0.0...
If this is regarded as a regression, then please file a bug for it.
However, if I'm understanding what is happening, then it seems to me
correct. If the UI language is set to French, then shouldn't the help
files open in French, whatever the language externally? Or does LyX
honor the LANG variable for UI, but not for the docs?

Perhaps a look at git log for filetools.cpp would turn something up....

Richard
Stephan Witt
2011-09-03 16:30:09 UTC
Permalink
Post by Richard Heck
Post by Stephan Witt
I've been fiddling around endlessly to get the Application menu translated.. without succces.. Unfortunately LyX has the same problem.
Are you aware that the documentation is not localized for LyX ? Was there a reason for or did you not came to it yet ?
The relevant code to choose the correct online help file is in i18nLibFileSearch.
--- lyx-2.0.1/src/support/filetools.cpp 2011-08-28 20:44:53.000000000 +0200
+++ lyx-2.0.1-locale/src/support/filetools.cpp 2011-09-03 13:16:00.000000000 +0200
@@ -273,6 +273,7 @@
string lang = to_ascii(_(languageTestString()));
string const language = getEnv("LANGUAGE");
+ LYXERR(Debug::LOCALE, "i18nLibFileSearch: lang = " << lang);
if (!lang.empty() && !language.empty())
lang = language;
The output is very different!
% locale
LANG="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_CTYPE="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_ALL=
% LyX-1.6.10.app/Contents/MacOS/lyx -dbg locale
Setting debug level to locale
Debugging `locale' (Locale/Internationalisation)
/Users/Shared/LyX/lyx-1.6.10/src/support/filetools.cpp(252): i18nLibFileSearch: lang = de
...
% LyX-2.0.1.app/Contents/MacOS/lyx -dbg locale
Festlegen des Test-Levels auf locale
Testen von `locale' (Spracheinstellungen/Internationalisierung)
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(97): language(ignore)
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(150): Setting LANGUAGE to ignore
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(160): Setting LC_ALL to en_US
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(195): restoring LANGUAGE from ignore to
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(199): restoring LC_ALL from en_US to
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(97): language(latex)
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(150): Setting LANGUAGE to latex
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(160): Setting LC_ALL to en_US
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(195): restoring LANGUAGE from latex to
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(199): restoring LC_ALL from en_US to
...
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(97): language(cy_GB)
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(150): Setting LANGUAGE to cy_GB
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(160): Setting LC_ALL to en_US
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(195): restoring LANGUAGE from cy_GB to
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(199): restoring LC_ALL from en_US to
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/filetools.cpp(276): i18nLibFileSearch: lang = en
...
Somehow the locale environment is not honored by LyX in i18nLibFileSearch. I don't know if this is intended.
The result is LyX opening the online help files in english. One has to set the interface language explicitly
in the prefs to get the online help in sync with the menu language.
BTW, this is a regression already in LyX-2.0.0...
If this is regarded as a regression, then please file a bug for it.
I'll do that. I was not sure if it's a bug - but it looks like.
Post by Richard Heck
However, if I'm understanding what is happening, then it seems to me
correct. If the UI language is set to French, then shouldn't the help
files open in French, whatever the language externally? Or does LyX
honor the LANG variable for UI, but not for the docs?
This is the problem. The LANG variable is set to "de_DE.UTF-8". Therefor the UI is german.
But the docs are in english because of the "i18nLibFileSearch: lang = en" above.
LyX 1.6 prints "i18nLibFileSearch: lang = de" in the same environment.

I've checked the preferences already, if I set the UI language this is honored.
That's why I didn't detect this. The default value for language is empty of course.
Post by Richard Heck
Perhaps a look at git log for filetools.cpp would turn something up....
I'm afraid it's a complex interaction of gettext and the use of the Messages class.

Stephan
Jean-Marc Lasgouttes
2011-09-03 18:03:13 UTC
Permalink
Post by Stephan Witt
This is the problem. The LANG variable is set to "de_DE.UTF-8". Therefor the UI is german.
But the docs are in english because of the "i18nLibFileSearch: lang = en" above.
LyX 1.6 prints "i18nLibFileSearch: lang = de" in the same environment.
I've checked the preferences already, if I set the UI language this is honored.
That's why I didn't detect this. The default value for language is empty of course.
I had a go at it some time go, and it looks like the code that looks for
existing translations (int Language initialization) loads all the .gmo
files and after some point gettext refuses to load a new one. You can
check whether removing the test for availability in Language loading
fixes your problem

JMarc
Stephan Witt
2011-09-03 19:25:47 UTC
Permalink
Post by Stephan Witt
This is the problem. The LANG variable is set to "de_DE.UTF-8". Therefor the UI is german.
But the docs are in english because of the "i18nLibFileSearch: lang = en" above.
LyX 1.6 prints "i18nLibFileSearch: lang = de" in the same environment.
I've checked the preferences already, if I set the UI language this is honored.
That's why I didn't detect this. The default value for language is empty of course.
I had a go at it some time go, and it looks like the code that looks for existing translations (int Language initialization) loads all the .gmo files and after some point gettext refuses to load a new one. You can check whether removing the test for availability in Language loading fixes your problem
When I remove the test it works. :(

I get the following output:

% /Users/Shared/LyX/lyx-build/LyX-2.0.1.build/src/lyx -dbg locale
Festlegen des Test-Levels auf locale
Testen von `locale' (Spracheinstellungen/Internationalisierung)
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(83): Default language set to de_DE.UTF-8
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/Messages.cpp(83): Default language set to de_DE.UTF-8
/Users/Shared/LyX/lyx-2.0.1-locale/src/support/filetools.cpp(276): i18nLibFileSearch: lang = de

So we are in trouble, aren't we?

Stephan
Jean-Marc Lasgouttes
2011-09-06 09:50:47 UTC
Permalink
Post by Stephan Witt
I had a go at it some time go, and it looks like the code that looks for existing translations (int Language initialization) loads all the .gmo files and after some point gettext refuses to load a new one. You can check whether removing the test for availability in Language loading fixes your problem
When I remove the test it works.
So we are in trouble, aren't we?
I think anyway that loading all gmo files just to know which ones exist
is a broken concept. We have to find another way to detect which
languages are supported.

JMarc
Vincent van Ravesteijn
2011-09-06 10:21:12 UTC
Permalink
Post by Jean-Marc Lasgouttes
Post by Stephan Witt
Post by Jean-Marc Lasgouttes
I had a go at it some time go, and it looks like the code that looks
for existing translations (int Language initialization) loads all
the .gmo files and after some point gettext refuses to load a new
one. You can check whether removing the test for availability in
Language loading fixes your problem
When I remove the test it works.
So we are in trouble, aren't we?
I think anyway that loading all gmo files just to know which ones
exist is a broken concept. We have to find another way to detect which
languages are supported.
JMarc
[Quietly repeating what I had already said]
Post by Jean-Marc Lasgouttes
The translation of the string languageTestString() is cached, so maybe
we ask for the translation of this string before gettext is
initialized with the correct locale ?
After further investigation: When testing for the language availability,
we call "translated_ = getMessages(code()).available();". In
Post by Jean-Marc Lasgouttes
string const test = languageTestString();
string const trans = to_utf8(get(test));
Now, this causes the translation of languageTestString() to be cached.
If we try to load all languages to see whether they are available, the
cached value is thus pretty much random.

When we call i18nLibFileSearch, we again try to translate
languageTestString() and we return the cached value.

If you remove the above test for the translation, the translation
doesn't cache the value for languageTestString() and no problems appear.


Vincent
Jean-Marc Lasgouttes
2011-09-06 11:19:41 UTC
Permalink
Post by Vincent van Ravesteijn
Now, this causes the translation of languageTestString() to be cached.
If we try to load all languages to see whether they are available, the
cached value is thus pretty much random.
When we call i18nLibFileSearch, we again try to translate
languageTestString() and we return the cached value.
If you remove the above test for the translation, the translation
doesn't cache the value for languageTestString() and no problems appear.
When I was still young and naive about this problem, I suspected a cache
problem. Therefore I tried to disable completely the cache but the
situation did not change...

I really think the problem is related to opening too many translation
files with gettext. But I would be delighted to be proven wrong, as it
would mean that the problem is fixed.

BTW, I would not be against getting rid of this cache, which was added
by Abdel because updateLabels() was too slow on windows. I think we
introduced changes later that mitigate the issue and the cache in itself
has a cost (overhead and also a couple megabytes of memory according to
massif).

JMarc
Vincent van Ravesteijn
2011-09-06 11:47:29 UTC
Permalink
Post by Jean-Marc Lasgouttes
When I was still young and naive about this problem, I suspected a cache
problem. Therefore I tried to disable completely the cache but the situation
did not change...
I really think the problem is related to opening too many translation files
with gettext. But I would be delighted to be proven wrong, as it would mean
that the problem is fixed.
Stephan, can you comment out lines 139--141 in Messages.cpp (in
Messages::get()) to see whether it helps ?

Vincent
Stephan Witt
2011-09-06 13:11:36 UTC
Permalink
When I was still young and naive about this problem, I suspected a cache problem. Therefore I tried to disable completely the cache but the situation did not change...
I really think the problem is related to opening too many translation files with gettext. But I would be delighted to be proven wrong, as it would mean that the problem is fixed.
Stephan, can you comment out lines 139--141 in Messages.cpp (in Messages::get()) to see whether it helps ?
Yes, we can. :)

But it does not help.

The following helps:

Index: src/Language.cpp
===================================================================
--- src/Language.cpp (Revision 39617)
+++ src/Language.cpp (Arbeitskopie)
@@ -187,7 +187,7 @@
// cache translation status. Calling getMessages() directly in
// PrefLanguage::PrefLanguage() did only work if the gui language
// was set to auto (otherwise all languages would be marked as available).
- translated_ = getMessages(code()).available();
+ translated_ = true ; // getMessages(code()).available();
return true;
}


... as JMarc said already.

Stephan
Vincent van Ravesteijn
2011-09-06 15:57:12 UTC
Permalink
Post by Stephan Witt
When I was still young and naive about this problem, I suspected a cache problem. Therefore I tried to disable completely the cache but the situation did not change...
I really think the problem is related to opening too many translation files with gettext. But I would be delighted to be proven wrong, as it would mean that the problem is fixed.
Stephan, can you comment out lines 139--141 in Messages.cpp (in Messages::get()) to see whether it helps ?
Yes, we can. :)
But it does not help.
Index: src/Language.cpp
===================================================================
--- src/Language.cpp (Revision 39617)
+++ src/Language.cpp (Arbeitskopie)
@@ -187,7 +187,7 @@
// cache translation status. Calling getMessages() directly in
// PrefLanguage::PrefLanguage() did only work if the gui language
// was set to auto (otherwise all languages would be marked as available).
- translated_ = getMessages(code()).available();
+ translated_ = true ; // getMessages(code()).available();
return true;
}
... as JMarc said already.
Yes, I believe JMarc. The only problem is that it feels like shooting
with a canon on a little mouse.

TBI

Vincent
Jean-Marc Lasgouttes
2011-09-06 16:59:01 UTC
Permalink
Post by Vincent van Ravesteijn
Yes, I believe JMarc. The only problem is that it feels like shooting
with a canon on a little mouse.
OTOH, this availability code itself shoots with a canon on a little mouse.

JMarc
Stephan Witt
2011-09-06 19:56:00 UTC
Permalink
Post by Stephan Witt
When I was still young and naive about this problem, I suspected a cache problem. Therefore I tried to disable completely the cache but the situation did not change...
I really think the problem is related to opening too many translation files with gettext. But I would be delighted to be proven wrong, as it would mean that the problem is fixed.
Stephan, can you comment out lines 139--141 in Messages.cpp (in Messages::get()) to see whether it helps ?
Yes, we can. :)
But it does not help.
Index: src/Language.cpp
===================================================================
--- src/Language.cpp (Revision 39617)
+++ src/Language.cpp (Arbeitskopie)
@@ -187,7 +187,7 @@
// cache translation status. Calling getMessages() directly in
// PrefLanguage::PrefLanguage() did only work if the gui language
// was set to auto (otherwise all languages would be marked as available).
- translated_ = getMessages(code()).available();
+ translated_ = true ; // getMessages(code()).available();
return true;
}
... as JMarc said already.
Yes, I believe JMarc. The only problem is that it feels like shooting with a canon on a little mouse.
Of course. It's not meant as a real fix. Only to get a feeling what direction to search further.
TBI
Traumatic brain injury?

Stephan
Stephan Witt
2011-09-06 20:22:31 UTC
Permalink
Post by Vincent van Ravesteijn
Now, this causes the translation of languageTestString() to be cached.
If we try to load all languages to see whether they are available, the
cached value is thus pretty much random.
When we call i18nLibFileSearch, we again try to translate
languageTestString() and we return the cached value.
If you remove the above test for the translation, the translation
doesn't cache the value for languageTestString() and no problems appear.
When I was still young and naive about this problem, I suspected a cache problem. Therefore I tried to disable completely the cache but the situation did not change...
I really think the problem is related to opening too many translation files with gettext. But I would be delighted to be proven wrong, as it would mean that the problem is fixed.
The man page of bind_textdomain_codeset mentions the use of iconv_open.
Did you try to avoid this function call and do the charset translation manually in the old ages?
Perhaps the loss of file descriptors is there. And the loss of speed on Windows too?

If you didn't try that I'll investigate that.

Stephan
BTW, I would not be against getting rid of this cache, which was added by Abdel because updateLabels() was too slow on windows. I think we introduced changes later that mitigate the issue and the cache in itself
has a cost (overhead and also a couple megabytes of memory according to massif).
JMarc
Vincent van Ravesteijn
2011-09-03 18:33:07 UTC
Permalink
Post by Stephan Witt
Post by Richard Heck
Perhaps a look at git log for filetools.cpp would turn something up....
I'm afraid it's a complex interaction of gettext and the use of the Messages class.
The translation of the string languageTestString() is cached, so maybe
we ask for the translation of this string before gettext is initialized
with the correct locale ?

Vincent
Vincent van Ravesteijn
2011-09-03 21:46:55 UTC
Permalink
I've been fiddling around endlessly to get the Application menu translated.. without succces.. Unfortunately LyX has the same problem.
Yes, currently I have no idea how to get it translated. A Qt thing?
I figured out some things:

First, LyX uses QLibraryInfo::location(QLibraryInfo::TranslationsPath))
to find the path to the translations of qt. For me, this pointed to
/Developer/Applications/Qt/translations. I guess you can't rely on this
when you provide Qt in your bundle. To solve, we should include all the
qt_xx.qm files from this directory in our bundle. Then you can modify
qt.conf to tell Qt where to look for the translation files.

Second, there is a MenuTranslator class in GuiApplication that is
designed to translate the LyX items in the Application menu. However,
the function translate which is defined there is not declared const and
therefore does not overload the virtual function as it should and
therefore does not work. Declaring this function as const solves this.

If we don't want to include all those qt translations, we can also make
sure we have all the translations in our own translation files.

I can't get LyX to get translated when I compile it myself, so could you
try the above.

Vincent
Stephan Witt
2011-09-04 11:28:42 UTC
Permalink
I've been fiddling around endlessly to get the Application menu translated.. without succces.. Unfortunately LyX has the same problem.
Yes, currently I have no idea how to get it translated. A Qt thing?
First, LyX uses QLibraryInfo::location(QLibraryInfo::TranslationsPath)) to find the path to the translations of qt. For me, this pointed to /Developer/Applications/Qt/translations. I guess you can't rely on this when you provide Qt in your bundle. To solve, we should include all the qt_xx.qm files from this directory in our bundle. Then you can modify qt.conf to tell Qt where to look for the translation files.
Second, there is a MenuTranslator class in GuiApplication that is designed to translate the LyX items in the Application menu. However, the function translate which is defined there is not declared const and therefore does not overload the virtual function as it should and therefore does not work. Declaring this function as const solves this.
If we don't want to include all those qt translations, we can also make sure we have all the translations in our own translation files.
I can't get LyX to get translated when I compile it myself, so could you try the above.
Cool! Basically it works. Translation of our own menu item(s) is missing though.
I'll do some investigation later.

Stephan
Uwe Stöhr
2011-09-05 15:28:36 UTC
Permalink
Post by Vincent van Ravesteijn
Can you send me a link to this installer. I want to test it.
https://developer.berlios.de/project/showfiles.php?group_id=5117&release_id=18767

regards Uwe
Vincent van Ravesteijn
2011-09-05 18:43:43 UTC
Permalink
Post by Uwe Stöhr
Post by Vincent van Ravesteijn
Can you send me a link to this installer. I want to test it.
https://developer.berlios.de/project/showfiles.php?group_id=5117&release_id=18767
regards Uwe
Hi Uwe,


I tried the merged installer. Here is some feedback:

1. The icon is not the nicest one. We should have a transparent one.

2. I agree with Joost that the dialog to choose the start menu folder is
not necessary anymore. It is not useful having only a single item in a map.

3. The start menu folder is called "LyX 2.0.1". I don't like the version
number in the name, there is no need for it.

4. In the MikTeX page is a spelling error in the dutch translation:
LaTeX softare. Also in the MikTeX update page.

5. Why do we install the MikTeX packages without asking the user for
permission? I determine whether I want to install tons of MikTeX
packages or not and ,moreover, I have set the setting of MikTex to
always ask before installing a package. LyX just overrides this. I don't
accept this.

6. Joost had a reason to not allow to start the application from the
installer. Isn't this a problem now anymore ?

7. Joost's LyX2.0 installer installed the folder AppData/Roaming/LyX2.0.
Can we please have the same directory for newer installers instead of
lyx20 ?

8. Joost's LyX2.0 installer installed in the folder Program Files/LyX20.
The merged installer in Program Files/LyX 2.0.1. Can we please have the
same directory for newer installers? Preferably without all the version
numbers.

9. I found the following faulty registry entries. Where do they come from ?

HKEY_CLASSES_ROOT\LyX.Document\Shell\open\command
"C:\Program Files (x86)\LyX 2.0.1\bin\LyXLauncher.exe" "%1"

HKEY_CLASSES_ROOT\LyX.Document\DefaultIcon
C:\Program Files (x86)\LyX 2.0.1\bin\LyXLauncher.exe,0

HKEY_CLASSES_ROOT\Applications
C:\Program Files (x86)\LyX 2.0.1\imagemagick\convert.exe $

10. Now, I have both LyX2.0.0 and LyX2.0.1 installed on my pc ?
Shouldn't we overwrite the previous version ?

Vincent
Uwe Stöhr
2011-09-06 04:03:10 UTC
Permalink
Post by Vincent van Ravesteijn
I tried the merged installer.
Many thanks!
Post by Vincent van Ravesteijn
1. The icon is not the nicest one. We should have a transparent one.
What icon do you mean? The installer uses the icon of the lyx.exe file. If you want another icon, we
must change the build code to link it to the lyx.exe.
Post by Vincent van Ravesteijn
2. I agree with Joost that the dialog to choose the start menu folder is not necessary anymore. It
is not useful having only a single item in a map.
People requested to choose the start menu folder and almost all installers I know provide this
feature. There is also only one programs on my PC (Inkscape) that is not following the Windows
guideline to have its own folder in the start menu.
This is also necessary to distinguish between different LyX versions. For example I have LyX 1.4.5,
1.5.7, 1.6.10. 2.0.1 and 2.1.0svn installed. Without a folder for each program, I would have 5
entries with the same name "LyX".
(Initially in the LyX folder there was also the link to uninstall LyX but Joost were opposed to
this, so I dropped it.)
Post by Vincent van Ravesteijn
3. The start menu folder is called "LyX 2.0.1". I don't like the version number in the name, there
is no need for it.
We need the version number to distinguish between different versions. Many users I know are still
using LyX 1.6.x side by side to LyX 2.0.x in case there are regression bugs in LyX 2.0.x. For the
same reason we got reports that users even do this for a stable LyX series. So the might have LyX
2.0.0 _and_ 2.0.1 installed.
Post by Vincent van Ravesteijn
4. In the MikTeX page is a spelling error in the dutch translation: LaTeX softare. Also in the
MikTeX update page.
Thanks, fixed now.
Post by Vincent van Ravesteijn
5. Why do we install the MikTeX packages without asking the user for permission?
Because new user cannot know what a package is and what is it about. Their cryptic names are also
meaningless, even if you know some basics about LaTeX.
We can also not let new users about 50 times read popup dialog with lots of information that are
cryptic and he should decide what to do. We therefore install all available packages that are needed
by LyX. This way the user is not bothered and he gets a full functional LyX. The installation
progress is made visible in the installer.

This is one of the key features of the installer!
Post by Vincent van Ravesteijn
I determine whether
I want to install tons of MikTeX packages or not and ,moreover, I have set the setting of MikTex to
always ask before installing a package. LyX just overrides this. I don't accept this.
You can reset the settings any time.
Post by Vincent van Ravesteijn
6. Joost had a reason to not allow to start the application from the installer. Isn't this a problem
now anymore ?
I don't know what you are referring to.
Post by Vincent van Ravesteijn
7. Joost's LyX2.0 installer installed the folder AppData/Roaming/LyX2.0. Can we please have the same
directory for newer installers instead of lyx20 ?
What do you mean? LyX's settings folder is on my PC
C:\Documents and Settings\Uwe\Application Data\lyx20

All LyX 2.0.x releases share the same folder. The 1.6.x series uses the folder "lyx16". What is
wrong with that?
I don't know why Joost's installer creates a folder "LyX2.0" instead of "lyx20". For me this folder
is created automatically when LyX.exe is called the first time. So he must be using a special
compilation setting.
Post by Vincent van Ravesteijn
8. Joost's LyX2.0 installer installed in the folder Program Files/LyX20. The merged installer in
Program Files/LyX 2.0.1. Can we please have the same directory for newer installers? Preferably
without all the version numbers.
This is not possible, because how would yo then distinguish between the different installations? You
can have LyX 1.6.4 installed besides 1.6.10. And we have user who are actually using this as I
stated above. (I did the same when I wrote my thesis.)
Post by Vincent van Ravesteijn
9. I found the following faulty registry entries. Where do they come from ?
HKEY_CLASSES_ROOT\LyX.Document\Shell\open\command
"C:\Program Files (x86)\LyX 2.0.1\bin\LyXLauncher.exe" "%1"
HKEY_CLASSES_ROOT\LyX.Document\DefaultIcon
C:\Program Files (x86)\LyX 2.0.1\bin\LyXLauncher.exe,0
LyXLauncher is the executable that hides LyX's console Window. Joost doesn't need this anymore since
he found a way to compile LyX without its console window. But I was not able to do the same. No
matter if I compile with SCons or CMake, I always get a lyx.exe that comes with a console window.
Post by Vincent van Ravesteijn
HKEY_CLASSES_ROOT\Applications
C:\Program Files (x86)\LyX 2.0.1\imagemagick\convert.exe $
This is ImageMagick's converter executable. This entry is set by ImageMagick.
Post by Vincent van Ravesteijn
10. Now, I have both LyX2.0.0 and LyX2.0.1 installed on my pc ? Shouldn't we overwrite the previous
version ?
No. See the reasons above.

thanks and regards
Uwe
Liviu Andronic
2011-09-06 06:35:53 UTC
Permalink
Post by Uwe Stöhr
Post by Vincent van Ravesteijn
6. Joost had a reason to not allow to start the application from the
installer. Isn't this a problem
now anymore ?
I don't know what you are referring to.
This has been discussed earlier on the list. Now the last page of the
installer (before hitting 'finish') no longer offers the user to
launch LyX because of admin privileges. If the user launched LyX from
within the installer, with admin privileges, then all her customised
settings would be lost upon LyX restart, which would use normal
privileges.

Regards
Liviu
Uwe Stöhr
2011-09-07 14:18:30 UTC
Permalink
Post by Liviu Andronic
Post by Uwe Stöhr
Post by Vincent van Ravesteijn
6. Joost had a reason to not allow to start the application from the
installer. Isn't this a problem
now anymore ?
I don't know what you are referring to.
This has been discussed earlier on the list. Now the last page of the
installer (before hitting 'finish') no longer offers the user to
launch LyX because of admin privileges.
No, Joost did not provide the feature of starting LyX at the end of the installation while I enabled
this option by default. We came to the conclusion to use a "way in the middle", so provide an option
to start Lyx after the installation as almost all installers I know do, but to disable this option
by default to allow batch installations. So now the last installer page has this option. If you
like, you can turn it on.
Post by Liviu Andronic
If the user launched LyX from
within the installer, with admin privileges, then all her customised
settings would be lost upon LyX restart, which would use normal
privileges.
This is not true. The user settings are stored in a folder for every user of the PC. If you did not
delete the user settings in the previous uninstallation, they are not touched. I just checked this.

regards Uwe
Vincent van Ravesteijn
2011-09-06 08:30:23 UTC
Permalink
Post by Vincent van Ravesteijn
I tried the merged installer.
Many thanks!
Post by Vincent van Ravesteijn
1. The icon is not the nicest one. We should have a transparent one.
What icon do you mean? The installer uses the icon of the lyx.exe file. If
you want another icon, we must change the build code to link it to the
lyx.exe.
I see one in my taskbar with a dark-blue background, but it appears as an
ugly square.
Post by Vincent van Ravesteijn
2. I agree with Joost that the dialog to choose the start menu folder is
Post by Vincent van Ravesteijn
not necessary anymore. It
is not useful having only a single item in a map.
People requested to choose the start menu folder and almost all installers
I know provide this feature.
IMO it is useless. Why would one not want to have LyX in a directory
called... "LyX" ?

Maybe people requested this because they don't like the default LyX 2.0.0,
LyX 2.0.1 and so forth.
Post by Vincent van Ravesteijn
There is also only one programs on my PC (Inkscape) that is not following
the Windows guideline to have its own folder in the start menu.
Joost was citing a completely different Windows guideline.
Post by Vincent van Ravesteijn
This is also necessary to distinguish between different LyX versions. For
example I have LyX 1.4.5, 1.5.7, 1.6.10. 2.0.1 and 2.1.0svn installed.
Without a folder for each program, I would have 5 entries with the same name
"LyX".
The entry in the start menu is "LyX 2.0", so no confusion here.
Post by Vincent van Ravesteijn
(Initially in the LyX folder there was also the link to uninstall LyX but
Joost were opposed to this, so I dropped it.)
Yes, you uninstall programs using the Control Panel->Add or Remove
Programs.
Post by Vincent van Ravesteijn
3. The start menu folder is called "LyX 2.0.1". I don't like the version
Post by Vincent van Ravesteijn
number in the name, there
is no need for it.
We need the version number to distinguish between different versions. Many
users I know are still using LyX 1.6.x side by side to LyX 2.0.x in case
there are regression bugs in LyX 2.0.x. For the same reason we got reports
that users even do this for a stable LyX series. So the might have LyX 2.0.0
_and_ 2.0.1 installed.
I'm sorry, but we are not going to bother _every_ user because some
exceptional person wants to have LyX2.0.1 and LyX2.0.2 installed next to
each other. I can't think of a reason to do so. If a newer version is worse,
then you can just install the older one again.
Post by Vincent van Ravesteijn
Post by Vincent van Ravesteijn
5. Why do we install the MikTeX packages without asking the user for permission?
Because new user cannot know what a package is and what is it about. Their
cryptic names are also meaningless, even if you know some basics about
LaTeX.
We can also not let new users about 50 times read popup dialog with lots of
information that are cryptic and he should decide what to do. We therefore
install all available packages that are needed by LyX. This way the user is
not bothered and he gets a full functional LyX. The installation progress is
made visible in the installer.
It takes toooooooooooo much time. That's why I set the preference in MikTeX
to not automatically install packages, but the LyX installer just overrides
it. I'm the boss of my pc, not the LyX installer.

Why is the installer only targeted for new users that have no idea what
LaTeX is ? I think most users are not new users. What is wrong with having a
question, "Do you want to automatically install all LaTeX packages of the
MikTeX distribution ?" which defaults to yes. If a user does not know what a
LaTeX package is, he can just click ok.

Now, we're overruling the decision of the expert users. This is an often
heard critique about LyX that it thinks it knows better than the user. This
is a typical case.
Post by Vincent van Ravesteijn
This is one of the key features of the installer!
I hate it.
Post by Vincent van Ravesteijn
6. Joost had a reason to not allow to start the application from the
Post by Vincent van Ravesteijn
installer. Isn't this a problem
now anymore ?
I don't know what you are referring to.
Last page: "Launch LyX". We've discussed this more than once.
Post by Vincent van Ravesteijn
7. Joost's LyX2.0 installer installed the folder AppData/Roaming/LyX2.0.
Post by Vincent van Ravesteijn
Can we please have the same
directory for newer installers instead of lyx20 ?
What do you mean? LyX's settings folder is on my PC
C:\Documents and Settings\Uwe\Application Data\lyx20
What do I mean ? Are you sure you don't know ?
Post by Vincent van Ravesteijn
All LyX 2.0.x releases share the same folder. The 1.6.x series uses the
folder "lyx16". What is wrong with that?
I don't know why Joost's installer creates a folder "LyX2.0" instead of
"lyx20". For me this folder is created automatically when LyX.exe is called
the first time. So he must be using a special compilation setting.
I won't accept any installer for the LyX 2.0 series that is not compatible
with a previous one. I installed a custom layout into the LyX2.0 directory
and now I have to manually move it into the lyx20 directory. This is
unacceptable.
Post by Vincent van Ravesteijn
8. Joost's LyX2.0 installer installed in the folder Program Files/LyX20.
Post by Vincent van Ravesteijn
The merged installer in
Program Files/LyX 2.0.1. Can we please have the same directory for newer
installers? Preferably
without all the version numbers.
This is not possible, because how would yo then distinguish between the
different installations? You can have LyX 1.6.4 installed besides 1.6.10.
And we have user who are actually using this as I stated above. (I did the
same when I wrote my thesis.)
Then these users will be disappointed. I can't think of ANY reason to have
two different minor versions of LyX installed on your machine and expect the
installer to adjust all the defaults to this. The user can change the
directory into which he wants to install LyX if he desperately wants to have
more than one installation.
Post by Vincent van Ravesteijn
9. I found the following faulty registry entries. Where do they come from ?
Post by Vincent van Ravesteijn
HKEY_CLASSES_ROOT\LyX.**Document\Shell\open\command
"C:\Program Files (x86)\LyX 2.0.1\bin\LyXLauncher.exe" "%1"
HKEY_CLASSES_ROOT\LyX.**Document\DefaultIcon
C:\Program Files (x86)\LyX 2.0.1\bin\LyXLauncher.exe,0
LyXLauncher is the executable that hides LyX's console Window. Joost
doesn't need this anymore since he found a way to compile LyX without its
console window. But I was not able to do the same. No matter if I compile
with SCons or CMake, I always get a lyx.exe that comes with a console
window.
I don't understand. We discussed this and we clearly agreed that LyXLauncher
was history. Now you suddenly are still using it, showing the same bugs as I
reported previously.

You can simply get rid of the console by setting the MSVC project
properties LyX -> Configuration Properties -> System -> SubSystem ->
Windows.
Post by Vincent van Ravesteijn
HKEY_CLASSES_ROOT\Applications
Post by Vincent van Ravesteijn
C:\Program Files (x86)\LyX 2.0.1\imagemagick\convert.exe $
This is ImageMagick's converter executable. This entry is set by ImageMagick.
Please don't tell me this is the ImageMagick's converter executable. I
could have figured that out myself.

The problem is that:
a) it is the wrong key: Applications is a folder, not a key itself (if
there is a difference).
b) Why doesn't Joost's installer set this if it is set by ImageMagick
itself ?
Post by Vincent van Ravesteijn
10. Now, I have both LyX2.0.0 and LyX2.0.1 installed on my pc ? Shouldn't
Post by Vincent van Ravesteijn
we overwrite the previous
version ?
No. See the reasons above.
I totally do not agree with these reasons. Because a few people might want
to use multiple minor releases, ALL users have to manually uninstall
LyX2.0.0 after installing LyX2.0.1, manually uninstall LyX2.0.1 after
installing LyX2.0.2, etc.

What happens to the user directory called LyX2.0 or lyx20. Does it persist
after uninstalling ? If so, apparently we do not clean up our mess while
uninstalling. We should do that. If not, the user lost all his settings. Or
will there be a question what to do with the risk of pressing the wrong
button.

This price is way too high for users that just upgrade from 2.0.0 to 2.0.1.

Vincent
Vincent van Ravesteijn
2011-09-06 18:17:53 UTC
Permalink
Post by Vincent van Ravesteijn
10. Now, I have both LyX2.0.0 and LyX2.0.1 installed on my pc
? Shouldn't we overwrite the previous
version ?
No. See the reasons above.
I totally do not agree with these reasons. Because a few people might
want to use multiple minor releases, ALL users have to manually
uninstall LyX2.0.0 after installing LyX2.0.1, manually uninstall
LyX2.0.1 after installing LyX2.0.2, etc.
What happens to the user directory called LyX2.0 or lyx20. Does it
persist after uninstalling ? If so, apparently we do not clean up our
mess while uninstalling. We should do that. If not, the user lost all
his settings. Or will there be a question what to do with the risk of
pressing the wrong button.
This price is way too high for users that just upgrade from 2.0.0 to 2.0.1.
Now I uninstalled LyX2.0.1 (because I also wanted to test the
uninstaller). Now my .lyx files can't be opened by double-click and they
don't have the lyx logo anymore. So, the user should even uninstall the
previous version before installing the new one. If he does it the
otherway around the installation is broken.

Vincent
Uwe Stöhr
2011-09-21 21:21:47 UTC
Permalink
Now I uninstalled LyX2.0.1 (because I also wanted to test the uninstaller). Now my .lyx files can't
be opened by double-click and they don't have the lyx logo anymore.
Sure, because you decided to uninstall LyX. We must therefore delete all registry entries of LyX,
including the file extensions. That is the common rule for an uninstaller. (If you uninstall Word or
OpenOffice, *.doc files also loose their icons and the open statement in the registry.)
So, the user should even
uninstall the previous version before installing the new one. If he does it the otherway around the
installation is broken.
Sure, either you keep a version and install a new version or uninstall it before installing the new
version.
In general, if you uninstall a program, you cannot expect that registry entries are kept - that
would oppose the idea of uninstalling. This concept is the same for all other programs I know.

regards Uwe

Uwe Stöhr
2011-09-07 16:02:16 UTC
Permalink
Post by Vincent van Ravesteijn
Post by Uwe Stöhr
Post by Vincent van Ravesteijn
1. The icon is not the nicest one. We should have a transparent one.
What icon do you mean? The installer uses the icon of the lyx.exe file. If
you want another icon, we must change the build code to link it to the
lyx.exe.
I see one in my taskbar with a dark-blue background, but it appears as an
ugly square.
On my Win 7 and also at my Win XP machine, I see in the taskbar the same icon as in the upper left
corner of LyX's main window - the one with the blue L, the yellow y and the red X. Its background is
that of the taskbar, so it is transparent.

Ah, OK now I see that you are referring to the icon of the installer. I used the old version of the
icon in my build tree. The one in SVN is the correct one.
Post by Vincent van Ravesteijn
Post by Uwe Stöhr
2. I agree with Joost that the dialog to choose the start menu folder is
Post by Vincent van Ravesteijn
not necessary anymore. It
is not useful having only a single item in a map.
People requested to choose the start menu folder and almost all installers
I know provide this feature.
IMO it is useless. Why would one not want to have LyX in a directory
called... "LyX" ?
Some users have there own sectioning scheme. For example all graphic programs go to the folder
"graphics", text editors and word processors go to "text". Our installer is proposing the default
location in the base tree: "~\LyX 2.0.1" but user might want to have it in "~\text\LyX 2.0.1"
This can also be done in the start menu selection page.
Post by Vincent van Ravesteijn
Maybe people requested this because they don't like the default LyX 2.0.0,
LyX 2.0.1 and so forth.
I can't remember. The version number is important if you have several LyX versions installed. If you
don't like it, yes you can remove it. So this is one application of the start menu choosing feature.
Post by Vincent van Ravesteijn
Post by Uwe Stöhr
There is also only one programs on my PC (Inkscape) that is not following
the Windows guideline to have its own folder in the start menu.
Joost was citing a completely different Windows guideline.
I know and he is right, this is indeed the official guideline, I don't know a program following
this. I think the reason is that you would loose the overview if there are 200 programs with their
icons in one folder. On Win 7 this would not be problem as the start menu is different, but on Win
XP this would be a nightmare.
Therefore all programs I know is putting their programs in its own subfolder, which makes it also
easier for the users to group the programs customly as I described above.
Post by Vincent van Ravesteijn
Post by Uwe Stöhr
This is also necessary to distinguish between different LyX versions. For
example I have LyX 1.4.5, 1.5.7, 1.6.10. 2.0.1 and 2.1.0svn installed.
Without a folder for each program, I would have 5 entries with the same name
"LyX".
The entry in the start menu is "LyX 2.0", so no confusion here.
How would you distinguish between LyX 2.0.0 and 2.0.1 then? Having several LyX versions installed is
useful in some cases and I don't see a reason why we should no longer support this.
Post by Vincent van Ravesteijn
Post by Uwe Stöhr
3. The start menu folder is called "LyX 2.0.1". I don't like the version
Post by Vincent van Ravesteijn
number in the name, there
is no need for it.
We need the version number to distinguish between different versions. Many
users I know are still using LyX 1.6.x side by side to LyX 2.0.x in case
there are regression bugs in LyX 2.0.x. For the same reason we got reports
that users even do this for a stable LyX series. So the might have LyX 2.0.0
_and_ 2.0.1 installed.
I'm sorry, but we are not going to bother _every_ user because some
exceptional person wants to have LyX2.0.1 and LyX2.0.2 installed next to
each other. I can't think of a reason to do so. If a newer version is worse,
then you can just install the older one again.
If you are writing an important document like a thesis that requires months of work, you want a
version of LyX that works. So if you started with LyX 1.6.3 you want to keep this as fallback if
there is a regression in later releases. I did this for my thesis and some of my colleagues too.
In the past we had the case that we accidentally introduced regressions in bugfix releases. We are
all humans and this will occur for sure also in the future.
So why should we no longer support if users want to stay super safe?

All in all your complaint is about "LyX 2.0" in Joost's installer while I use "LyX 2.0.1". Why is
the additional ".1" so important for you?

I have to go now, more in another mail.

regards Uwe
Uwe Stöhr
2011-09-21 21:15:55 UTC
Permalink
Post by Vincent van Ravesteijn
Post by Uwe Stöhr
Post by Vincent van Ravesteijn
5. Why do we install the MikTeX packages without asking the user for permission?
Because new user cannot know what a package is and what is it about. Their
cryptic names are also meaningless, even if you know some basics about
LaTeX.
We can also not let new users about 50 times read popup dialog with lots of
information that are cryptic and he should decide what to do. We therefore
install all available packages that are needed by LyX. This way the user is
not bothered and he gets a full functional LyX. The installation progress is
made visible in the installer.
It takes toooooooooooo much time. That's why I set the preference in MikTeX
to not automatically install packages, but the LyX installer just overrides
it. I'm the boss of my pc, not the LyX installer.
For the installer, we need to treat the users as if they were customers. Assume you pay some money
to get a full functional version of a program. As you paid some money, you can expect that your copy
is really fully functional. Moreover when you are starting with a new program you simply need a
fully functional version to continue reading its tutorial, playing a bit with it and its example
files, having a look what it can do with math, tables, footnotes, etc.

It is therefore extremely important to install all packages LyX is supporting/requiring. This takes
some time for new installations, but for all further installations not, as no new packages need to
be installed. Switching MikTeX to install on the fly is necessary because it takes usually some time
until new users understand the system of packages and what they are for. we cannot bother them with
cryptic questions for more than 50 packages to install.
Post by Vincent van Ravesteijn
Why is the installer only targeted for new users that have no idea what
LaTeX is ?
The complete installer variant is designed for this. The small version expects an already installed
LaTeX (not necessarily MikTeX). So in case LateX is already there, there will no new packages
installed as they are already there - experienced users won't suffer from the lengthy package
installation cycle.
Post by Vincent van Ravesteijn
I think most users are not new users. What is wrong with having a
question, "Do you want to automatically install all LaTeX packages of the
MikTeX distribution ?" which defaults to yes. If a user does not know what a
LaTeX package is, he can just click ok.
I can implement this for the small variant, for the complete variant I try to keep the installer as
automatic as possible preventing any question that is not necessary to get a full functional LyX.
OK?
Post by Vincent van Ravesteijn
Now, we're overruling the decision of the expert users. This is an often
heard critique about LyX that it thinks it knows better than the user. This
is a typical case.
It is new to me that people are complaining about this. (I heard this the first time in this
thread.) You can any time reset MiKTeX's settings if you like. You only need the installer once,
after the installation, experienced users will set their special things nevertheless.( Note that
installing packages is also the default setting of MiKTeX if you install it separately so there it
not a fault to use the default.)
Post by Vincent van Ravesteijn
Post by Uwe Stöhr
6. Joost had a reason to not allow to start the application from the
Post by Vincent van Ravesteijn
installer. Isn't this a problem
now anymore ?
I don't know what you are referring to.
Last page: "Launch LyX". We've discussed this more than once.
I already discussed this point with Joost and the consensus was to provide this option but disable
it by default - and that is what I implemented.
Post by Vincent van Ravesteijn
Post by Uwe Stöhr
7. Joost's LyX2.0 installer installed the folder AppData/Roaming/LyX2.0.
Post by Vincent van Ravesteijn
Can we please have the same
directory for newer installers instead of lyx20 ?
What do you mean? LyX's settings folder is on my PC
C:\Documents and Settings\Uwe\Application Data\lyx20
What do I mean ? Are you sure you don't know ?
You are confusing me. The name of LyX's settings folders is set at compilation time into the
lyx.exe. When I compile LyX via SCons or CMake and start the resulting lyx.exe, LyX is creating a
folder named "lyx20". So it seems that Joost is using its own compilation flags.
The installer is not to blame here.
Post by Vincent van Ravesteijn
Post by Uwe Stöhr
All LyX 2.0.x releases share the same folder. The 1.6.x series uses the
folder "lyx16". What is wrong with that?
I don't know why Joost's installer creates a folder "LyX2.0" instead of
"lyx20". For me this folder is created automatically when LyX.exe is called
the first time. So he must be using a special compilation setting.
I won't accept any installer for the LyX 2.0 series that is not compatible
with a previous one. I installed a custom layout into the LyX2.0 directory
and now I have to manually move it into the lyx20 directory. This is
unacceptable.
This is indeed not nice, but what should I do? This is not installer business, but a compiler flag
and I compile using the official sources. Please help what I need to change to get the folder name
changed.
Post by Vincent van Ravesteijn
Post by Uwe Stöhr
8. Joost's LyX2.0 installer installed in the folder Program Files/LyX20.
Post by Vincent van Ravesteijn
The merged installer in
Program Files/LyX 2.0.1. Can we please have the same directory for newer
installers? Preferably
without all the version numbers.
This is not possible, because how would yo then distinguish between the
different installations? You can have LyX 1.6.4 installed besides 1.6.10.
And we have user who are actually using this as I stated above. (I did the
same when I wrote my thesis.)
Then these users will be disappointed. I can't think of ANY reason to have
two different minor versions of LyX installed on your machine and expect the
installer to adjust all the defaults to this.
I already gave you some examples. Again the main reason: When writing really important things that
take some months, you want to assure that your document is compilable. So for example for my thesis
I started with LyX 1.6.1. I updated LyX 1.6 from time to time, but to be safe I of course kept the
versions of LyX that I found stable in all areas in compiling my thesis. Thus, finally I had 1.6.4
and 1.6.7. This was a wise decision, because LyX is not perfect and we sometime introduced
regressions in the bugfix releases. I remember such a case where LyX crashed with the recent version
of LyX 1.6.x while it worked for the previous one. (We had such a case by a whisker also in LyX
2.0.1, see bug 7731).

So why should I no longer be allowed to install several LyX versions side by side. I do this since
ever and it worked without problems. i also know some users and colleagues doing the same.
Post by Vincent van Ravesteijn
The user can change the
directory into which he wants to install LyX if he desperately wants to have
more than one installation.
You can do this already if you prefer "LyX 2.0" instead of "LyX 2.0.x".
Post by Vincent van Ravesteijn
Post by Uwe Stöhr
9. I found the following faulty registry entries. Where do they come from ?
Post by Vincent van Ravesteijn
HKEY_CLASSES_ROOT\LyX.**Document\Shell\open\command
"C:\Program Files (x86)\LyX 2.0.1\bin\LyXLauncher.exe" "%1"
HKEY_CLASSES_ROOT\LyX.**Document\DefaultIcon
C:\Program Files (x86)\LyX 2.0.1\bin\LyXLauncher.exe,0
LyXLauncher is the executable that hides LyX's console Window. Joost
doesn't need this anymore since he found a way to compile LyX without its
console window. But I was not able to do the same. No matter if I compile
with SCons or CMake, I always get a lyx.exe that comes with a console
window.
I don't understand. We discussed this and we clearly agreed that LyXLauncher
was history. Now you suddenly are still using it, showing the same bugs as I
reported previously.
I also would like to get rid of it, but it doesn't work for me. When I compile LyX from SVN; I
always get a lyx.exe that opens a console windows. What am i doing wrong?

Please send me a lyx.exe without this console window and I can get rid of it. If you are able to
compile such a version, can you please teach me what I need to do to get it too
Post by Vincent van Ravesteijn
You can simply get rid of the console by setting the MSVC project
properties LyX -> Configuration Properties -> System -> SubSystem ->
Windows.
Post by Uwe Stöhr
HKEY_CLASSES_ROOT\Applications
Post by Vincent van Ravesteijn
C:\Program Files (x86)\LyX 2.0.1\imagemagick\convert.exe $
This is ImageMagick's converter executable. This entry is set by ImageMagick.
Please don't tell me this is the ImageMagick's converter executable. I
could have figured that out myself.
Why are you so aggressive? I answered your question to my best knowledge.
Post by Vincent van Ravesteijn
a) it is the wrong key: Applications is a folder, not a key itself (if
there is a difference).
Blame Imagemagick, not me. You can test out by installing ImageMagick as standalone version and you
will get this entry.
Post by Vincent van Ravesteijn
b) Why doesn't Joost's installer set this if it is set by ImageMagick
itself ?
Because Joost is compiling his own version he did a lot of changes to get ImageMagick working if it
is installed without admin priviledges. Thus he had to change IM's registry settings.
I don't think that this is a real solution as only Joost can now provide IM versions for the
installer, but the goal was that more than nly one person is able to build our installer. Moreover,
IM releases very frequently, sometimes each week a new version due to reported memory leaks etc. I
therefore think we should encourage the IM developers to change their program to work also without
admin priviledges. The change to achieve this is quite simple, so I don' understand why Joost is not
contacting them and requesting this. I will now start an initiative of my own and report back.
Post by Vincent van Ravesteijn
Post by Uwe Stöhr
10. Now, I have both LyX2.0.0 and LyX2.0.1 installed on my pc ? Shouldn't
Post by Vincent van Ravesteijn
we overwrite the previous
version ?
No. See the reasons above.
I totally do not agree with these reasons. Because a few people might want
to use multiple minor releases, ALL users have to manually uninstall
LyX2.0.0 after installing LyX2.0.1, manually uninstall LyX2.0.1 after
installing LyX2.0.2, etc.
That is not true. You can already uninstall LyX 2.0.0 before the installation of LyX 2.0.1 and keep
the settings of LyX 2.0.0. As in my former altinstaller, I plan to add the option to override
existing LyX installations. (the feature of my former update installer variant). But before doing
this, I want to sort the other issues out. So step by step.
Post by Vincent van Ravesteijn
What happens to the user directory called LyX2.0 or lyx20. Does it persist
after uninstalling ?
If you choose the uninstaller option to keep the settings, then this folder is kept, otherwise it is
erased. So it is up to you.
Post by Vincent van Ravesteijn
This price is way too high for users that just upgrade from 2.0.0 to 2.0.1.
I never said that the installer is feature complete and even requested Joost to provide his
installer again for LyX 2.0.1 as the official one, see my posts on the list in the 2.0.ö1 release
thread.

regards Uwe
Pavel Sanda
2011-09-05 17:54:49 UTC
Permalink
Post by Uwe Stöhr
Works fine and a Win installer is ready (the merged one). I'll leave the
installer for LyX 2.0.1 to Joost because the merged installer is not yet
able to install LyX if you install it without admin privileges (due to a
Imagemagick issue).
is this regression wrt 2.0.0 installer? if not why wait...
pavel
Uwe Stöhr
2011-09-06 03:32:56 UTC
Permalink
Post by Pavel Sanda
Post by Uwe Stöhr
Works fine and a Win installer is ready (the merged one). I'll leave the
installer for LyX 2.0.1 to Joost because the merged installer is not yet
able to install LyX if you install it without admin privileges (due to a
Imagemagick issue).
is this regression wrt 2.0.0 installer? if not why wait...
Yes, Joost's installer is able to install LyX without admin priviledges. To achieve this, he use
special compiled version of ImageMagick. This is not a suitable solution because we should rely on
official releases. Moreover ImageMagick releases very often and our goal was that more than one
developer is able to build the Win installer. Therefore we should concentrate on the LyX stuff and
use the official releases.
The next time I find time, I'll work on the remaining ImageMagick issue. The problem is that
ImageMagick requires a registry entry in HKLM but this can only be set with admin priviledges.

Besides this, the new installer was not yet tested by users.

regards Uwe
Pavel Sanda
2011-09-06 09:46:13 UTC
Permalink
Post by Uwe Stöhr
Post by Pavel Sanda
Post by Uwe Stöhr
Works fine and a Win installer is ready (the merged one). I'll leave the
installer for LyX 2.0.1 to Joost because the merged installer is not yet
able to install LyX if you install it without admin privileges (due to a
Imagemagick issue).
is this regression wrt 2.0.0 installer? if not why wait...
Yes, Joost's installer is able to install LyX without admin priviledges. To
i see i'm completely lost what is meant by 'merged' and Joost installer :)
it looked some time back we have only one.
pavel
Tommaso Cucinotta
2011-09-02 01:09:44 UTC
Permalink
Post by Richard Heck
http://frege.brown.edu/lyx/lyx-2.0.1.tar.gz
I only got this warning while compiling:

Server.cpp: In member function ‘bool
lyx::LyXComm::loadFilesInOtherInstance()’:
Server.cpp:1018:45: warning: ignoring return value of ‘ssize_t
write(int, const void*, size_t)’, declared with attribute warn_unused_result

Then, when starting and opening EmbeddedObjects or Math, tons of these
messages on the console:
latex had problems compiling 0lyxpreview.tex
latex had problems compiling 0lyxpreview_legacy.tex
This is dvips(k) 5.98 Copyright 2009 Radical Eye Software
(www.radicaleye.com)
' TeX output 2011.09.02:0305' -> 0lyxpreview_legacy.ps
(-> 0lyxpreview_legacy.001) </usr/share/texmf-texlive/dvips/base/tex.pro>
...
(-> 0lyxpreview_legacy.030) </usr/share/texmf-texlive/dvips/base/tex.pro>
</usr/share/texmf/fonts/enc/dvips/cm-super/cm-super-t1.enc>
</usr/share/texmf-texlive/dvips/base/texps.pro>

and of these:
GPL Ghostscript 9.01: Unrecoverable error, exit code 1
GPL Ghostscript 9.01: Unrecoverable error, exit code 1

My system:
-) Ubuntu 11.04 64bit
-) gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2
-) configure options: --prefix=/usr/local/lyx-2.0.1

Bye,

T.
Tommaso Cucinotta
2011-09-02 01:16:04 UTC
Permalink
Something more serious:

-) start LyX
-) open Advanced F&R
-) close LyX

-) start LyX (Advanced F&R is already there)
-) type C-m (math mode), then x, then left-cursor (try once, twice,
thrice left cursor)
-) type C-q (quit)

and we get SEGFAULT!

Seems to crash both with instant preview on and off, but AFAICR there
was a similar bug related to instant preview that was supposed to have
been fixed (find below details including the ones about my system).

(gdb) run
Starting program: /home/tommaso/lyx-trunk-ws/lyx-2.0.1/src/lyx
[Thread debugging using libthread_db enabled]
[New Thread 0x7fffef899700 (LWP 463)]
[New Thread 0x7fffe3f4b700 (LWP 464)]

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff5c59378 in std::basic_string<char, std::char_traits<char>,
std::allocator<char> >::basic_string(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&) () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) bt
#0 0x00007ffff5c59378 in std::basic_string<char,
std::char_traits<char>, std::allocator<char>
::basic_string(std::basic_string<char, std::char_traits<char>,
std::allocator<char> > const&) () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1 0x0000000000a116bd in lyx::support::FileName::absFileName() const ()
#2 0x0000000000a142bf in lyx::support::operator<(lyx::support::FileName
const&, lyx::support::FileName const&) ()
#3 0x00000000009f1141 in std::_Rb_tree<lyx::support::FileName,
std::pair<lyx::support::FileName const,
std::tr1::shared_ptr<lyx::graphics::CacheItem> >,
std::_Select1st<std::pair<lyx::support::FileName const,
std::tr1::shared_ptr<lyx::graphics::CacheItem> > >,
std::less<lyx::support::FileName>,
std::allocator<std::pair<lyx::support::FileName const,
std::tr1::shared_ptr<lyx::graphics::CacheItem> > > >::_M_lower_bound ()
#4 0x00000000009f1e69 in std::_Rb_tree<lyx::support::FileName,
std::pair<lyx::support::FileName const,
std::tr1::shared_ptr<lyx::graphics::CacheItem> >,
std::_Select1st<std::pair<lyx::support::FileName const,
std::tr1::shared_ptr<lyx::graphics::CacheItem> > >,
std::less<lyx::support::FileName>,
std::allocator<std::pair<lyx::support::FileName const,
std::tr1::shared_ptr<lyx::graphics::CacheItem> > >
::find(lyx::support::FileName const&) ()
#5 0x00000000009f1323 in
lyx::graphics::Cache::remove(lyx::support::FileName const&) const ()
#6 0x00000000009fba2b in
lyx::graphics::Loader::Impl::resetFile(lyx::support::FileName const&) ()
#7 0x00000000009fbf5e in lyx::graphics::Loader::Impl::~Impl() ()
#8 0x00000000009fc131 in lyx::graphics::Loader::~Loader() ()
#9 0x00000000009fde4e in lyx::graphics::PreviewImage::Impl::~Impl() ()
#10 0x00000000009fdee1 in lyx::graphics::PreviewImage::~PreviewImage() ()
#11 0x0000000000a04782 in
std::tr1::_Sp_counted_base_impl<lyx::graphics::PreviewImage*,
std::tr1::_Sp_deleter<lyx::graphics::PreviewImage>,
(__gnu_cxx::_Lock_policy)2>::_M_dispose() ()
#12 0x0000000000a0517a in std::_Rb_tree<std::basic_string<char,
std::char_traits<char>, std::allocator<char> >,
std::pair<std::basic_string<char, std::char_traits<char>,
std::allocator<char> > const,
std::tr1::shared_ptr<lyx::graphics::PreviewImage> >,
std::_Select1st<std::pair<std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
std::tr1::shared_ptr<lyx::graphics::PreviewImage> > >,
std::less<std::basic_string<char, std::char_traits<char>,
std::allocator<char> > >,
std::allocator<std::pair<std::basic_string<char, std::char_traits<char>,
std::allocator<char> > const,
std::tr1::shared_ptr<lyx::graphics::PreviewImage> > >
::_M_erase(std::_Rb_tree_node<std::pair<std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
std::tr1::shared_ptr<lyx::graphics::PreviewImage> > >*) ()
#13 0x00000000009febe7 in lyx::graphics::PreviewLoader::Impl::~Impl() ()
#14 0x00000000009fec91 in lyx::graphics::PreviewLoader::~PreviewLoader() ()
#15 0x0000000000a06b32 in
std::tr1::_Sp_counted_base_impl<lyx::graphics::PreviewLoader*,
std::tr1::_Sp_deleter<lyx::graphics::PreviewLoader>,
(__gnu_cxx::_Lock_policy)2>::_M_dispose() ()
#16 0x0000000000a06cf4 in std::_Rb_tree<lyx::Buffer const*,
std::pair<lyx::Buffer const* const,
std::tr1::shared_ptr<lyx::graphics::PreviewLoader> >,
std::_Select1st<std::pair<lyx::Buffer const* const,
std::tr1::shared_ptr<lyx::graphics::PreviewLoader> > >,
std::less<lyx::Buffer const*>, std::allocator<std::pair<lyx::Buffer
const* const, std::tr1::shared_ptr<lyx::graphics::PreviewLoader> > >
::_M_erase(std::_Rb_tree_node<std::pair<lyx::Buffer const* const,
std::tr1::shared_ptr<lyx::graphics::PreviewLoader> > >*) ()
#17 0x00007ffff51a7961 in exit () from /lib/x86_64-linux-gnu/libc.so.6
#18 0x00007ffff518cf06 in __libc_start_main () from
/lib/x86_64-linux-gnu/libc.so.6
#19 0x0000000000437169 in _start ()
-) Ubuntu 11.04 64bit
-) gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2
-) configure options: --prefix=/usr/local/lyx-2.0.1
Bye,

T.
Stephan Witt
2011-09-02 07:48:01 UTC
Permalink
Post by Tommaso Cucinotta
-) start LyX
-) open Advanced F&R
-) close LyX
-) start LyX (Advanced F&R is already there)
-) type C-m (math mode), then x, then left-cursor (try once, twice, thrice left cursor)
-) type C-q (quit)
and we get SEGFAULT!
This exact procedure doesn't crash on Mac (lyx-2.0.1 release candidate build).

Stephan
Richard Heck
2011-09-02 13:27:57 UTC
Permalink
Post by Stephan Witt
Post by Tommaso Cucinotta
-) start LyX
-) open Advanced F&R
-) close LyX
-) start LyX (Advanced F&R is already there)
-) type C-m (math mode), then x, then left-cursor (try once, twice, thrice left cursor)
-) type C-q (quit)
and we get SEGFAULT!
This exact procedure doesn't crash on Mac (lyx-2.0.1 release candidate build).
I didn't see it here either, at least not without instant preview.

rh
Richard Heck
2011-09-02 13:22:42 UTC
Permalink
Post by Tommaso Cucinotta
Post by Richard Heck
http://frege.brown.edu/lyx/lyx-2.0.1.tar.gz
Server.cpp: In member function ‘bool
Server.cpp:1018:45: warning: ignoring return value of ‘ssize_t
write(int, const void*, size_t)’, declared with attribute
warn_unused_result
Pavel reported this, too, and it's harmless. Probably a "(void)" in
front of the line should fix it.
Post by Tommaso Cucinotta
Then, when starting and opening EmbeddedObjects or Math, tons of these
latex had problems compiling 0lyxpreview.tex
latex had problems compiling 0lyxpreview_legacy.tex
This is dvips(k) 5.98 Copyright 2009 Radical Eye Software
(www.radicaleye.com)
' TeX output 2011.09.02:0305' -> 0lyxpreview_legacy.ps
(-> 0lyxpreview_legacy.001) </usr/share/texmf-texlive/dvips/base/tex.pro>
...
(-> 0lyxpreview_legacy.030) </usr/share/texmf-texlive/dvips/base/tex.pro>
</usr/share/texmf/fonts/enc/dvips/cm-super/cm-super-t1.enc>
</usr/share/texmf-texlive/dvips/base/texps.pro>
I think Julien said these are expected in certain circumstances. I do
not see them.

Richard
Loading...