Re: [paragui-users] Don't R.I.P., ParaGUI :'( (now dynamic loading)

[Teunis Peters]

On Fri, 25 Jul 2003, Antony Shaleynikov wrote:

> > Actually not that complex.  Or maybe more complex *G*.
> > 1. Some kind of configuration file (user settable but defaults to
> > <config>:paragui2.xml)
> > - why XML?  Why not.  ParaGUI2 anyways already uses it.
> >
> > 2. Dynamic loading system.  Take a peek at devel-opengl - it already has
> > that for video drivers.  I was playing with the design of a component
> > loader but ran into troubles with paragui's XML handler.  *ick*  Not
> > really extendable.
> >
> > 3. hooks in paragui for extensions to hook themselves in.  And some way to
> > request: a) a list of extensions and b) access to an extension.
> >
> > 1 - optional, but would be handy to locate extensions
> > 2 - optional, seems a good idea.
> > 3 - that's the basic min.  Any shared lib could hook into that...  and the
> > app could require the lib which would automagically arrange things.
>
> Do you mean do develop something like SCF in CrystalSpace 3D Engine?
> I don't think it's a very lightweight solutions.

I guess I should look at crystalspace again.  It's only been a couple of
years :)

> Advantages:
>  * Very modularised structure

modular = good.  ParaGUI is almost there...  but not quite *splat*

>  * Only necessary modules will be loaded in memory

good

>  * On-fly changable drawing backend

Got that in my branch... *g*

>  * _really_ extendable XML configuration handler
>

ParaGUI's is -stupid-.  Not just messy and annoying but -stupid-.  Only
works for save/restore not for anything else as far as I can tell.  Pity.
Not sure how to attack this one....  I only recently (and reluctantly)
learned how to work with libexpat.  I'd be much happier if ParaGUI could
work with XML excerpts rather than assuming control of the whole XML body.

> Disadvantages:
>  * More complex code

I know that one.  Complex is relative though - the trickiest part of the
videodriver rewrite was making sure -no- SDL video calls were -ever- made
outside the driver.

>  * Cannot use in some systems

What breaks them?   The videodriver system used SDL's (optional) dynamic
loader initially then forked it out.  I suppose I could use that extension
loader lib that's on the SDL library pages...  Very small simple code,
seems to probably work on windows/macos/unixen

> I have library called clear_base, which is similar to COM and allow to do
> all this things ( means common extension loading/unloading, interfacing, etc. 
> )

COM is evil.   Would be fun to see but I don't know....
I once wrote a .dll handler for DOS/linux (don't ask) and then switched to
elf... then my own format I still haven't figured out how to link to *g*.

COM doesn't really handle objects very well, otherwise it's okay.

> Maybe need to fork ParaGUI for example ParaGUI Light which will be extremly 
> lightweight
> and ParaGUI, with more functions?

Actually ParaGUI's realitively 'light' compared to most full GUIs but it's
a little heavy for other things... hrm.  Not sure if that's a good
solution.

G'day, eh? :)
        - Teunis
PS: just to take this with a grain of salt - I haven't work with
windows/XX since about '95 after windows blew up for the last time on me.
I cross compile -to- windows I don't run it unless I have to.