Am 20.12.2012 10:50, schrieb denis.beurive:

> When porting a software, user interface is often painful. Furthermore, Povray's
> user interface is essentially a code editor. It could be replaced by any serious
> code editor, such Eclipse.

As a matter of fact, there is no such thing as "the" POV-Ray user 
interface; there is a GUI for Windows, and there's a command-line 
interface for Linux. (You can also start a POV-Ray render from a Windows 
command prompt, but it's a bit messy because it always starts the GUI, 
and/or delegates the render to an already running instance of it.)

>  From my point of view, there is no reason to maintain the Povray's user
> interface.

It is maintained as a convenience for Windows users: While good code 
editors are part of every Linux distro, Windows doesn't come with one 
out of the box.

> I guess that Povray does not use any OS dependant library for the rendering.

Perfectly true.

> We could see the renderer as a compiler.

It is already seen as such.


> Povray's language for scene description is quite archaic (for today's
> standards).
> My impression is that it was first a "descriptive language" (such as XML).
> Then variables and macros were added, to make it a very basic "programming
> tool".

Yes, that is indeed the case.

> If we can isolate the renderer code, we could interface it with languages such
> Perl, Python, PHP... All the parsing and the hard work would be handled by the
> (Perl, Python, PHP) interpreter. Furthermore, we could use the entire collection
> of libraries available for these languages.

The collateral damage of this would be a fragmented user community: Some 
would use Perl, some Python, etc.; and it would be impossible to 
exchange parts of scenes between those factions.

It would also leave new users to the question, which language to use, 
and require them to install a 3rd-party tool (the compiler or 
interpreter for that language).

The only way around this is retaining /one/ inbuilt language as /the/ 
standard language for POV-Ray scene descriptions.


Furthermore, creating a scene is still primarily descriptive work, while 
all of the mainstream languages are imperative in nature, making them 
comparatively cumbersome for the job.


I'm therefore convinced that the proper thing to do is a thorough 
overhaul (or even redesign) of the SDL.

Post a reply to this message