Re: [paragui-users] widget registry?

[Teunis Peters]

On Fri, 15 Aug 2003, Asko Kauppi wrote:

>
> then why not embed a whole (small and simple) lua core within paragui.
> by that i mean _inside_, could actually replace 'internal-expat' at the
> same time.
>
> this would allow you to:
>       - implement C stuff with C

ANYTHING can be implemented in C that can run on a computer.  Just
sometimes it takes more work than in another language *grin*

>       - implement more higher level stuff (maps) in Lua

again, this is misunderstanding the situation.
The mapping requirement at hand is LOW level.

>       - outside world would never know.. ;)
>
> another idea could be to extract the (ready, working, and efficient)
> mapping code
> from lua sources and bring it in. But i would presume that to be a more
> elaborate option.

I'm willing to look.  I'll go that far.
Nope - lua doesn't have what I need.  glib-2.0 does though, so I'm
grabbing code out of it.  Maybe.

> You might even be able to replace the 'expat' dependency by this, so
> the total number
> of 'dependencies' (even internal) would not increase.
>
> as Pete the Fixer (or what's he called in English) sings:
> "get the right tools for the job..."  ;)

expat actually fits what I've got in mind, so I'm leaving it as is.

lua looks pretty basic.  Kind of reminds me a little of ruby actually...

Okay.  I've got the widget registry designed for the moment.   Again, I'll
post on the whole thing when I have a demo.  I -do- have rules to this
project:

here's some more:
- it's in C
- As few outside dependancies as possible
        (as a result, I'm importing pieces of pango - for proper string
         layout and management.  May end up with some glib too)
- as EFFICIENT as possible

The CURRENT rendition of the widget registry I've got wouldn't work with
current ParaGUI - C++ has no way to refer to class objects directly.  (gcc
might, but C++ doesn't)
Mind you, once I've got it all tested and stuff I think I will rewrite it
for paragui-devel.  It'll probably go into the devel-opengl trunk because
I actually have access to that one *g*.  Besides, it's a big change...

G'day, eh? :)
        - Teunis