Uwe Stöhr wrote:
But haven't you done so the time Christian tried to bring us working
together? I had this time rewritten major parts of my code as suggested
by Christian. The plan was that these parts will be taken and other
parts of your installer to create a new one which code we both
understand. Bot nothing came from your side.
I've replied to all the messages I received during this discussion and
also made some changes to the installer code. I'm still interested to
work on a merge of the installers.
> It looks like the only unofficial modification (the toolbar) in your
installer is currently
> related to your PDF viewing method.
This will go now. But this is not the only difference between the
installers. As said as always before, the main problem was to understand
your code as maintaining it is the major task. Providing support costs
much more time than to program. As you are not following the users-list
regularily, which is no problem in general, I had to do this. Therefore
I need an installer with code I understand. Most of the recent installer
features are consequences of user complaints.
Are you able to understand the current installer code in trunk?
It always takes some time to understand code you have not written
yourself, but I think the current scripts are less complicated as
compared to your scripts because of the new NSIS features I've used.
For example, the complex code related to the InstallOptions dialogs and
INI files is no longer necessary because of the new nsDialogs plug-in.
> The only thing I don't think is a good idea is to install a subset of
an application and then to
> create the registry keys that pretend this installation to be the
official application. This
> breaks other application that depend on e.g. ImageMagick, because
they use features that are not
> required by LyX.
When you are using other applications that are using e.g. code from
Imagemagick, you have it already installed. Then the installer doesn't
install any ore ImageMagick files. You can also at any time later for
example install a full Python version without problems when needed.
But when such an application is installed when LyX already exists on the
system, the incomplete ImageMagick will be detected and the application
will not work.
> The only remaining issue here is the detection of Ghostscript by
Imagemagick. Now both are under
> the GPL this may not be very difficult to solve. Then we can bundle
ImageMagick and Ghostscript
> just like Python right now.
But that kind of bundling is already the case in my installer?
No, you're writing to registry keys that belong to the original
ImageMagick application.
What I would suggest is to install a subset of ImageMagick in the LyX
directory that is completely separated from a full ImageMagick that may
be installed. This ImageMagick installation should also be able to
detect our Ghostscript files.
> There are quite some important features in the official installer
that are missing in the
> alternative one, such as support for installation without
administrator privileges and more
> support for multi-user environments. Most companies and universities
have strict network security > policies these days and don't give their
employees administrator rights.
We have these restrictions here too and the admins absolutely don't like
that users install things. Even when it is possible with user
permissions, some things will automatically be undone when relogin. I
discussed this with our admins a few times and they convinced me not to
offer things they won't work. Nevertheless the installer is in
principle ready to offer user-only installations.
Most companies do allow users to install software as long as no system
folders/files/settings are modified. But even when the system is
restored on reboot it can be useful to be able to install LyX, e.g. when
working in a library.
There are a number of special considerations regarding support for
user-only installations and multi-user environments. You won't have
access to "Program Files", HKLM registry keys and things like that. I've
already added support for such installations.
It's also important to take systems with multiple users into account.
For example, your installer only detects global file associations, not
the per-user ones.
Tests for converters belong in the configure script instead of the
installer.
Regards,
Joost
