O.K. folks ...
I think we heard enough opinions about the pros and cons of implementing
image loading in the file target.
Let's summarize:
Pro:
- It is simple to use for LibGGI-aware applications.
Con:
- It doesn't help non-LibGGI-aware applications while a separate lib would.
- If it implements more than a few file formats internally or via libs (even
if they are dynamically loaded: they have no common calling interface,
so at least glue code is added for every format), it bloats the file target
and/or its dependencies.
- If it implements only a few formats, we will always have some people left
over that complain why it won't load format xyz.
- It is inconsistent regarding the calling interface as it either needs to be
readonly (which mean you have to write a special renderer set for it
for that to work correctly) or it would magically work without SetMode,
which is undefined behaviour on other targets.
Now let's see what we can do about that conflict. My opinion:
1. Marcus is right: We need a generic and _really_good_ image
reading/writing library anyway. We have quite some good standalone libs
for the individual formats, but they lack a common calling interface.
While it is true, that it is pretty hard to make a universal interface
that takes account of all the possible extensions and features of all
formats, it should be easily possible to make one that does the basic jobs
of image loading and saving.
2. So I'd suggest we design and write that one first. As said I have some
design ideas about that, and probably others have some as well from some
frustrations with other libs.
3. When this is done, we have a _single_ library that will load/save any
picture for us. As we design it, I image it to be like LibGGI with pluggable
libs for the file formats, so no bloat at runtime.
4. Now, if there is still desire to add that functionality to the file
target, we can do so by linking to _JUST_ONE_ lib and adding a _FEW_
lines of code (say less than 100) to it.
This path solves the first three cons very nicely. Regarding the last one:
If there is demand for it, and it doesn't add much bloat - why not. One
doesn't have to use the feature, in which case all is nice and consistent.
It might as well be, that after we have the loader lib, noone still wants
it, so let's delay the discussion until the work is done.
Let's get something done (you all know that I hate the "no action talk only"
syndrome):
1. Someone please propose an external API for an image loader/writer. At
best one that already exists with working code attached to it.
2. We will then discuss it and improve it until we are satisfied.
3. We will the implement it or restructure existing code to work like LibGGI
dynamically loading loaders/writers as required.
4. We add libs for all known/documented file formats, starting from "use
ppmtools" stubs to have a catchall system from scratch.
5. We write a few glue components that take care of colorspace conversion
and image representation/transfer.
O.K. - let's go ... task 1. is on schedule ...
CU, Andy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
