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. There's no need for LyXLauncher anymore.
But your script doesn't compile because you try to file it. Can you please
remove this call?
Please set APP_RUN back to LyX.exe.
Please do this. I only changed this to make it compilable as you filed LyXLauncher. Can you please
do this in SVN trunk? This way we come closer to a final merged version.
- 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.
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.
The installation of these files need also be changed because all future
LyX versions will use them. So we should do the same as for Aspel: install
them so as they don't need to be installed/uninstalled for every new LyX
release. They will be installed as standalone program. If you later really
need to update your dictionary, you can download the latest version from
the net and put it in hunspell's installation folder.
It's way too much work to create installers for all the dictionaries as we
did for Aspell.
That was not my intention. My intention is to download the dictionary files (there is only one
folder per language) and copy it to a suitable location. That should be easy to implement.
regards Uwe
