"Jonathan Wooldridge" <jwo### [at] attbicom> wrote in message
news:3d0ba83b$1@news.povray.org...
> Clicking on a box that says "Don't ask again" should result in not being
> asked again. It fails to perform as advertised. So IMHO it is a bug, not a
> feature: An old bug, yes, but an old bug is still a bug.
>
> Isn't this what testing is all about?

You are not asked again while the program is running. It does perform as
advertised. There is more than one way to interpret the dialog box's text.



IIRC, it is not a bug, it is a design decision that was discussed at length
somewhere and some when in these newsgroups. Gnnnnn ! I began downloading
all of the 35910 messages in p.general to find the thread... but I just
calculated this download will complete in around 8 hours, so I'll just post
this now. (I am not even sure it was in p.gen...)





Povingly,



Philippe

Post a reply to this message

"Philippe Debar" <phd### [at] belgacomnet> wrote in message
news:3d0bccb2@news.povray.org...
>
> "Jonathan Wooldridge" <jwo### [at] attbicom> wrote in message
> news:3d0ba83b$1@news.povray.org...
> > Clicking on a box that says "Don't ask again" should result in not being
> > asked again. It fails to perform as advertised. So IMHO it is a bug, not
a
> > feature: An old bug, yes, but an old bug is still a bug.
> >
> > Isn't this what testing is all about?
>
> You are not asked again while the program is running. It does perform as
> advertised. There is more than one way to interpret the dialog box's text.
>
> IIRC, it is not a bug, it is a design decision that was discussed at
length
> somewhere and some when in these newsgroups. Gnnnnn ! I began downloading
> all of the 35910 messages in p.general to find the thread... but I just
> calculated this download will complete in around 8 hours, so I'll just
post
> this now. (I am not even sure it was in p.gen...)
>

Hmm...I would suggest that this ought to be more of a user-preference type
of thing than a design decision; similar to hot-key assignments. I know how
easy it is to hard-code hot-keys, vs create dynamic binding so the user can
do their own keystroke layout.

But it could be easy to add an .ini setting along the lines of:
FileSaveStatus=always

and have it default to "ask" for novice users.

Post a reply to this message

"Jonathan Wooldridge" <jwo### [at] attbicom> wrote in message
news:3d0c2835@news.povray.org...

> Hmm...I would suggest that this ought to be more of a user-preference type
> of thing than a design decision; similar to hot-key assignments. I know
how
> easy it is to hard-code hot-keys, vs create dynamic binding so the user
can
> do their own keystroke layout.

Mmmmh... You _can_ define key mappings, just not all of it (see doc 1.6.3
and 1.6.4). The "not all of it" is clearly because of programming
difficulty. I do not believe that setting a persistent flag is so much of a
problem (but I am no programmer): it is already done for many settings
(e.g. : remembering rendering settings, opened docs, queue settings, ...).





> But it could be easy to add an .ini setting along the lines of:
> FileSaveStatus=always
>
> and have it default to "ask" for novice users.



I know and IIRC (I still did not find the thread neither in p.general nor in
p.windows... I asked Outlook Express to download everything in these two
groups, but I think there is a bug there, as the first thread I have in
p.gen is from 1994, then  it jumps straight to december 1996... also I
suspect the search command in OE not to work properly on such large groups),
that kind of solution was proposed / asked for at the time and it was
decided to keep it the way it is. (though I do not know exactly why...)



Overall, it is a very minor annoyance. As I already made mistakes with that
feature, esp. with the save all + don't ask again, I can guess one of the
reasons.



As for your solution, I believe that (1) it would not be allowed to add
platform-specific switches to the ini file / command line language and (2)
putting this in an ini file would mean that you could have your settings
changed by an imported scene, which is definitely bad.



This issue was decided ages ago and I think that the silence of the pov-team
in this thread clearly show that they consider this question as closed.
Furthermore, as this is not a bug but rather a feature wish, I believe that
it is far too late to express such a wish and here is not the right group.
Why not p.unofficial.patches ? (better wait till the release of the source
code...)





Povingly,





Philippe

Post a reply to this message

Philippe Debar wrote:

> I asked Outlook Express to download everything in these two groups, but I
> think there is a bug there, as the first thread I have in
> p.gen is from 1994, then  it jumps straight to december 1996...

I guess someone posted with a wrong date.
-- 
Felix Wiemann

Post a reply to this message

I'll chime in on this too. Yep, design decision I'm fairly certain. If the
program were settable to never ask whether to save a changed file a person
could make a big mistake and lose data because of forgetting their setup
between sessions. Of course they'd need to be running POV-Ray with the
Editor menu set to not Create Backups and not Allow Undo After Autosave. But
that's something you wouldn't want to happen by accident. Probably too late
in the game to be rethinking this.

bob h

Post a reply to this message

"bob h" <omn### [at] charternet> wrote in message news:3d0d412d$1@news.povray.org...
> I'll chime in on this too. Yep, design decision I'm fairly certain. If the
> program were settable to never ask whether to save a changed file a person
> could make a big mistake and lose data because of forgetting their setup
> between sessions. Of course they'd need to be running POV-Ray with the

This is in fact the exact reason I did it that way. I don't want folks bitching
that we 'overwrite their file' because they set "don't ask again" some years in
the past then accidentally saved over a file that they wanted to keep.

-- Chris

Post a reply to this message

"Chris Cason" <new### [at] deletethispovrayorg> wrote in message
news:3d0d515d@news.povray.org...

> This is in fact the exact reason I did it that way. I don't want folks
bitching
> that we 'overwrite their file' because they set "don't ask again" some
years in
> the past then accidentally saved over a file that they wanted to keep.
>
> -- Chris
>
Doesn't it seem counter-intuitive to you to press "don't ask again" and be
asked again?
"I'm just going to ask you again anyway, just in case you didn't mean it
this time."

It would be nice to be able to turn this off. You could post a disclaimer of
responsibility: "you have de-activated a safety feature, and may
inadvertently overwrite one of your files. You can re-instate the safety
feature at any time in the options/whatever tab"

Post a reply to this message

"Jonathan Wooldridge" <jwo### [at] attbicom> wrote in message
news:3d0d7629$1@news.povray.org...
> Doesn't it seem counter-intuitive to you to press "don't ask again" and be
> asked again?

Perhaps. But my experience with supporting POV-Ray for so many years shows me
that no matter how we word the warning, someone somewhere won't pay attention
and will then complain to us.

I will, however, alter the wording of the dialog to say "don't ask again this
session", so it is clear that this is intentional.

-- Chris

Post a reply to this message

"Chris Cason" <new### [at] deletethispovrayorg> wrote in message
news:3d0eee79@news.povray.org...
>
> "Jonathan Wooldridge" <jwo### [at] attbicom> wrote in message
news:3d0d7629$1@news.povray.org...
> > Doesn't it seem counter-intuitive to you to press "don't ask again" and
be
> > asked again?
>
> Perhaps. But my experience with supporting POV-Ray for so many years shows
me
> that no matter how we word the warning, someone somewhere won't pay
attention
> and will then complain to us.
>
> I will, however, alter the wording of the dialog to say "don't ask again
this
> session", so it is clear that this is intentional.
>
> -- Chris

It's too bad the forces at work are competetive between Coders and Users. By
which I mean that an improvement penalizes one of the two players. I am
saddened that there is no recourse to this.

Is it possible to improve the product? By which I mean that both the Coders
and the Users suffer less? This would be a genuine improvement.

Post a reply to this message

"Jonathan Wooldridge" <jwo### [at] attbicom> wrote in message
news:3d0fc392$1@news.povray.org...
> Is it possible to improve the product? By which I mean that both the Coders
> and the Users suffer less? This would be a genuine improvement.

The proper way to fix this is to not require that a file be saved at all
prior to a render starting (rather than have some auto-save feature that
can be turned on and forgotten about). This is in fact how v3.0 worked, which
used a different editor (which stored the edit data as a flat memory structure;
this was very inefficient but handy for doing a render from memory). It was
never necessary to save a file before rendering.

This is not easily possible with codemax, since it stores the file as a linked
list. This is not an impossible problem to get around and I will probably do it
one day. But not for 3.5 release.

-- Chris

Post a reply to this message