> A comment from someone who actually knows what they are talking about would be
> useful about now....

Agreed (no offence intended)

Post a reply to this message

"Harold" <bai### [at] 3dculturecom> wrote in message
news:3e416b79$1@news.povray.org...

> POV script files and shell out to POV-Ray, but I've never
> seen any reason to hide the interface. I do think it is possible
> using the command line options, but why bother?

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

Post a reply to this message

In article <3e416dc4@news.povray.org>, git### [at] wanadoofr says...

> 3e4164ea@news.povray.org...
> > No.  Read the license.  That isn't allowed.
> 
> Before jumping to conclusions about potential wrongdoings and license
> violations, he may have legitimate reasons to do so.
> I'm launching POV-Ray from Access to create graphics for the database I'm
> running at work. I'm using the DOS version of POV-Ray 3.1 to avoid having
> the splash screen pop up every time I create a graphic (I've done 3000 of
> them so far). I'm the sole user, so I definitely don't hide to myself the
> fact that I'm using POV-Ray ;-)
> 
> G.
> 
> 
> --
> **********************
> http://www.oyonale.com
> **********************
> - Graphic experiments
> - POV-Ray and Poser computer images
> - Posters
> 
This brings up an issue of something I was considering. The idea is in 
essence this:

Make a pge that also provides:
  A) Built in display window.
  B) Some basic controls like stop and pause/resume.
  C) Settings for image directory to use and location of the .pov file.
  D) Implements a COM interface, making it an insertable control in other 
programs, with the following calls:
    1. FTP file and render.
    2. UUDecode stream to file and render.
    3. Stop.
    4. Pause/resume.
    5. Set option.

The idea being to provide the control for free, but since the interface 
is implemented by the control itself, it can display the normal text 
streams in the display window, then switches to a graphic one when 
rendering starts (probably in a tab strip design). Thus it will always 
show the same info about POVRay version, etc as you would see in the 
main editor. Since the control is free, it could be included as a 
supported control with a program, but not as part of the program itself.

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...

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

3e42bc46@news.povray.org...
> "Harold" <bai### [at] 3dculturecom> wrote in message
> news:3e416b79$1@news.povray.org...
>
> > POV script files and shell out to POV-Ray, but I've never
> > seen any reason to hide the interface. I do think it is possible
> > using the command line options, but why bother?
>
> the thought did occur - hey, Gilles, Mark, why do you need to hide it?
What
> happens if you don't?

The splash screen was a nuisance as it hid the main Access window, but the
main issue was Povray not exiting at the end. When launching a batch of
renders through VB this really caused problems. These could be solved,
perhaps, but using the old console version was just easier.

G.


--
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

> 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