Nathan Kopp schrieb in Nachricht <36EDDB2A.6C1C618D@Kopp.com>...
>Twyst,
>
>I really like your concept (I've been following this thread for a bit).  I
>think that you'll a bit more powerful of a scripting language, though, in
>order for a plug-in to be able to do anything useful.  Trying to jump all
>the way to javascript (or something like it) would probably be a bit
>difficult (unless there's open source code available to parse and execute
>it already).  Maybe something a bit simpler, but something that is
>designed for growth.


There are a few simple free macro languages on the net. If I could only
remember where I had seen them. One would only have to write a plugin dll
wrapper for them. I also like the concept. This would be like Word-Basic as
it was before Office 97: a simple macro language for Moray.

--
Rudy

Post a reply to this message

Johannes Hubert wrote:

> Ph Gibone wrote in message <36ed4ab0.0@news.povray.org>...
> >
> >To make things clear, when I wrote about a scripting language for Moray I
> >thought that it would be very convenient to be able to write a plugin even
> >if you don't know C, C++, WIndows SDK,
> [snip]
>
> That is where the misunderstanding was, I think:
>
> Twyst was thinking of a plug-in that would offer a simply scripting-language
> to make part of the plug-in interface available to non (C/C++)-programmers,
> or at least available without the need of compiling and building DLLs.
>
> Your idea was to change/adapt the plugin interface of Moray so that it would
> facilitate writing plugins in Java instead of C/C++.
>
> Both are good ideas, but different ones, in my view.
>
> You idea may be possible to realize in two ways: First (of course) would be
> for Markus and Lutz to change the plugin-interface to allow interfacing to
> Java (frankly, I don't see this happening ;-)
> Or someone could write a Moray plugin in C++ that is actually only a wrapper
> for the plugin-interface, and that exposes all interface methods and members
> to a similar Java interface.
>
> But the main question is: Is this needed?
> Are there really people who are dying to write a Moray plugin and only don't
> do so because they would have to program in C/C++? And would the same people
> start programming like hell, if they could do so in Java instead?
> I don't think so, because even in Java it would still require some
> above-beginner-level programming skills, and people with such skills are
> usually not bothered by the fact of which language they would have to use
> for a certain task.
>

I think that such a plugin would, perhaps, be quite useful. I am a Moray user,
with a decent level of knowlege about C++(but only in DOS), and I want to write
plugins for Moray. Also, I don't have VC++ 5.0, so thats another thing that I
can't do with them.

I think that all you need for the given plugin is this:
The dialogue box.
The export of the dialogue box.
The wireframe of the object created by the dialogue box.

The first two ought to be pretty easy, even for non-programmers, as long as they
have at least a decent familiarity with POV-Code. The last section would be a
bit harder to write, but nonetheless, it would be easier than having to write a
windows program. By encapsulating this code, I think that you open up Moray to a
great amount of new plugins. Everyone who writes those little plugin requests
will be able to at least TRY to write new plugins, without having to buy a major
C++ compiler or something similar, as well as a few books on programming.

I think, though, that you may just want to create a bunch of .h files, or
libraries, or soemthing, so that you can compile the plugin before hand. But
that would require a commercial compiler, so strike that idea.

> Java has other disadvantages for a project like this: The number of
> different VM's that all behave slightly different would require quite some
> testing of such a plugin, to make sure that it runs everywhere. Or the
> author could require a certain VM (and a certain version of it) to be
> installed, adding more installation burdon to the end-user.
> Then there is the general sluggishness of Java (granted, it can be overcome
> by the right programming, but still...).
> Also the memory usage: Expect your VM (with a program loaded and running) to
> use up at least 5-10 Megs of RAM - memory that is no longer available for
> Moray (and more importantly POV-Ray) anymore.
> And last not least: The look and feel (even with Swing's Windows L&F) would
> be different between Moray and Java plugins, making them appear less
> "seamless".
>
> OK, just to clear that up (and because Philippe always stresses that he is
> *not* a "Java-fan" ;-) I want to stress that I am not a Java "basher":
> Actually, I earn my living by programming in Java and I like it (but it also
> makes me very aware of its many shortcomings).
>
> Greetings,
> Johannes.



--
Only I can prevent narcissism!

Post a reply to this message

Johannes Hubert wrote:
> 
> Ph Gibone wrote in message <36ed4ab0.0@news.povray.org>...
> >
> >To make things clear, when I wrote about a scripting language for Moray I
> >thought that it would be very convenient to be able to write a plugin even
> >if you don't know C, C++, WIndows SDK,
> [snip]
> 
> That is where the misunderstanding was, I think:
> 
> Twyst was thinking of a plug-in that would offer a simply scripting-language
> to make part of the plug-in interface available to non (C/C++)-programmers,
> or at least available without the need of compiling and building DLLs.

That would be a pretty nice thing to have - especially considering the
size of today's compilers...

One thing seems like an obvious alternative to the suggestions made so
far - use the Windows Scripting Host (WSH).  Already has support for
VBScript and JScript...

See http://msdn.microsoft.com/scripting/ for details.  Why only have one
scripting language available.


> ...
> 
> But the main question is: Is this needed?
> Are there really people who are dying to write a Moray plugin and only don't
> do so because they would have to program in C/C++? ...

On the other hand, even those of use that do write plugins in C++ might
like the ability to do simple scene building stuff as a script, rather
than having to build an entire DLL to do the job.

An obvious response is that it is possible to do this sort of thing as a
POV-Ray macro.  But then, the script only works with POV-Ray - I make a
renderer and I'd much prefer to have the scripting done in Moray, and
then have it be exportable to the renderer of choice.

Xander

Post a reply to this message

Johannes Hubert wrote:
> 
> It will only take away the need of that DLL building and stuff.

And with that it would take away the need to have development tools like
VC++ or Borland (Inprise).  That would allow more people to write plugins.

-Nathan

Post a reply to this message

Alex Magidow wrote:
> 
> I think that all you need for the given plugin is this:
> The dialogue box.
> The export of the dialogue box.
> The wireframe of the object created by the dialogue box.

You also need to be able to save the pluged-in object to the MDL file.
(and do stuff like copy and paste)

-Nathan

Post a reply to this message

Hi Twyst

Just looking at the length of this thread : you had a very good idea.


Philippe

--The universe is the only place I know where you can get a good steack--

Post a reply to this message

I've been following this thread for a while and have a question for Philippe
Are you suggesting using JS for the macros (afterall, it would be basically
a macro plugin)? While JS has the "advantage" of existing, there it wouldn't
be an ideal language for this specific application. Twyst's original idea
for the macros was a lot simpler and easier to understand for the
"non-programmer". I grew up in the age of COBOL, BASIC, and LOGO.. they had
a certian simplicity that today's languages lack (including JS)
On the upside, it would be a novel non-web based use for what's basically a
web script.
 Lue Ebra
url /say $chan www.triangle.quik.com/lueebra
Ph Gibone wrote in message <36ee18f6.0@news.povray.org>...
>>But we shouldn't kid ourselves: It will not work for non-programmers,
>>because it will still be a programming language.
>
>That's exactly what I mean, so why not take advantage of an existing one ?
>
>Philippe
>
>

Post a reply to this message

Hi Lue

 I didn't expect to raise so many swords suggesting JS as a macro language
for Moray plugin.

What I suggest, following the excellent idea by Twyst, is to have a plugin
(written in C/C++ as present plugins, by a talented programmer) able to read
a script file (1 script file = 1 plugin in written by anyone knowing the
scripting language and not necessarily C/C++, and anyway it saves a compiler
:-)) and then, based on the script file infos :

1) create and open a dialog box to input the needed values
2) tell Moray how to draw the wireframe, according to these values
3) tell PovRay how to ray-trace (means create the pov ray object)
4) tell Moray how to initialize, load, read, copy ...

What we need is a scripting language able to
1)   describe a dialog box and its content,
2)   know what is a variable (if possible structured one)
3)   do much math (plugins need that)
4)   and many other things

And what is to be noted is that we need first to define a syntax (as
complete as possible) for this scripting language before programming the
analyser so we have two solutions

1) use the syntax of a scripting language able to do most of the things we
need (and we don't need to implement all of it), and the happy fews knowing
the inspiring language will have a short learning curve)
2) re invent the wheel (an so every body will have to learn a new language)

The end of the story is : The talented programmer that will create the
scripting plugin will certainly have the right to choose


Sorry for my loosy english, I'm afraid most of the confusion comes from my
difficulties mastering this language (which has the advantage to exist :-)))


Philippe



>I've been following this thread for a while and have a question for
Philippe
>Are you suggesting using JS for the macros (afterall, it would be basically
>a macro plugin)? While JS has the "advantage" of existing, there it
wouldn't
>be an ideal language for this specific application. Twyst's original idea
>for the macros was a lot simpler and easier to understand for the
>"non-programmer". I grew up in the age of COBOL, BASIC, and LOGO.. they had
>a certian simplicity that today's languages lack (including JS)
>On the upside, it would be a novel non-web based use for what's basically a
>web script.
> Lue Ebra
>url /say $chan www.triangle.quik.com/lueebra
>Ph Gibone wrote in message <36ee18f6.0@news.povray.org>...
>>>But we shouldn't kid ourselves: It will not work for non-programmers,
>>>because it will still be a programming language.
>>
>>That's exactly what I mean, so why not take advantage of an existing one ?
>>
>>Philippe
>>
>>
>
>

Post a reply to this message