Re: [paragui-users] translation to C ideas...

[Teunis Peters]

On Sun, 10 Aug 2003, Asko Kauppi wrote:

>
> Strings, maps etc. are something that should not really be handled in
> the C level. Scripting languages (choose your flavour ;) are much
> better for them..

not in this case.  No script language I'm aware of has the capabilities
I've in mind.  (trust me - I've looked :)

and besides at some point the lowlevel has to handle strings.  Might as
well get it right the first time.   (hint: font rendering, filename
storing.  Both involve PILES of special cases and additional rules.  Oh
and localization)

(although I'm starting to get the idea that keeping file handling to a
minimum is a good thing.  That usually can make it balloon fast...)

As for the rest - one of the things a C port makes a whole pile easier is
interfacing with scripts / plugins / whatever.  For some reason C++ is a
dreadful pain when it comes to that.

Should make cross-platform portability easier.

> As i've stated earlier, i'd be interested in making a Pargui/Lua
> interface (eventually). This easily leads to a two-tier architecture
> where the bottom-most parts are C(++) and the top are scripts.
>
> There's only one downside i can think of: since scripting languages
> differ (in syntax, not so much in features) we'd easily get stuck with
> a certain 'preferred' language.
>
> Perhaps we can have several upper level parts (s.a. Lua, Python, ..)
> and agree on a common scripting API for them (that is, same name of
> functions, methods, behaviour..)
>
> Of course, also the bare-and-minumum C library should be usable as such
> (if that's all you need).
>
> what do you think?

*heh* sounds good.   I'm trying to get the 'bare-and-minimum' C library
written right now...
I'm not tying it to any particular language at the moment (except 'make').
Still have to see from there.

the standard rules apply:
        - it must be embeddable
        - it must be minimal dependancies (eg: SDL okay, GTK not, KDE
                most definitely not)
        - it must be multithread-friendly

am not sure if I'll make it actually multithreaded (there are a few points
where having a second thread would be handy) or just merely setup to
handle it.
about 100% of the code I write for my own purposes is multithreaded so :)

G'day, eh? :)
        - Teunis