There is a previous message thread that this is related to, but it was long and
contentious and I thought this might be more helpful at the top of a new
I appreciate that some effort was put into this latest version of POV-Ray to try
to accommodate multiple users. Unfortunately, I think the effort was directed
toward offering options for defining paths in a specific type of multi-user
environment (roaming profiles and apps on shared drives) and less on options
that would help both that environment and the general user or even home users).
I suspect a vast majority of multi-user environments would be happy with the
default locations, but they need the program to work for everyone logging in. I
think there are two big issues to point out.
1) The documentation (as I comprehend it) about non-standard installations is
not about the _install_ process, but rather the POV-Ray initial start-up
process. The /INSTALL and /QINSTALL switches are not intended to and *do not
work* with the downloaded installer. They work with the POV-Ray executable(s).
While this is covered in the documentation, it is not made clear in the
"Non-Standard Installations" section which many people seeking help for this are
directly linked to. Having a switch named "/Install" for something that is
already installed adds to the confusion. I think "\paths" would make more
The documentation states that "it may not be necessary to install anything", but
gives no information on how to get POV-Ray on the machine short of
The documentation also states that if the "documents" directory doesn't exist,
"it will be automatically created along with the INI directory beneath it."
What it doesn't say is that those will be empty directories. It doesn't state
anywhere that it is the responsibility of the user/lab manager to put all the
necessary (and default) documents into that location regardless of whether it is
"inferred" or expressly stated. What is the point of the code that creates
empty directories when there are files that are clearly needed in those
directories? This code should be easily extended to resolve the next issue...
2) The required, user-editable documents are only installed for the installing
user (administrator or not). When a new user tries to start POV-Ray and the
machine they are using was not configured by a competent administrator (with
available time to work out these issues), the first thing they get is an error.
That doesn't look good.
A few years ago, I posted about this and included a simple batch file to be
disguised as POV-Ray. The .bat checks for the user POV-Ray files and
copies/creates them if they don't exist. It works fine *except* that most users
don't start POV-Ray from the icon (.bat). They call POV-Ray directly from
another application and then we get a call because "POV-Ray isn't working." One
solution is to include the POV-Ray user files in the default profile, but that
doubles our default profile size causing all user's initial log in (which may be
every time with Deep Freeze) to take longer and makes the user profile that much
bigger -- a problem for entities that don't use Deep Freeze or who store
profiles on the network. This doesn't make sense when only a small (but
significant) percentage of users ever use POV-Ray.
All other software with which I am familiar (which is a significant library)
except for a few packages NOT designed for multiple users (such as to collect
data from equipment that takes a highly trained technician to run) will create
any missing-but-required, default, user-editable files when it starts. Why
can't POV-Ray do something similar? You could include a default copy of all the
"documents" files in it's "Home" directory and upon reaching the point that it
currently does where it creates the empty "documents" directory, simply
create/copy the default set of initial user-editable files?
I saw a mention in the other message thread about using a pre-install and
needing MSI support. I am not a developer, so I am not entirely sure of the
details of those functions, but I know what I have observed with other software.
Look at Mozilla products for example. They distinctly do not offer MSI
installation (much to many lab manager's frustration), but they do manage to
create default files on first start for any user whether they had a Windows user
profile at the time of installation or not. Are they using "MSI support"?
If I get time (and you are interested), I will take a stab at specific
suggestions for the documentation related to multiple users to make it less
"developery" and more friendly for lab manager types who are the ones most
likely to be using it.
Sorry for the long post, but I'm trying to logically explain the frustration of
the end user (like "Nick") without frustrating the developers who have worked so
hard on this.
Post a reply to this message
On 6/03/2015 01:58, Erich wrote:
> "Non-Standard Installations" section which many people seeking help for this are
> directly linked to. Having a switch named "/Install" for something that is
> already installed adds to the confusion. I think "\paths" would make more
This is a fair point, though I will mention that the main purpose of
/install is not for pre-installed executables but for the case where
the EXE is on the network or has otherwise been made available to the
user without their needing to run anything prior to that.
> The documentation states that "it may not be necessary to install anything", but
> gives no information on how to get POV-Ray on the machine short of
The main impetus for the /install switch was requests from lab techs
using POV in a educational setting. In those cases the software is
usually available on the network or in some other pre-mapped location.
> If I get time (and you are interested), I will take a stab at specific
> suggestions for the documentation related to multiple users to make it less
> "developery" and more friendly for lab manager types who are the ones most
> likely to be using it.
Thanks for the offer.
I think what I need to do now is actually implement the default file
install on first launch like you and others have suggested. I need to
do it in such a way that it works even if the exe is on the network,
so it can't depend on the files being installed locally; probably to
do this I'll create a separate user-files installer that lives with
the main exe.
Once I've done that I'll let folks here know and they can test, and if
you like you can update the documentation to suit.
Post a reply to this message
Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> The main impetus for the /install switch was requests from lab techs
> using POV in a educational setting. In those cases the software is
> usually available on the network or in some other pre-mapped location.
I'm in an educational setting! :-)
We stopped putting (Windows) executables on the network many years ago because
the bandwidth utilization was too high and desktop hard drives are so big. I
have not seen any discussion of doing that on a national lab manager listserv
for many years either. Are you sure that is still regularly/widely done?
We currently (and many others) create generic, monolithic images with many
software packages already installed and roll those out to standardize all the
systems in a lab or even across many labs. The up-and-coming standard is to use
WDS and SCCM to push a base image with little-to-no software installed, and then
push packages specific to the lab needs. This makes for much more flexibility,
but it still has the software installed locally.
I think much more common than software on the network is user profiles on the
network, but that too has enough costs and myriad problems that I get the
feeling it is still not the most common method. We offer file storage, but not
roaming profiles. Our users get either a fresh, local profile at every logon
(when the machine has DeepFreeze) or their former, local profile which lasts
only until we re-image the machine again (typically every semester).
> I think what I need to do now is actually implement the default file
> install on first launch like you and others have suggested. I need to
> do it in such a way that it works even if the exe is on the network,
> so it can't depend on the files being installed locally; probably to
> do this I'll create a separate user-files installer that lives with
> the main exe.
Does the current creation of the empty Documents folder not work if the .exe is
on the network? I got the impression that while the "Home" directory may be
tied to the network if the /install flag isn't used (and the .exe is on the
network), but that the user-editable files are sought in (and set to) the
%userprofile% location if the registry entries aren't found. In that case it
doesn't seem like a major change -- more like change a create dir tree to a copy
dir tree (and files). Non-standard locations have the option already.
Post a reply to this message