paragui-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[paragui-users] Why use XML for configuration?


From: Asko Kauppi
Subject: [paragui-users] Why use XML for configuration?
Date: Sat, 26 Jul 2003 00:40:29 +0300


Cast me stones (rather, tomatoes..? ;) but why does/should ParaGui use XML for configuration?

Imho, something like Lua does the job of (dynamic) configuration better. It doesn't have configuration / programming split. It's all both. Better than XML. Better than (shell) scripts. Better than anything?

-ak


Antony Shaleynikov kirjoittaa perjantaina, 25. heinäkuuta 2003, kello 12:28:

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


_______________________________________________
paragui-users mailing list
address@hidden
http://mail.nongnu.org/mailman/listinfo/paragui-users






reply via email to

[Prev in Thread] Current Thread [Next in Thread]