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

[Antony Shaleynikov]

On Thu, 24 Jul 2003 16:58:48 -0700 (PDT)
Teunis Peters <address@hidden> wrote:

> On Thu, 24 Jul 2003, I.S.Kuten wrote:
> 
> > >
> > > Hi all.
> > >
> > > I have some time to spend on this project, but first of all I need to 
> > > know,
> > > what features need to be implemented or bugs fixed.
> > >
> > > In my opinion there are must be the following (that's all that I lack in 
> > > ParaGUI ):
> > >
> > > * VFS abstration layer (maybe it isn't a ParaGUI task)
> 
> not a paragui thing.  Handy extension though.
> 
> > > * OpenGL support for drawing controls (work on it stopped more than year 
> > > ago )
> 
> Nope.  Stopped earlier this year.  required a complete rewrite of video
> driver support - previous code will NOT work with current SDL.  Depended
> on a HACK that has been since removed.
> 
> > > * More complex controls (file selector for example)
> 
> Again extension lib.
> 
> >
> > About complex controls ... ( like File Selector, Tree Control, etc )
> > I'd suggest not to bloat ParaGUI - it's lightweight GUI lib , but impelement
> > them as addon library ( like physfs )
> >
> > So we can choose in ParaGUI
> > ./configure --with-addon-controls
> 
> 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. 

Advantages:
 * Very modularised structure
 * Only necessary modules will be loaded in memory
 * On-fly changable drawing backend
 * _really_ extendable XML configuration handler
 
Disadvantages:
 * More complex code
 * Cannot use in some systems

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. )

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

--
Best regards,
Antony Shaleynikov