make an option to use the current or neXtgen IDEs, or I'm asking too 
much? please let me know in either case.

Best Regards.

Saul

Post a reply to this message

Saul Luizaga <sau### [at] netscapenet> wrote:
> make an option to use the current or neXtgen IDEs

what is that supposed to mean?  Do you mean to use an IDE to type povray SDL
code?  What has povray the renderer to do with that?  Povray even comes with a
pretty nice IDE on its own on Windows.

Povray SDL is just a programming language and if there is a plugin for some IDE
which handles povray SDL, then go for it.  Vim is a text editor and it already
comes packed with a pretty nice syntax highlight mode for povray SDL.  Couple
that with vim's textual completion facilities and macros and you're sold.
There's also a plugin for Eclipse which handles povray SDL -- Povclipse.  Not
to count visual modellers, not IDEs, which either export a povray scene file or
nicely integrates with it -- Blender and Wings3D the former, KPovModeller and
Moray the latter...

Povray has nothing to do with any of these projects.  And it shouldn't.

Post a reply to this message

nemesis wrote:
> Saul Luizaga <sau### [at] netscapenet> wrote:
>> make an option to use the current or neXtgen IDEs
> 
> what is that supposed to mean?  Do you mean to use an IDE to type povray SDL
> code?  What has povray the renderer to do with that?  Povray even comes with a
> pretty nice IDE on its own on Windows.
> 
> Povray SDL is just a programming language and if there is a plugin for some IDE
> which handles povray SDL, then go for it.  Vim is a text editor and it already
> comes packed with a pretty nice syntax highlight mode for povray SDL.  Couple
> that with vim's textual completion facilities and macros and you're sold.
> There's also a plugin for Eclipse which handles povray SDL -- Povclipse.  Not
> to count visual modellers, not IDEs, which either export a povray scene file or
> nicely integrates with it -- Blender and Wings3D the former, KPovModeller and
> Moray the latter...
> 
> Povray has nothing to do with any of these projects.  And it shouldn't.

OK, let me explain why I suggested this:
-neXtgen is a IDE for POV-Ray, so is dedicated to interact with POV-Ray 
and ONLY with POV-Ray. SO I thought since I have tryed and is nice, I 
would like to use the editor but have POV_Ray handy, the obvious 
solution is to integrate neXtgen into POV-Ray as an alternative built-in 
editor.

  I know that this should be ALOT more difficult than I can think of, 
that's why I wanted to know either way, if it was feasible or not. I 
guess not since looks like POV 4 is taken a lot of time and effort from 
the POV-Team. I just suggested in case they wanted it as an alternative 
editor since the POV-Team is making a "new" POV-Ray, remaking 
copyrighted source, so this could be inserted in this stage of POV-Ray's 
development I presume, since CODEMAX is a commercial plug-in doanted to 
POV-Ray.

Regards.Saul.

Post a reply to this message

Saul Luizaga <sau### [at] netscapenet> wrote:
> -neXtgen is a IDE for POV-Ray, so is dedicated to interact with POV-Ray
> and ONLY with POV-Ray. SO I thought since I have tryed and is nice, I
> would like to use the editor but have POV_Ray handy, the obvious
> solution is to integrate neXtgen into POV-Ray as an alternative built-in
> editor.

Povray is a renderer.  Integrating a renderer into your software really just
means to call the renderer to render a scene file or cancel the rendering.
Trivial interprocess communication in most OSes handle that just well:  no need
for DLLs, APIs etc.

Your IDE/software/whatever is not so much really intending to interact with
povray as it is supposed to interact with povray SDL files.  What use is for
povray to come with 5 different editors/IDEs to suit someone needs?  Just
download it and use it together with povray.  Heck, it's difficult enough to
get Moray into schedule, let alone more external stuff.  Besides, you'll need
Qt... :P

Post a reply to this message

> Trivial interprocess communication in most OSes handle that just well:  no need
> for DLLs, APIs etc.

Are you a developer? do you know this from experience? Are you part of 
the POV-Team or TAG-Team?

> Your IDE/software/whatever is not so much really intending to interact with
> povray as it is supposed to interact with povray SDL files.  What use is for
> povray to come with 5 different editors/IDEs to suit someone needs?

Any developer can correct me but I think the more tightly embedded a 
application is into another the better.

Post a reply to this message

>> Your IDE/software/whatever is not so much really intending to
>> interact with povray as it is supposed to interact with povray SDL
>> files.  What use is for povray to come with 5 different
>> editors/IDEs to suit someone needs?
> 
> Any developer can correct me but I think the more tightly embedded a
>  application is into another the better.

At the very least, this seems contrary to the philosophy behind 
Unix/Linux command-line tools, where the goal as far as I know is to 
develop specialized tools very good at what they do, then chain them 
together according to what you need.

-- 
Vincent

Post a reply to this message

Saul Luizaga <sau### [at] netscapenet> wrote:

> > Trivial interprocess communication in most OSes handle that just well:  no need
> > for DLLs, APIs etc.
>
> Are you a developer? do you know this from experience?

yes, I develop software for a living.

> Are you part of
> the POV-Team or TAG-Team?

no, but it is trivial to call an external application as a subprocess.  In this
case specifically, it's even easier because all you got to do is call povray
with the right command-line switches to render a file.  And if the user press
the Cancel button or something, signals that subprocess a halt.  There's no
complicated communication between the callee program and the caller other than
the caller asking the subprocess of the callee to do some specific task.  It's
all up to the renderer from there on.

> Any developer can correct me but I think the more tightly embedded a
> application is into another the better.

no, the worse:  it creates huge monolithic applications which as very hard to
debug and maintain.  Besides, for this specific task -- asking povray to render
or stop -- what advantage you'd get from it?

Post a reply to this message

Thank you for the guide lines nemesis, very interesting, didn't know 
many of this stuff. But what I meant is that the editor could be more 
than just a start or stop of POV-Ray, could be a config manager(memory, 
defaults, output format, etc) and all other stuff a normal IDE does, 
since, as you maight know, POV-Ray is only a DOS-line Raytracer in its 
core.

  Anyway, I thought that the IDE did some special tasks with the 
renderer pre- and at runtime, like serving files, parameters, config 
preferences and other stuff it may need but looks like I thoght wrong. I 
figured that both passed info to each other in special may: with shared 
variables or other data structures directly in memory.

  A few questions please(I've always wondered about theses):
1) DDE is sucha practice?
2) Why does windows have sucha implementation for programs?
3) and to complete the previous question. What are the most effective 
ways to pass parameter without using a command line. Command line looks 
like rustic/rough way to pass data to another program, should both 
programs communicate with each other directly in memory? I figure that 
they could have specialized functions to ask each other attention to 
communicate (pass data/parameters, request functions/calculus or any 
other unteraction).

  Pardon my ignorance.

Regards.
Saul.

Post a reply to this message

Saul Luizaga <sau### [at] netscapenet> wrote:
> But what I meant is that the editor could be more
> than just a start or stop of POV-Ray, could be a config manager(memory,
> defaults, output format, etc) and all other stuff a normal IDE does,

A config manager could just write a configuration file and pass that on to
povray.

> I
> figured that both passed info to each other in special may: with shared
> variables or other data structures directly in memory.

It may sound neat, but is just another burden.  You'll need to store user
preferences in some file anyway, so why not just pass that to the external
program?

> 1) DDE is sucha practice?

I'm not used to it, but it seems like a Windows specialized API for graphical
program developers who are too lazy to deal with command-line.

> 2) Why does windows have sucha implementation for programs?

Windows has its own ways of doing things.  They're specially good at reinventing
the wheels just in order to break compatibility with the way other platforms do
it.

> 3) and to complete the previous question. What are the most effective
> ways to pass parameter without using a command line. Command line looks
> like rustic/rough way to pass data to another program, should both
> programs communicate with each other directly in memory?

Command-line is not rustic:  it's a quick way to ask the program to behave in
certain ways without having to editing config files, to use a graphical dialog
box or  by modifying source code.  It's also great for assembling quite useful
scripts and utilities without coding a complete new application.

You can certainly use some component application server or simply some DLL and
communicate through API calls in memory rather than via slower IO interprocess
communication calls.  It's just not worth the trouble when the task at hand is
essentially a batch one rather than an interactive one.

Post a reply to this message

features / integrations.


keywords, operators, etc. that could be used by syntax coloring editors or
command completion editors.


across processes or machines.  Maybe they would take a stream that contained
simplified parameters such as file names, computers, max rendering times,
sizes, quality, etc and would generate an output stream containing command
lines to accomplish that.


Assemble, Progress.  Start might invoke processes and simply stream output with

use that streamed output to perform their functions.


allow for easier reuse.  It might have options like recursive to get
sub-objects/attributes.  This can be done by hand, but when assembling an
object means searching and extracting relevant text from ever increasing
numbers of source files, a utility seems useful.  Also adding rendering
throw-away metadata tags could greatly extend the usefulness of these
operations.  Maybe keywords like: Name, Description, Author, Category, Type,

lot and get a lot of noise.


the idea of scene or file level metadata tags, this could allow managing SDL
files much quicker.  Consider just the sample scenes.  Finding if one of those
scenes has a specific asset is an exercise in memory and perseverance.  This
nests nicely with the above utility for extracting the asset once found.  In
addition having these capabilities would allow for indexers to enhance the
speed of reuse for an asset.  This could even be used to extend the existing
#include to provide location independent file inclusion.  This could further be
enhanced by having one or more XML/ini files containing library locations and
descriptions for my installation.  This would work on the same lines as Library
Paths, but could extend it.  Currently libraries paths are searched in the order
they are listed.  If library paths were named, you could perhaps include a file
something like: fantasy:lighting.pov.  Where fantasy might end up being a


Anyway, just my thoughts.  If any of the ideas seem useful, I would be willing
to work on cross platform versions of them.  Being a bit of a casual PovRay
user I could use help with locating any existing similar GPL projects and with
additional ideas for extending their usefulness / reusability.

Post a reply to this message