In article <38CAE718.66F06330@mac.com> , Henry Penninkilampi <htp### [at] maccom>
wrote:

> Greetings!
>
> My experience with POVRay is all of about four hours long, so forgive me
> if I jump right in and make a fool of myself.

No problem.

> The POVRay Mac OS Read Me says plans are afoot to "Completely rework the
> application model... POV-Ray engine should be a simple rendering
> application,  separate from the UI.  This could pave the way to use it
> as a rendering plugin for QD3D or modeling  applications, and for
> network rendering farms."  All I'd like to say is that I am STONGLY IN
> FAVOUR of this approach.
>
> Whenever the UI is tightly coupled to the functionality of a program,
> flexibility is lost.  Bryce is a classic example - an otherwise
> brilliant work confined by a staggeringly rigid UI.  I'd prefer the same
> mistake not be repeated with POVRay.
>
> The normal response by Mac developers is to make an application
> "scriptable".  Now AppleScript is fine and dandy when it comes to
> automating repetitive processes, but that's *not* what is required by
> POVRay.  There are precious few repetitive tasks in setting up a scene,
> and macros would seem to address the issue quite adequately when it
> comes to multi-frame movies.

Hmm, I think you misunderstood our idea of AppleScript support here: It is
about controlling the application to start renders, open files for editing,
etx - the usual stuff.  We never wanted to do anything else, the part that
does the parsing and rendering in POV-Ray is cross-platform and separate
from the different GUIs in any possible way.

> What, then, is the point in investing time implementing robust
> AppleScript support in the Mac version?  Very little, if you ask me.  My
> suggestion would be to only implement the most minimal AS Dictionary -
> enough to open an arbitrary .pov file (which should trigger reading of
> the associated .ini file) and report back a standard result code along
> with a string containing much of the statistical information that is
> currently returned to STDOUT.

POV-Ray 3.5 will be a recordable application.  AppleEvents are a very good
method when it comes to designing a new application (the Mac 3.5 frontend is
a full rewrite).  If properly implemented this creates a much more logical
and simpler separation of the GUI code and the actual data access.

> Not only does this mean that POVRay remains flexible, but it means that
> there is that much less difference between the Mac version and the
> Unix/Windows versions - and that can only be good from a maintenance
> point of view.  I can think of a lot of better things to do with time
> than maintain marginalised AppleEvent-handlers which Apple seem
> hell-bent on breaking every so-often.

Hmm, I have no recollection of Apple ever breaking any Apple Event code.


     Thorsten


____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message