Re: first step of merging the Win installers

[Uwe Stöhr]

Am 21.08.2011 11:00, schrieb Vincent van Ravesteijn:


- I used the custom LaTeX installer page from my installer, only because
this is already translated to 22 languages. The page design is a matter of
taste, so we can also use yours if you prefer it for a certain reason.


This page doesn't fit in the framework of the installer and uses a deprecated 
NSIS plug-in for the
GUI. We now have two different GUI codes in place, one using the modern 
nsDialogs code and the old
code based on INI files.

If you don't mind I'll put back the nsDialogs version and we'll just transfer 
the translations.


AFAICS this hasn't been done yet.

Uwe, are you still planning to revert to the nsDialogs version ?


For now not. This can be done any time later. Once this installer is ready for usage we will ask 
people to translate it. Therefore the nsDialog strings are in the language files of the installer. 
When we got them translated, we can switch.
Currently we have translations for 22 languages and thus should use them. For the nsDialog strings 
we currently only have them for 3 languages.



Yea the detection of external programs became really messy now. We should merge 
and clean this up.
What I don't like about this MiKTeX detection code is the lack of forward 
compatibility (e.g.
MiKTeX 2.10 won't work) and the code duplication for each version.
What it wrong with the generic code that I used?


The problem with the generic code is that you expect every MiKTeX version to act the same. But this 
was not the case in the past. Registry entries changed and even names of executables we need to 
configure MikTeX. So we need to check each major release, e.g. the future MiKTeX 2.10 (which is 
probably not released under this version number but as MiKTeX 3.0).


regards Uwe

Re: first step of merging the Win installers

[Vincent van Ravesteijn]

Op 5-9-2011 17:39, Uwe Stöhr schreef:

Am 21.08.2011 11:00, schrieb Vincent van Ravesteijn:

- I used the custom LaTeX installer page from my installer, only 
because
this is already translated to 22 languages. The page design is a 
matter of
taste, so we can also use yours if you prefer it for a certain 
reason.


This page doesn't fit in the framework of the installer and uses a 
deprecated NSIS plug-in for the
GUI. We now have two different GUI codes in place, one using the 
modern nsDialogs code and the old

code based on INI files.

If you don't mind I'll put back the nsDialogs version and we'll just 
transfer the translations.


AFAICS this hasn't been done yet.

Uwe, are you still planning to revert to the nsDialogs version ?


For now not. This can be done any time later. Once this installer is 
ready for usage we will ask people to translate it. Therefore the 
nsDialog strings are in the language files of the installer. When we 
got them translated, we can switch.
Currently we have translations for 22 languages and thus should use 
them. For the nsDialog strings we currently only have them for 3 
languages.


I don't understand. Joost proposed to transfer the translations. I 
would expect them to use the same strings and thus the same translations.




Yea the detection of external programs became really messy now. We 
should merge and clean this up.
What I don't like about this MiKTeX detection code is the lack of 
forward compatibility (e.g.

MiKTeX 2.10 won't work) and the code duplication for each version.
What it wrong with the generic code that I used?


The problem with the generic code is that you expect every MiKTeX 
version to act the same. But this was not the case in the past. 
Registry entries changed and even names of executables we need to 
configure MikTeX. So we need to check each major release, e.g. the 
future MiKTeX 2.10 (which is probably not released under this version 
number but as MiKTeX 3.0).


So, if you have a newer MikTeX installed, you prefer to not be able to 
use it over the fact that people use it and it might not work completely 
right (in some exceptional cases) ?


Vincent

Re: first step of merging the Win installers

[Uwe Stöhr]

Am 05.09.2011 19:44, schrieb Vincent van Ravesteijn:


I don't understand. Joost proposed to transfer the translations. I would 
expect them to use the
same strings and thus the same translations.


The strings are different due to the different layout of the 2 installer pages.


The problem with the generic code is that you expect every MiKTeX version to 
act the same. But
this was not the case in the past. Registry entries changed and even names of 
executables we need
to configure MikTeX. So we need to check each major release, e.g. the future 
MiKTeX 2.10 (which is
probably not released under this version number but as MiKTeX 3.0).


So, if you have a newer MikTeX installed, you prefer to not be able to use it 
over the fact that
people use it and it might not work completely right (in some exceptional 
cases) ?


What are you referring to? The installer needs to check the LaTeX system. If more than one system is 
installed, it should use the newest one, if TeXLive and MiKTeX is installed, we use MiKTeX. Each 
MiKTeX release requires different registry settings (in this case these are the MiKTeX settings) and 
there own executable names. We need to configure MiKTeX in any case, for example to install 
LyX-specific packages like broadway. To do this, we copy the files to MiKTeX's repository  and thus 
need to know its location. Then we need to refresh MiKTeX's package file name database. This is done 
by executing one of MiKTeX's programs (maybe with parameters). So we need to know the name of the 
executable and its location. Perhaps we also need to set some special registry entry before. This is 
just one example and this procedure changes from version to version of MiKTeX.


regards Uwe

Re: first step of merging the Win installers

[Uwe Stöhr]

Am 21.08.2011 11:00, schrieb Vincent van Ravesteijn:


- I used the custom LaTeX installer page from my installer, only because
this is already translated to 22 languages. The page design is a matter of
taste, so we can also use yours if you prefer it for a certain reason.


This page doesn't fit in the framework of the installer and uses a deprecated 
NSIS plug-in for the
GUI. We now have two different GUI codes in place, one using the modern 
nsDialogs code and the old
code based on INI files.

If you don't mind I'll put back the nsDialogs version and we'll just transfer 
the translations.


AFAICS this hasn't been done yet.

Uwe, are you still planning to revert to the nsDialogs version ?


For now not. This can be done any time later. Once this installer is ready for usage we will ask 
people to translate it. Therefore the nsDialog strings are in the language files of the installer. 
When we got them translated, we can switch.
Currently we have translations for 22 languages and thus should use them. For the nsDialog strings 
we currently only have them for 3 languages.



Yea the detection of external programs became really messy now. We should merge 
and clean this up.
What I don't like about this MiKTeX detection code is the lack of forward 
compatibility (e.g.
MiKTeX 2.10 won't work) and the code duplication for each version.
What it wrong with the generic code that I used?


The problem with the generic code is that you expect every MiKTeX version to act the same. But this 
was not the case in the past. Registry entries changed and even names of executables we need to 
configure MikTeX. So we need to check each major release, e.g. the future MiKTeX 2.10 (which is 
probably not released under this version number but as MiKTeX 3.0).


regards Uwe

Re: first step of merging the Win installers

[Vincent van Ravesteijn]

Op 5-9-2011 17:39, Uwe Stöhr schreef:

Am 21.08.2011 11:00, schrieb Vincent van Ravesteijn:

- I used the custom LaTeX installer page from my installer, only 
because
this is already translated to 22 languages. The page design is a 
matter of
taste, so we can also use yours if you prefer it for a certain 
reason.


This page doesn't fit in the framework of the installer and uses a 
deprecated NSIS plug-in for the
GUI. We now have two different GUI codes in place, one using the 
modern nsDialogs code and the old

code based on INI files.

If you don't mind I'll put back the nsDialogs version and we'll just 
transfer the translations.


AFAICS this hasn't been done yet.

Uwe, are you still planning to revert to the nsDialogs version ?


For now not. This can be done any time later. Once this installer is 
ready for usage we will ask people to translate it. Therefore the 
nsDialog strings are in the language files of the installer. When we 
got them translated, we can switch.
Currently we have translations for 22 languages and thus should use 
them. For the nsDialog strings we currently only have them for 3 
languages.


I don't understand. Joost proposed to "transfer the translations". I 
would expect them to use the same strings and thus the same translations.




Yea the detection of external programs became really messy now. We 
should merge and clean this up.
What I don't like about this MiKTeX detection code is the lack of 
forward compatibility (e.g.

MiKTeX 2.10 won't work) and the code duplication for each version.
What it wrong with the generic code that I used?


The problem with the generic code is that you expect every MiKTeX 
version to act the same. But this was not the case in the past. 
Registry entries changed and even names of executables we need to 
configure MikTeX. So we need to check each major release, e.g. the 
future MiKTeX 2.10 (which is probably not released under this version 
number but as MiKTeX 3.0).


So, if you have a newer MikTeX installed, you prefer to not be able to 
use it over the fact that people use it and it might not work completely 
right (in some exceptional cases) ?


Vincent

Re: first step of merging the Win installers

[Uwe Stöhr]

Am 05.09.2011 19:44, schrieb Vincent van Ravesteijn:


I don't understand. Joost proposed to "transfer the translations". I would 
expect them to use the
same strings and thus the same translations.


The strings are different due to the different layout of the 2 installer pages.


The problem with the generic code is that you expect every MiKTeX version to 
act the same. But
this was not the case in the past. Registry entries changed and even names of 
executables we need
to configure MikTeX. So we need to check each major release, e.g. the future 
MiKTeX 2.10 (which is
probably not released under this version number but as MiKTeX 3.0).


So, if you have a newer MikTeX installed, you prefer to not be able to use it 
over the fact that
people use it and it might not work completely right (in some exceptional 
cases) ?


What are you referring to? The installer needs to check the LaTeX system. If more than one system is 
installed, it should use the newest one, if TeXLive and MiKTeX is installed, we use MiKTeX. Each 
MiKTeX release requires different registry settings (in this case these are the MiKTeX settings) and 
there own executable names. We need to configure MiKTeX in any case, for example to install 
LyX-specific packages like broadway. To do this, we copy the files to MiKTeX's repository  and thus 
need to know its location. Then we need to refresh MiKTeX's package file name database. This is done 
by executing one of MiKTeX's programs (maybe with parameters). So we need to know the name of the 
executable and its location. Perhaps we also need to set some special registry entry before. This is 
just one example and this procedure changes from version to version of MiKTeX.


regards Uwe

Re: first step of merging the Win installers

[Vincent van Ravesteijn]

Op 11-6-2011 22:51, Joost Verburg schreef:
Uwe Stöhr uwesto...@web.de wrote in message 
news:4de9a690.2020...@web.de...
- I used the custom LaTeX installer page from my installer, only 
because
this is already translated to 22 languages. The page design is a 
matter of

taste, so we can also use yours if you prefer it for a certain reason.


This page doesn't fit in the framework of the installer and uses a 
deprecated NSIS plug-in for the GUI.  We now have two different GUI 
codes in place, one using the modern nsDialogs code and the old code 
based on INI files.


If you don't mind I'll put back the nsDialogs version and we'll just 
transfer the translations.


AFAICS this hasn't been done yet.

Uwe, are you still planning to revert to the nsDialogs version ?

Yea the detection of external programs became really messy now. We 
should merge and clean this up.
What I don't like about this MiKTeX detection code is the lack of 
forward compatibility (e.g. MiKTeX 2.10 won't work) and the code 
duplication for each version.

What it wrong with the generic code that I used?



Is this still the case or do we again use the generic code ?

Vincent

Re: first step of merging the Win installers

[Vincent van Ravesteijn]

Op 11-6-2011 22:51, Joost Verburg schreef:
"Uwe Stöhr"  wrote in message 
news:4de9a690.2020...@web.de...
- I used the custom LaTeX installer page from my installer, only 
because
this is already translated to 22 languages. The page design is a 
matter of

taste, so we can also use yours if you prefer it for a certain reason.


This page doesn't fit in the framework of the installer and uses a 
deprecated NSIS plug-in for the GUI.  We now have two different GUI 
codes in place, one using the modern nsDialogs code and the old code 
based on INI files.


If you don't mind I'll put back the nsDialogs version and we'll just 
transfer the translations.


AFAICS this hasn't been done yet.

Uwe, are you still planning to revert to the nsDialogs version ?

Yea the detection of external programs became really messy now. We 
should merge and clean this up.
What I don't like about this MiKTeX detection code is the lack of 
forward compatibility (e.g. MiKTeX 2.10 won't work) and the code 
duplication for each version.

What it wrong with the generic code that I used?



Is this still the case or do we again use the generic code ?

Vincent

Re: first step of merging the Win installers

[Joost Verburg]

Uwe Stöhr uwesto...@web.de wrote in message 
news:4de9a690.2020...@web.de...

- I used the custom LaTeX installer page from my installer, only because
this is already translated to 22 languages. The page design is a matter 
of

taste, so we can also use yours if you prefer it for a certain reason.


This page doesn't fit in the framework of the installer and uses a 
deprecated NSIS plug-in for the GUI.  We now have two different GUI codes in 
place, one using the modern nsDialogs code and the old code based on INI 
files.


If you don't mind I'll put back the nsDialogs version and we'll just 
transfer the translations.


But LyX is besides Inkscape the only program (of more than 50!) at my PC 
that don't have its own subfolder. I don't see why we should forbid the 
users to put it in their custom folder. E.g. thy might have LyX 2.0.1 
installed and LyX 1.6.5 too and also LyX 2.1 test releases. Without 
subfolders you will quickly loose the overview.
If you like we can change it that if the user doesn't select a custom 
folder, we do what you are already doing.


These start menu folder selection pages are something from the Windows 95 
era.


Many programs with only one icon put their icon (correctly!) in the main 
group. Surely there are other problems that don't follow the Windows GUI 
guidelines. This doesn't mean we should replicate that.


Please see http://msdn.microsoft.com/en-us/library/aa511447.aspx
Specifically:

Eliminate unnecessary folders by putting programs at the top level or in a 
single product folder. Generally, your program should have a single shortcut 
on the Start menu.


Create a product folder only if your product is a collection of individual 
programs (three or more), and users think of your product in terms of that 
collection.



I'll remove it then.


OK

To the topic: When I run the installer from within a user account, LyX is 
also only started with user privileges. So I don't see the problematic. 
But have you tested my version? This ioption is by default unchecked so it 
shouldn't harm.


That's probably because you're using Windows XP. If you use a more recent 
Windows version with UAC and install LyX for all users which requires 
administrator privileges, LyX itself will also run with administrator 
privileges and will use the administrator directories. When LyX it started 
later the normal way no administrator privileges are required and the user 
directories are used.

This means all preferences etc. are lost after running LyX the first time.
Broken features should not be included IMO, even if unchecked by default.

I don't understand. The ides is to give our colleagues the option to build 
the bundle and small installer versions as easy as possible. So it should 
be one script that builds both installers at once. For us developers it 
should be good to have a script where we can select only to build e.g. the 
bundle installer. How can I do this with the existing script in the NSIS 
GUI?


I've put the shared code in the common file.

But I can use IM, GS and also Python here without problems also without 
admin privileges. So why do we need special versions?


ImageMagick for example can only find Ghostscript through a HKLM registry 
key which required administrator privileges for installation.


Sure. As i told, this version is a proposal and not ready. I merged your 
version with my routines and did not yet sanitized this ones. There are 
other superfluous routines there as well that I will remove bit by bit.


Yea the detection of external programs became really messy now. We should 
merge and clean this up.
What I don't like about this MiKTeX detection code is the lack of forward 
compatibility (e.g. MiKTeX 2.10 won't work) and the code duplication for 
each version.

What it wrong with the generic code that I used?

Not in my opinion because: When I'm already a LyX user I have MiKTeX 
already installed and thus don't need it. I only need it as new user and 
in this case the problem appears that i described. The bundle installer 
therefore only makes sense with MiKTeX included and is only to be used for 
new installations as you then need MiKTeX anyway.


I don't understand. The bundled version always included MiKTeX. I'm talking 
about having the option to download MiKTeX in the standard installer.


Joost 

Re: first step of merging the Win installers

[Joost Verburg]

"Uwe Stöhr"  wrote in message 
news:4de9a690.2020...@web.de...

- I used the custom LaTeX installer page from my installer, only because
this is already translated to 22 languages. The page design is a matter 
of

taste, so we can also use yours if you prefer it for a certain reason.


This page doesn't fit in the framework of the installer and uses a 
deprecated NSIS plug-in for the GUI.  We now have two different GUI codes in 
place, one using the modern nsDialogs code and the old code based on INI 
files.


If you don't mind I'll put back the nsDialogs version and we'll just 
transfer the translations.


But LyX is besides Inkscape the only program (of more than 50!) at my PC 
that don't have its own subfolder. I don't see why we should forbid the 
users to put it in their custom folder. E.g. thy might have LyX 2.0.1 
installed and LyX 1.6.5 too and also LyX 2.1 test releases. Without 
subfolders you will quickly loose the overview.
If you like we can change it that if the user doesn't select a custom 
folder, we do what you are already doing.


These start menu folder selection pages are something from the Windows 95 
era.


Many programs with only one icon put their icon (correctly!) in the main 
group. Surely there are other problems that don't follow the Windows GUI 
guidelines. This doesn't mean we should replicate that.


Please see http://msdn.microsoft.com/en-us/library/aa511447.aspx
Specifically:

"Eliminate unnecessary folders by putting programs at the top level or in a 
single product folder. Generally, your program should have a single shortcut 
on the Start menu."


"Create a product folder only if your product is a collection of individual 
programs (three or more), and users think of your product in terms of that 
collection."



I'll remove it then.


OK

To the topic: When I run the installer from within a user account, LyX is 
also only started with user privileges. So I don't see the problematic. 
But have you tested my version? This ioption is by default unchecked so it 
shouldn't harm.


That's probably because you're using Windows XP. If you use a more recent 
Windows version with UAC and install LyX for all users which requires 
administrator privileges, LyX itself will also run with administrator 
privileges and will use the administrator directories. When LyX it started 
later the normal way no administrator privileges are required and the user 
directories are used.

This means all preferences etc. are lost after running LyX the first time.
Broken features should not be included IMO, even if unchecked by default.

I don't understand. The ides is to give our colleagues the option to build 
the bundle and small installer versions as easy as possible. So it should 
be one script that builds both installers at once. For us developers it 
should be good to have a script where we can select only to build e.g. the 
bundle installer. How can I do this with the existing script in the NSIS 
GUI?


I've put the shared code in the common file.

But I can use IM, GS and also Python here without problems also without 
admin privileges. So why do we need special versions?


ImageMagick for example can only find Ghostscript through a HKLM registry 
key which required administrator privileges for installation.


Sure. As i told, this version is a proposal and not ready. I merged your 
version with my routines and did not yet sanitized this ones. There are 
other superfluous routines there as well that I will remove bit by bit.


Yea the detection of external programs became really messy now. We should 
merge and clean this up.
What I don't like about this MiKTeX detection code is the lack of forward 
compatibility (e.g. MiKTeX 2.10 won't work) and the code duplication for 
each version.

What it wrong with the generic code that I used?

Not in my opinion because: When I'm already a LyX user I have MiKTeX 
already installed and thus don't need it. I only need it as new user and 
in this case the problem appears that i described. The bundle installer 
therefore only makes sense with MiKTeX included and is only to be used for 
new installations as you then need MiKTeX anyway.


I don't understand. The bundled version always included MiKTeX. I'm talking 
about having the option to download MiKTeX in the standard installer.


Joost 

Re: first step of merging the Win installers

[Uwe Stöhr]

Am 23.05.2011 12:18, schrieb Edwin Leuven:


when i use your installer it gets stuck at the checking stage. i
killed it after 30mins.


I'll have a closer look soon.

thanks and regards
Uwe

Re: first step of merging the Win installers

[Uwe Stöhr]

Am 23.05.2011 20:34, schrieb Joost Verburg:


  - you installed LyX's sty-files always to MiKTeX's user folder. But
when LyX is installed for all

users, we need to install them to MiKTeX's main folder to be available for
all users


What if the user is not the administrator and only installs LyX for his/her
own user account?
AFAIK this was the reason why I changed the implementation.


You misunderstood me. When the user installs LyX only for his account (no matter if this is a user 
or admin account), the local MiKTeX folder is of course correct. But when he installs LyX for all 
users on the PC this location is not correct and that is what I fixed.



- I used the custom LaTeX installer page from my installer, only because
this is already translated to 22 languages. The page design is a matter of
taste, so we can also use yours if you prefer it for a certain reason.


The custom page system was a generic one supporting additional applications
if needed in the future.


What do you plan?


- there is now an installer page where you can select LyX's start menu
folder. This was once requested by users.


I don't agree with this. There's no reason to have a subfolder in the start
menu because we only have one shortcut.


But LyX is besides Inkscape the only program (of more than 50!) at my PC that don't have its own 
subfolder. I don't see why we should forbid the users to put it in their custom folder. E.g. thy 
might have LyX 2.0.1 installed and LyX 1.6.5 too and also LyX 2.1 test releases. Without subfolders 
you will quickly loose the overview.
If you like we can change it that if the user doesn't select a custom folder, we do what you are 
already doing.



- there is now an installer page where you can select the components to
install like JabRef and GSview, if there should be a desktop icon or not
and if the .lyx file extension should be linked to the installed LyX
version.


I'm not sure about GSview. It's commercial software with a nag screen.
I think it should be removed.


I'll remove it then.


- the last installer page has now an option to start LyX after the
installation. The option is by default disabled, but this feature is kind
of standard (users expect this, especially new ones).


This was removed on purpose because LyX will run with the wrong user account
since the installer has elevated privileges. So any preferences that are
changed etc. will not be preserved. Please remove it until a proper solution
is implemented.


Note that my installer I put in SVN trunk is a proposal. It is not that I think that everything MUST 
be as I did. I wanted to have a base to discuss the details, like this one.


To the topic: When I run the installer from within a user account, LyX is also only started with 
user privileges. So I don't see the problematic. But have you tested my version? This ioption is by 
default unchecked so it shouldn't harm.



- created 2 different nsi-files. This way you can simply execute the
lyx-bundle.nsi file and get a ready to use bundle installer. (No need to
edit an NSIS file.)


There's no reason to duplicate code. Defines can be set in the NSIS GUI, but
if you prefer a seperate file do something like:

!define SETUPTYPE_BUNDLE
!incluce lyx.nsi


I don't understand. The ides is to give our colleagues the option to build the bundle and small 
installer versions as easy as possible. So it should be one script that builds both installers at 
once. For us developers it should be good to have a script where we can select only to build e.g. 
the bundle installer. How can I do this with the existing script in the NSIS GUI?
Can you please modify the main script so that it builds both versions at once and that it is 
possible to build only on variant via the NSIS GUI?



(-you can ignore my path changes insettings.nsh, I'm to lazy to remove
them (they went in accidentally))


Please do revert. The paths no longer match INSTALL.Win32 now.


Will do tomorrow.


- why do you use special versions of Python and Ghostscript? This makes it
hard for other to build the installer and I don't see why this is
necessary. It is also harder to keep them up to date. I built an installer
where I used the official versions of the latest IM, Python 2.7.1 and GS
9.0.2. They work fine here on my two test PCs - one with GS and Python
pre-installed, one without them.


They are special portable versions. They don't work by default without
administrator privileges.


But I can use IM, GS and also Python here without problems also without admin privileges. So why do 
we need special versions?



Can you remove the code for detecting external Ghostscript/Python etc.?


Sure. As i told, this version is a proposal and not ready. I merged your version with my routines 
and did not yet sanitized this ones. There are other superfluous routines there as well that I will 
remove bit by bit.



- you don't have the LyXLauncher in your dependency package. Can you
please add it.


That's because it's gone. 

Re: first step of merging the Win installers

[Uwe Stöhr]

Am 23.05.2011 12:18, schrieb Edwin Leuven:


when i use your installer it gets stuck at the checking stage. i
killed it after 30mins.


I'll have a closer look soon.

thanks and regards
Uwe

Re: first step of merging the Win installers

[Uwe Stöhr]

Am 23.05.2011 20:34, schrieb Joost Verburg:


  >- you installed LyX's sty-files always to MiKTeX's user folder. But
when LyX is installed for all

users, we need to install them to MiKTeX's main folder to be available for
all users


What if the user is not the administrator and only installs LyX for his/her
own user account?
AFAIK this was the reason why I changed the implementation.


You misunderstood me. When the user installs LyX only for his account (no matter if this is a user 
or admin account), the local MiKTeX folder is of course correct. But when he installs LyX for all 
users on the PC this location is not correct and that is what I fixed.



- I used the custom LaTeX installer page from my installer, only because
this is already translated to 22 languages. The page design is a matter of
taste, so we can also use yours if you prefer it for a certain reason.


The custom page system was a generic one supporting additional applications
if needed in the future.


What do you plan?


- there is now an installer page where you can select LyX's start menu
folder. This was once requested by users.


I don't agree with this. There's no reason to have a subfolder in the start
menu because we only have one shortcut.


But LyX is besides Inkscape the only program (of more than 50!) at my PC that don't have its own 
subfolder. I don't see why we should forbid the users to put it in their custom folder. E.g. thy 
might have LyX 2.0.1 installed and LyX 1.6.5 too and also LyX 2.1 test releases. Without subfolders 
you will quickly loose the overview.
If you like we can change it that if the user doesn't select a custom folder, we do what you are 
already doing.



- there is now an installer page where you can select the components to
install like JabRef and GSview, if there should be a desktop icon or not
and if the .lyx file extension should be linked to the installed LyX
version.


I'm not sure about GSview. It's commercial software with a nag screen.
I think it should be removed.


I'll remove it then.


- the last installer page has now an option to start LyX after the
installation. The option is by default disabled, but this feature is kind
of standard (users expect this, especially new ones).


This was removed on purpose because LyX will run with the wrong user account
since the installer has elevated privileges. So any preferences that are
changed etc. will not be preserved. Please remove it until a proper solution
is implemented.


Note that my installer I put in SVN trunk is a proposal. It is not that I think that everything MUST 
be as I did. I wanted to have a base to discuss the details, like this one.


To the topic: When I run the installer from within a user account, LyX is also only started with 
user privileges. So I don't see the problematic. But have you tested my version? This ioption is by 
default unchecked so it shouldn't harm.



- created 2 different nsi-files. This way you can simply execute the
lyx-bundle.nsi file and get a ready to use bundle installer. (No need to
edit an NSIS file.)


There's no reason to duplicate code. Defines can be set in the NSIS GUI, but
if you prefer a seperate file do something like:

!define SETUPTYPE_BUNDLE
!incluce lyx.nsi


I don't understand. The ides is to give our colleagues the option to build the bundle and small 
installer versions as easy as possible. So it should be one script that builds both installers at 
once. For us developers it should be good to have a script where we can select only to build e.g. 
the bundle installer. How can I do this with the existing script in the NSIS GUI?
Can you please modify the main script so that it builds both versions at once and that it is 
possible to build only on variant via the NSIS GUI?



(-you can ignore my path changes insettings.nsh, I'm to lazy to remove
them (they went in accidentally))


Please do revert. The paths no longer match INSTALL.Win32 now.


Will do tomorrow.


- why do you use special versions of Python and Ghostscript? This makes it
hard for other to build the installer and I don't see why this is
necessary. It is also harder to keep them up to date. I built an installer
where I used the official versions of the latest IM, Python 2.7.1 and GS
9.0.2. They work fine here on my two test PCs - one with GS and Python
pre-installed, one without them.


They are special portable versions. They don't work by default without
administrator privileges.


But I can use IM, GS and also Python here without problems also without admin privileges. So why do 
we need special versions?



Can you remove the code for detecting external Ghostscript/Python etc.?


Sure. As i told, this version is a proposal and not ready. I merged your version with my routines 
and did not yet sanitized this ones. There are other superfluous routines there as well that I will 
remove bit by bit.



- you don't have the LyXLauncher in your dependency package. Can you
please add it.


That's because it's gone. 

Re: first step of merging the Win installers

[Edwin Leuven]

On Mon, May 23, 2011 at 06:17, Uwe Stöhr uwesto...@web.de wrote:
 - I replaced the LaTeX check and installation routine with my installer for
 the following reasons:

when i use your installer it gets stuck at the checking stage. i
killed it after 30mins.

using the installer i build myself using the previous installer code i
don't have this problem

i don't have admin rights on my machine btw

ed.

Re: first step of merging the Win installers

[Joost Verburg]

Hi Uwe,

Below are my comments/concerns.
I guess in the future it's better to have a little discussion on the devel 
list first so things don't have to be reverted.

Uwe Stöhr uwesto...@web.de wrote in message 
news:4dd9dfbf.2080...@web.de...
- you installed LyX's sty-files always to MiKTeX's user folder. But 
when LyX is installed for all
 users, we need to install them to MiKTeX's main folder to be available for 
 all users

What if the user is not the administrator and only installs LyX for his/her 
own user account?
AFAIK this was the reason why I changed the implementation.

 - I used the custom LaTeX installer page from my installer, only because 
 this is already translated to 22 languages. The page design is a matter of 
 taste, so we can also use yours if you prefer it for a certain reason.

The custom page system was a generic one supporting additional applications 
if needed in the future. I think it's better to keep that.

 - there is now an installer page where you can select LyX's start menu 
 folder. This was once requested by users.

I don't agree with this. There's no reason to have a subfolder in the start 
menu because we only have one shortcut. It should be in the main start menu 
according to the Microsoft UI guidelines.

 - there is now an installer page where you can select the components to 
 install like JabRef and GSview, if there should be a desktop icon or not 
 and if the .lyx file extension should be linked to the installed LyX 
 version.

I'm not sure about GSview. It's commercial software with a nag screen.
I think it should be removed.

 - the last installer page has now an option to start LyX after the 
 installation. The option is by default disabled, but this feature is kind 
 of standard (users expect this, especially new ones).

This was removed on purpose because LyX will run with the wrong user account 
since the installer has elevated privileges. So any preferences that are 
changed etc. will not be preserved. Please remove it until a proper solution 
is implemented.

 - register also *.lyx14 and *.lyx13 to LyX if the user agreed to link 
 *.lyx to the new LyX version.

 - created 2 different nsi-files. This way you can simply execute the 
 lyx-bundle.nsi file and get a ready to use bundle installer. (No need to 
 edit an NSIS file.)

There's no reason to duplicate code. Defines can be set in the NSIS GUI, but 
if you prefer a seperate file do something like:

!define SETUPTYPE_BUNDLE
!incluce lyx.nsi

 (-you can ignore my path changes insettings.nsh, I'm to lazy to remove 
 them (they went in accidentally))

Please do revert. The paths no longer match INSTALL.Win32 now.

   - why do you use a file list for things like the fonts? They are all in 
LyX's Resources folder like
 the layout files and scripts. Moreover, you missed 2 fonts in your list. 
 Also for python and Ghostscript there is no list necessary because we can 
 file the whole folder recursively.

Yea those lists I removed already. I think I forgot to commit.

 - why do you use special versions of Python and Ghostscript? This makes it 
 hard for other to build the installer and I don't see why this is 
 necessary. It is also harder to keep them up to date. I built an installer 
 where I used the official versions of the latest IM, Python 2.7.1 and GS 
 9.0.2. They work fine here on my two test PCs - one with GS and Python 
 pre-installed, one without them.

They are special portable versions. They don't work by default without 
administrator privileges.

Can you remove the code for detecting external Ghostscript/Python etc.?
I really want to keep bundling a tested combination of the external tools 
which also support normal user accounts.

 - you don't have the LyXLauncher in your dependency package. Can you 
 please add it.

That's because it's gone. There's no need for LyXLauncher anymore. LyX is 
now a real Windows GUI application.
Please set APP_RUN back to LyX.exe.

 Some generalities:

 - the idea is to provide an installer that can be used by every developer 
 if he has NSIS installed. He can then call the lyx.nsi file and get a 
 ready to use installer. Everything should be possible withing the 
 checked-out SVN folders. I therefore want to put your dependency package 
 also to SVN.

The dependency package is downloaded automatically by CMake.

 - MiKTeX should not be downloaded. Bundling it has the advantage that the 
 user can download one installer

I think it's a good feature to offer a download option in the standard 
installer.

 - decrease the installer size by not shipping every exotic spell checker 
 language file. I plan to ship only the English files by default. Others 
 can be installed from the Web. A normal user only needs 1 language (and 
 not 113 as we currently ship) and downloading/installing it doesn't 
 require a broadband connection.

I'm OK with that if we should keep the current UI but download the 
dictionaries instead.

 The installation of these files need also be 

Re: first step of merging the Win installers

[Edwin Leuven]

On Mon, May 23, 2011 at 06:17, Uwe Stöhr  wrote:
> - I replaced the LaTeX check and installation routine with my installer for
> the following reasons:

when i use your installer it gets stuck at the checking stage. i
killed it after 30mins.

using the installer i build myself using the previous installer code i
don't have this problem

i don't have admin rights on my machine btw

ed.

Re: first step of merging the Win installers

[Joost Verburg]

Hi Uwe,

Below are my comments/concerns.
I guess in the future it's better to have a little discussion on the devel 
list first so things don't have to be reverted.

"Uwe Stöhr"  wrote in message 
news:4dd9dfbf.2080...@web.de...
 >   - you installed LyX's sty-files always to MiKTeX's user folder. But 
when LyX is installed for all
> users, we need to install them to MiKTeX's main folder to be available for 
> all users

What if the user is not the administrator and only installs LyX for his/her 
own user account?
AFAIK this was the reason why I changed the implementation.

> - I used the custom LaTeX installer page from my installer, only because 
> this is already translated to 22 languages. The page design is a matter of 
> taste, so we can also use yours if you prefer it for a certain reason.

The custom page system was a generic one supporting additional applications 
if needed in the future. I think it's better to keep that.

> - there is now an installer page where you can select LyX's start menu 
> folder. This was once requested by users.

I don't agree with this. There's no reason to have a subfolder in the start 
menu because we only have one shortcut. It should be in the main start menu 
according to the Microsoft UI guidelines.

> - there is now an installer page where you can select the components to 
> install like JabRef and GSview, if there should be a desktop icon or not 
> and if the .lyx file extension should be linked to the installed LyX 
> version.

I'm not sure about GSview. It's commercial software with a nag screen.
I think it should be removed.

> - the last installer page has now an option to start LyX after the 
> installation. The option is by default disabled, but this feature is kind 
> of standard (users expect this, especially new ones).

This was removed on purpose because LyX will run with the wrong user account 
since the installer has elevated privileges. So any preferences that are 
changed etc. will not be preserved. Please remove it until a proper solution 
is implemented.

> - register also *.lyx14 and *.lyx13 to LyX if the user agreed to link 
> *.lyx to the new LyX version.
>
> - created 2 different nsi-files. This way you can simply execute the 
> lyx-bundle.nsi file and get a ready to use bundle installer. (No need to 
> edit an NSIS file.)

There's no reason to duplicate code. Defines can be set in the NSIS GUI, but 
if you prefer a seperate file do something like:

!define SETUPTYPE_BUNDLE
!incluce lyx.nsi

> (-you can ignore my path changes insettings.nsh, I'm to lazy to remove 
> them (they went in accidentally))

Please do revert. The paths no longer match INSTALL.Win32 now.

 > > - why do you use a file list for things like the fonts? They are all in 
LyX's Resources folder like
> the layout files and scripts. Moreover, you missed 2 fonts in your list. 
> Also for python and Ghostscript there is no list necessary because we can 
> file the whole folder recursively.

Yea those lists I removed already. I think I forgot to commit.

> - why do you use special versions of Python and Ghostscript? This makes it 
> hard for other to build the installer and I don't see why this is 
> necessary. It is also harder to keep them up to date. I built an installer 
> where I used the official versions of the latest IM, Python 2.7.1 and GS 
> 9.0.2. They work fine here on my two test PCs - one with GS and Python 
> pre-installed, one without them.

They are special portable versions. They don't work by default without 
administrator privileges.

Can you remove the code for detecting external Ghostscript/Python etc.?
I really want to keep bundling a tested combination of the external tools 
which also support normal user accounts.

> - you don't have the LyXLauncher in your dependency package. Can you 
> please add it.

That's because it's gone. There's no need for LyXLauncher anymore. LyX is 
now a real Windows GUI application.
Please set APP_RUN back to LyX.exe.

> Some generalities:
>
> - the idea is to provide an installer that can be used by every developer 
> if he has NSIS installed. He can then call the lyx.nsi file and get a 
> ready to use installer. Everything should be possible withing the 
> checked-out SVN folders. I therefore want to put your dependency package 
> also to SVN.

The dependency package is downloaded automatically by CMake.

> - MiKTeX should not be downloaded. Bundling it has the advantage that the 
> user can download one installer

I think it's a good feature to offer a download option in the standard 
installer.

> - decrease the installer size by not shipping every exotic spell checker 
> language file. I plan to ship only the English files by default. Others 
> can be installed from the Web. A normal user only needs 1 language (and 
> not 113 as we currently ship) and downloading/installing it doesn't 
> require a broadband connection.

I'm OK with that if we should keep the current UI but download the 
dictionaries