> the thought did occur - hey, Gilles, Mark, why do you need to hide it? What
> happens if you don't?

I am using the Unix version. It has only two visible outputs.
One is the preview window which I disable for these purposes.
The other is a very verbose stream that goes to stdout and
hence appears in my shell. I guess I COULD hide that by
piping it to /dev/null but I have not bothered so far: It is
easy enough to ignore the shell output because at that time I
work with a different shell.

The use in question is a run of make, some script, or some other
program that produces MANY images using povray. If, as the
license suggests and the Unix version does not implement, it is
required to let the user really know that povray is running by
presenting some popup each time povray is called, I would not be
able to work in the meantime. Every two minutes or so another
popup would bother me, just like ad-infested websites do.

It is acceptable, I think, to have a popup of that kind if you
are working on ONE scene that takes long to render and you give
it a try only every two hours. But it is not acceptable if, as I
do, you use povray as the backend of some program.

Post a reply to this message

In article <MPG.18ac6f4e1bd9e05c989720@news.povray.org>, 
sha### [at] hotmailcom says...
> I think this would theoretically resolve the issues in the license as it 
> stands, but I really don't understand how the bloody GUIExt interface 
> works and if those streams even available to the extension (something 
> that would tend to blow a hole in my idea). I don't really want to spend 
> a lot of time trying to figure the interface out if I can't feed those 
> streams through it or this idea has some unintentional defect with regard 
> to the licensing...
> 


Ok.. Maybe bloody was a bad choice of words there. However, this is 
supposed to be an understandable and I assume easy to use interface. The 
problem is that no example exists that really shows what each of the 
functions in it do, there is no documentation in the code that spells 
out, even in a general sense, what its bits are pieces are designed for, 
the only available working examples are A) an incomplete 'example' that 
doesn't do or entirely explain anything, B) a pure console based version 
that lacks most of the key features of the interface I need to use and C) 
the one for Moray, which they don't supply source for and doesn't answer 
my question about what text streams are actually supported. Right now 
this COM bridge is an interesting feature I would like to add to what I 
am doing, not something so critical I plan to spend days rummaging 
through the POVRay source trying to figure out (even if it looks like 
that is the only way I will get any answer).

I need really only two questions answered:

1. Would this design be likely cause a licensing issue.
2. Do the same text streams that show up in Codemax for the rendering 
information also get fed through something in the GUIExt interface?

I have looked at the general code and from what I can tell the answer to 
#2 is likely to be 'no', which would be seriously inconvenient. Then C++ 
gives me a headache to read, so... lol

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

On Thu, 6 Feb 2003 13:40:35 -0000, Tom Melly wrote
> Windows version has a GUI-extension API and the ability to replace the text
> editor.

How do I do this? I disliked the editor in Povray for windows from the
very first day, mostly because of some small things (for example the
behaviour of the Home and End keys appears brain-damaged to me), but
also because a longterm vim-user will naturally regard all other
text-editors as inferior. I would *love* to use vim as editor inside
POV-Ray for Windows. Is that possible, and if so, how? In particular, do
I have to build a custom version of POV-Ray?

-- 
Timon Christl <me### [at] christltimonde>
AIM: sgmfragcollector
ICQ: 172280602

Post a reply to this message

"Timon Christl" <chr### [at] belindafmiuni-passaude> wrote in message
news:3e4765d7$1@news.povray.org...

> How do I do this? I disliked the editor in Povray for windows from the

No idea - I was just quoting from the docs, and I always use the standard
interface. However, iirc it's not hard to use another text-editor and have a
macro/whatever run pov from the command line against your script.

Check under 5.1.1 from a quick example.

Post a reply to this message

On Mon, 10 Feb 2003 09:49:26 -0000, Tom Melly wrote
> "Timon Christl" <chr### [at] belindafmiuni-passaude> wrote in message
> news:3e4765d7$1@news.povray.org...
> 
>> How do I do this? I disliked the editor in Povray for windows from the
> 
> No idea - I was just quoting from the docs, and I always use the standard
> interface. However, iirc it's not hard to use another text-editor and have a
> macro/whatever run pov from the command line against your script.

Hm. This will work if POV doesn't grab the focus at all. I don't want to
hide POV completely, but just to keep it in the background so that I can
continue editing POV-Code without any interruption. I guess I should
dust off my C compiler and compile a custom version just for my private
pleasure.

-- 
Timon Christl <me### [at] christltimonde>
AIM: sgmfragcollector
ICQ: 172280602

Post a reply to this message

In article <MPG.18b0622aaa59552c989725@news.povray.org>, 
sha### [at] hotmailcom says...
> I need really only two questions answered:
> 
> 1. Would this design be likely cause a licensing issue.
> 2. Do the same text streams that show up in Codemax for the rendering 
> information also get fed through something in the GUIExt interface?
> 
> I have looked at the general code and from what I can tell the answer to 
> #2 is likely to be 'no', which would be seriously inconvenient. Then C++ 
> gives me a headache to read, so... lol
> 
Ok.. I am a total idiot. Looking again the answer to #2 is, yes I can 
feed that info through it, but that still leave question #1.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message