[no subject]

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


Karthik

On Mon, 14 Mar 2005 14:00:06 +0100, Evert Glebbeek <eglebbk@xxxxxxxxxx> wrote:
> guilt:
> > So, what do you guys feel/think/suggest about splitting up the library
> > into base+implementation+extension?
>=20
> I think that this makes a lot of sense for the structure of the library
> internally, in as far as this is not done already (the bitmap loader, for
> instance, already follows this approach fairly closely: the bitmap loader=
s
> could all be made into addons by simply removing the code from the librar=
y,
> packing it seperately and recompiling). But this is something that I thin=
k
> has been discussed and agreed upon before now.
> Wether it makes sense to offer base and implementation as a seperate
> download is debatable, I think. I tend to think not.
>=20
> Chris:
> > I probably would leave Allegro as-is (eg. one full-featured library),
> > and provide some kind of public plugin API for 3rd party add-ons.
>=20
> Yes, I think this is the way to go too.
>=20
> > And I don't see the use in splitting Allegro up, since if the Allegro
> > devs are going to work on/support it, it might as well be in the lib
> > itself and reduce the amount of dependancies the user has to worry
> > about.
>=20
> Good point.
>=20
> > Things like the GUI, if work on it is going to be stopped, I can
> > understand being externalized into a plug-in and letting someone else
> > take it over.. but something like image loading that's going to be used
> > alot and would be maintained, there's no reason to externalize.
>=20
> I tend to agree. There was also a lot of discussion on this topic on
> Allegro.cc when Korval first proposed `AllegroPro', which at its base
> wouldn't have image loading and file I/O either. What good is a library
> that has no way to load external resources, or needs an addon for
> everything you want to do with it?
> Currently, Allegro needs addons for loading certain filetypes (PNG comes =
to
> mind) because it is older than those types and it contains loaders that a=
re
> no longer useful (LBM, if that was ever really useful). If Shawn were
> designing Allegro today, I think it would include PNG loading by default.
> This isn't an addon because it's best that it's an addon, but because
> Allegro's design makes this more convenient.
>=20
> The discussion wether or not Allegro should include PNG support by defaul=
t
> in a post 4.2 version is a different one. This will make Allegro dependen=
t
> on zlib and libpng. On the one hand, it is convenient to have Allegro
> depend on as few third party libraries as possible. On the other hand,
> Allegro already requires DirectX in Windows to build at all and
> X11/SVGAlib/whatever in *nix to build a fully usable version. Adding zlib
> and libpng wouldn't be a big deal for the UNIX port, but it might be for
> Windows. Of course, the advantage would be the ability to use zlib for
> packfiles as well.
> Anyway, that is a discussion best left until after 4.2 is out and 4.3 is
> well underway and maybe has seen its first release.
>=20
> Evert
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_ide95&alloc_id=14396&opclick
> --
> https://lists.sourceforge.net/lists/listinfo/alleg-developers
>




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/