In article <3dab1335@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

> Well, as far as a scripting language for 4.0 we have been considering to
> allow functions written in Perl or maybe Scheme would be a good idea.  That
> would make all those people happy who don't like the current scripting
> capabilities.  And users could extend the GUI this way from inside POV-Ray
> scene files.

Perl? Yuck. ;-)

I don't really know if it is relevant to this, but would OSA be of any 
use? (OSA == Open Scripting Architecture)
I don't know the status of OSA on non-Mac platforms, but if it is useful 
for this it would allow any language with an OSA plugin to be 
used...AppleScript, Ruby, JavaScript, probably Python and Perl, and 
others. I don't really know anything about OSA though, just an 
association that popped up when I read this.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

In article <3dab1246@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

> Well, for a GUI the stuff that is available as part of Mozilla looks very
> interesting.  Maybe increasing the level of abstraction and then just
> running POV-Ray as a backend to a webbrowser might be sufficient.  After
> all, there are plenty of editors out there, so no need for a dedicated
> GUI...

Maybe a plugin for jEdit...it seems to be a pretty good code editor, and 
it already has syntax coloring for POV. It'd just need to show rendering 
progress, error/status/info messages, and provide a render button/menu 
item. Making people download and install a separate Java program would 
be seen as pretty unfriendly, but I think jEdit would be better for this 
than Mozilla.

jEdit is a good example of what I was saying in the other messages 
though...it is a good program with a UI that will look familiar to 
someone on Windows, but it breaks a lot of Mac conventions. It even uses 
Aqua interface elements, but there is no way you could mistake it for a 
native Mac OS X program.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Thorsten Froehlich wrote:
> 
> Well, assuming some classes like below, one could remove user interface
> dependincies from the core code and just allow overloading of a few classes
> to transmit data...
> [...]

Actually my question was what in the end the user of POV-Ray will profit
from this.  So far i understand it will be a possibly larger variety of
frontends.  Are there other advantages?

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

Hello,

You know, I have to explain something.  My post was just a test.  In fact
what it describes already exists in POV-Ray 3.5 and is known under the name
POVMS and the document itself is rather old.  I just made this post in order
to get an idea what would happen should 4.0 design be discussed publicly at
all.  What I said has absolutely *no* relation to any team plans regarding
4.0.

I have to admit the results were rather surprising.  I had expected more
controversy or someone noticing immediately that it already exists.  What
happened is that there was little controversy (even when I started to make
really ridiculous suggestions such as using Mozilla as GUI, but maybe nobody
took that serious?) and nobody noticed that something like this already
exists.  Even those who have played with the source code very long.  And the
classes I posted later are almost an exact copy from povmscpp.h with all
reasonable or working features (such a arguments passed by reference)
removed.

In summary, I am not sure what to make out of the "result" I got with my
little experiment...

    Thorsten



The original document (actually only tiny little subset of its introduction)
as I had posted it back somewhere in the private POV-Team CompuServe GO
POVRAY forum back in 1999/2000:


This documents is to explain most issues regarding a proposal for new,
additional hooks to significantly better abstract the POV-Ray 3.5 core code
from outside, platform specific implementation details. The goal is a much
more powerful connection with Graphical User Interfaces. These hooks offer
an optional way to specify the render options without a command line and
control rendering as well as replacements and additions for the text stream
based input and output.

Up to version 3.1 POV-Ray only allowed text output and the main control
worked through the command line. Since version 3.0 two more powerful GUI
platforms - Windows and Mac OS - provide text editors but little abstraction
of the command line. However, both platforms surely present the main part of
the POV-Ray users today and a command line environment is no longer state of
the art. Especially Integrated Development Environment applications outline
a reasonable way to move traditionally command line driven programs like
compilers into the GUI age. However, providing IDE like features without
extensive support from the backend, the POV-Ray platform independent core
code, is very hard and resulted in errors and a (today) rather primitive
user interface designs. These new hooks will ease the creation of GUIs on
other platforms as well.

The hooks are designed to be very flexible and extensible. They will allow
future changes in the core code without breaking platform specific code or
forcing changes in it. It can simply ignore the additional information and
immediate changes in platform specific code of all platforms if some hooks
are changed can be avoided in these areas. Especially for a future C++
version of POV-Ray these hooks will be helpful and reduce or eliminate
changes to this crucial part of every platform specific user interface for
POV-Ray. Currently a set of C++ wrapper classes for the POVMS is
available.

In addition, the information about these hooks is very limited and some
documentation would be helpful for both sides, the GUI as well as the core
code developers, in order to prevent breaking old code by new changes. This
document contains the details of the POVMS functions, changes required in
each platform specific code and composition of the messages. It could be
used as base for some kind of introduction for those willing to port POV-Ray
to unsupported platforms. With the current and the constantly increasing
complexity of the hooks and other interface functions this has become a more
and more difficult task.

The POV-Ray Message System (POVMS) is a solution to the command line and
text input and output limitations for GUI systems. It offers a very easy to
extend control mechanism for POV-Ray. Existing command line driven POV-Ray
versions will only need little adjustment while the GUI platforms may need
(more) extensive changes in order to make use of the newly available
features and options. However, nearly full backward compatibility is
provided so GUI platforms do not need to be adapted immediately. A macro to
compile POV-Ray without POVMS is provided for platforms that do not use the
POVMS. This way no additional code is generated, and no time is wasted
creating messages that are not used.



____________________________________________________
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

Thorsten Froehlich wrote:
> 
> Hello,
> 
> You know, I have to explain something.  My post was just a test.  In fact
> what it describes already exists in POV-Ray 3.5 and is known under the name
> POVMS and the document itself is rather old.  I just made this post in order
> to get an idea what would happen should 4.0 design be discussed publicly at
> all.  What I said has absolutely *no* relation to any team plans regarding
> 4.0.

Well, that explains your quite strange answer to my question.

> I have to admit the results were rather surprising.  I had expected more
> controversy or someone noticing immediately that it already exists.  What
> happened is that there was little controversy (even when I started to make
> really ridiculous suggestions such as using Mozilla as GUI, but maybe nobody
> took that serious?) and nobody noticed that something like this already
> exists.  Even those who have played with the source code very long. [...]

I doubt there is much to conclude from this test.  First what it is about
is a part of POV-Ray not of much interest for someone starting to deal
with the POV-Ray source code.  The first time i stumbled across POVMS was
when i added some new element to the statistics and even that did not go
into depth.  And second you did not really start a discussion about
anything important.  As it seems you just described a few details about
something that already exists in POV-Ray.  Why should anyone have concerns
about that? ;-) 

If you really want to find out whether public discussion of things could
be useful for 4.0 development there is no other way but to try it.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <3DAC6C9A.AFBF4D0E@gmx.de> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

> I doubt there is much to conclude from this test.  First what it is about
> is a part of POV-Ray not of much interest for someone starting to deal
> with the POV-Ray source code.  The first time I stumbled across POVMS was
> when I added some new element to the statistics and even that did not go
> into depth.  And second you did not really start a discussion about
> anything important.  As it seems you just described a few details about
> something that already exists in POV-Ray.  Why should anyone have concerns
> about that? ;-)

Well, yes, a flame war or someone noticing that it already existed would
have been far more conclusive :-(

> If you really want to find out whether public discussion of things could
> be useful for 4.0 development there is no other way but to try it.

The problem is that if that would be done and we get burned, then we got
burned permanently.  I don't want to have to answer the (as I expect it)
resulting misunderstandings for the next half decade ... the problem is we
can't keep the usual group of general users from reading such public
discussions and getting completely misdirected :-(  No matter how big the
disclaimers ;-)

I am already expecting somebody tell me in a few weeks that I suggested Perl
or Scheme as scripting languages for 4.0 also that was just such a clear
joke...


    Thorsten


____________________________________________________
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

> In summary, I am not sure what to make out of the "result" I got with my
> little experiment...

It sounds like a case of "the emperor's new clothes" to me.  Perhaps 
those who did notice strange things about your post (like that there 
wasn't anything new in it, and that you were suggesting things totally 
out of character with POV development) just thought, "No one else seems 
to find it strange, so perhaps I'm imagining it."

Nice experiment though, if not particularly successful.

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3dac7374$1@news.povray.org...
> I am already expecting somebody tell me in a few weeks that I suggested
Perl
> or Scheme as scripting languages for 4.0 also that was just such a clear
> joke...
>
>
>     Thorsten
>

I did think that odd coming from you, however what it reminded me of was
this IRTC winner that was written with a perl script.

http://oz.irtc.org/ftp/pub/anims/1998-07-15/marble.txt

Post a reply to this message

On Tue, 15 Oct 2002 20:11:23 +0200, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> You know, I have to explain something.  My post was just a test.

In fact I think it was small success in the test for one reason. I somehow
felt there was always fear in Team about talking about internals (not just
answers to questions). But finally you wrote something and there was no
flaming in response, no critique. Nobody said "better optimize isosurfaces
speed", "work on bugs", "POV-Ray is outdated" or "The Team is lazy and rude". 

> In fact
> what it describes already exists in POV-Ray 3.5 and is known under the name
> POVMS and the document itself is rather old.

Don't you think that after two months of sources we are concerned on bugs, and
"todos" gathered during previous year of waiting for 3.5 ? There is over 90
files in package (not counting platform specific) and less then 80 days since
sources are available. How we could learn ideas so fast when you worked over
them two years?

And... I'm still thinking serious about your initial post. Not only becouse
real implementation but becouse of inspirations I get to extend knowledge. You
can say "we have to hold decisions in team becouse there is nobody brave to
discute or nobody with apropriate skills". But we learn all the time. I think
I'm not only person who started diging net for some references about design.
So please don't stop, just cheat less with every next post ;-)

ABX

Post a reply to this message

ABX wrote:
> 
> ..."better optimize isosurfaces speed", ...
> 

Actually that would be...

;-)

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message