In article <wZmeOGBnBBOdVTR7PqR9bMN3e05c@4ax.com> , Glen Berry 
<7no### [at] ezwvcom>  wrote:

> If someone is afraid of some "rogue" scene file having  too much
> control of their computer, why not just make the settings on the
> command line and/or the "povray.ini" file overide the settings made by
> "ini_option." The settings suggested by "ini_option" would only take
> effect if there were no "default" or overiding value set by either the
> command line or the "povray.ini" file.

I think you are contradicting yourself here. One the one hand you say it
eases frequent changes of options, on the other hand you suggest to give it
the lowest possible precedence.

Currently the order is (some elements are optional):

- Enviroment variable (supply alternate name for "povray.ini")
- povray.ini or env.var. name
- Command line
- INI files
- Write INI file
(- ini_option)

You suggest:

- Enviroment variable (supply alternate name for "povray.ini")
(- ini_option)
- povray.ini or env.var. name
- Command line
- INI files
- Write INI file

As you can see, if you specify to write an INI file now it will contain all
options, and the next time you render ini_option settings will be ignored.

But that is not all!  How can this _ever_ work at all?  Don't you at least
need the command line to specify the scene file?  What is about animation,
you would basically have to restart POV-Ray for each frame as you would have
to read all INI files again.

> For those of us that like to specify ini options in the scene file, we
> could simply leave empty spaces in our povray.ini files and carry on
> as usual. Those that didn't like scene files having control, could
> insert default values in their povray.ini, and they could likewise
> carry on as usual.

As said, it simply does not work as you suggest.

> Would there be any problems with this arrangement? I'd *really* like
> to keep "ini_option" in the POV-Ray scene file.

Consistency, among many others. POV-Ray allows the user of the local
POV-Ray, not the person who wrote the file to force the settings.  After all
you can always include an INI file with your scene archive.

So, as there is obviously no problem sending files to others, this leaves
you working with your own scenes.  I can see why you would like to change
settings easily.
Well, lets look at three different platforms and how it works on each with
one file open:

Windows:  Open the scene file, change your scene, save, go to the ini
settings button, change the command line (which is kept between renders) and
render.  Repeat all as often as you like, can change settings without having
to go to editor. You can change the scene instantly.

Mac OS:  Open the scene file, change your scene, save, open render settings,
change settings and render.  Repeat all as often as you like, can change
settings without having to go to editor. You can change the scene instantly.

Unix:  Open the scene file, change your scene, save.  Go to command line
window (or have an editor that can execute a command line), use your own
script or just the previous command lines and edit it, hit return (render).
Repeat all as often as you like, can change settings without having to go to
editor. You can change the scene instantly.


Now, by placing it in the scene file, what do you gain? Lets see:

Windows:  Open the scene file, change your scene, scroll to the ini_option
line, render.  To change settings in scene, edit, save, render.  To change
scene, scroll to last edited position and change scene, (optional: go back
to settings change them) and render.

Mac OS:  Open the scene file, change your scene, scroll to the ini_option
line, render.  To change settings in scene, edit, save, render.  To change
scene, scroll to last edited position and change scene, save, (optional: go
back to settings change them) and render.

Unix:  Open the scene file, change your scene, save scene.  Go to command
line window (or have an editor that can execute a command line), use your
own script or just the previous command lines and edit it, hit return
(render).  To change settings in scene, edit, save, go to command line,
(edit it) and render.

Now, there is also one thing common you make much hard on each platform:
Undo.  A typical editor will only allow you to undo your changes in
sequence, thus you always undo your ini_option settings at first.  In
addition, you each time have to scroll to change settings, also some editors
offer split views. And, did you notice that no usability is gained, to the
contrary, on each platform everything changes from the default behaviour all
programs offer which is a linear model, not the switching/scrolling all the
time.


Additionally, even if you can dismiss all these arguments as user
preference, look at the support problems:  Let someone add ini_option="+rq"
in the file. Now when you get a scene and start to render and it it terribly
slow, people will complain. Not to the author of the scene, but you know to
whom...
And what is about users who don't use command lines/ini files?  All three
platforms above offer powerful graphical user interfaces which do or may
offer comfortable dialogs to set options.  Those users first have to learn
command line settings in order to understand this, increasing slope of the
learning curve even more.  And it breaks user perception of a GUI which
should hide complexity (optional access to the command line is a plus of
course).
Further usability aspects are that it is not possible (technically) to allow
all kinds of settings with the "ini_option". This makes it even more
complicated to use without having to as the command line/ini files are just
fine.
And, as consistency is an issue, it is a valid (also not the strongest)
argument to ask:  Are there other (frequently used) programs which allow you
in command line systems that offer a similar interface?  The only one I can
come up with are compiler with makefiles (= ini files), the command line and
"# pragma " directives (= "ini_option").  However, is a compiler a end-user
program?


       Thorsten


Opinions express are my own and do not represent the POV-Team.

Post a reply to this message