KPovModeler Tutorial

[CARVALHO Luis Passos]

> -----Original Message-----
> From: Hugo Ferreira [mailto:hmf at inescporto.pt]
> Sent: segunda-feira, 14 de Julho de 2003 9:04
> To: kpovmodeler-devel at mail.kde.org
> Subject: Re: KPovModeler Tutorial
> 
> 
> Hi,
> 
> Sorry for only replying now. I have no connection at home. 
> (Gave up on cable modem, service was really bad).
> 

Try ADSL. I live in Barcelos and never had any complaints. 
At least for my uses 2Gb/month are more than enough.

> 
> Kwrite, Kate, (maybe KEdit ) and Kdevelop have code folding. 
> I tried Gideon 
> and this seems to work ok.
> 

Yes, I know. However, I keep doing esc+i to edit. What can I say.
You can't teach an old horse new tricks. :)

> 
> Unfortunatelly I don't have much time. Basically I just 
> wanted to support the 
> polygons. I can go on giving some of my time, but I cannot give u any 
> guarantees. 8-(
> 
> I will be looking at the tutorial and asking some questions, 
> of course ;-).
> Andreas, thanks for the info. Any way I could add comments to 
> the code to 
> reflect this information?
> 

More comments are always A Good Thing(tm). :)

The most simple objects to implement are those that don't require 3d.
We'll, at least for me as I don't really understand openGL. For now, 
I'll study it eventually.

> I would like to ask a related question. I had a look at the 
> parser and see 
> that it is a major part of the work. I have also realized 
> that parsing and 
> supporting all the PovRay objects is a constant battle for 
> any application 
> that interfaces with povray. So may question is, have any of 
> you considred 
> using automatic parser generators to do this work? If not, 
> why? Please note: 
> this is not a suggestion to change Kpovmodeler. I am merely 
> interested in the  
> reasons for your decisions.
> 

I assume you're talking about bison and flex.

Hmmm, although I didn't actually make the decision here are a few ideas:
	* Reverse engineering from povray -> povray doesn't use bison/flex
	* Less compile time precedences -> kdegraphics didn't require
bison/flex
	* Object oriented parsers -> as far as I know, from my limited
experience
with it at university bison/flex are not object oriented. How well do they
fit in
this methodology I do not know.

In fact, if you look at the code there is not much to change when the
parsing changes.
	* PMScanner -> Token parser. Does flex's job, even if only for
povray. 
Maybe it could be generalized to contain different token dictionaries.
	* PMPovrayParser -> using a PMScanner instance to feed it with
tokens, implements
the parsing rules for povray.

When I had to develop a new object, I had only to add one or two missing
tokens to 
PMScanner and develop a new method in PMPovrayParser, eventually using other
methods as
components for the new parse. Anyway, most of the code is not for the
parsing itself but 
more for the construction of the object tree.

New plugins for different grammars may be interesting to develop using
parser generators.

However, really cool would be to have a user configurable grammar parser to
avoid compile-time
dependencies. If you know of such a parser (that is fast), I'm sure we could
have advantages
in adopting it. :)

Cheers,
Luis