> > I have for now only argued with respect to bloating the file target.
> > While IMHO a p?m loader wouldn't add much bloat, Marcus is right with the
> > "we need a good image loading library anyway" argument.
> Not a only loading library. He said:
>> Image loading should ideally be written as two libraries:
>> One library that does not use LibGGI and does not know about visuals.
>> It should dynamicly load readers/writers for different image formats,
>> and read images into/write images from it's own simple structure
> ^^^^^
Yes - sure. While we are at implementing loading files, we can as well add
saving. This can usually share quite a bunch of code or at least brainpower.
When you can load a format, you usually know how to write it as well (except
for some lossy formats, where the trick lies in deciding what to loose),
and in quite some cases, there are common subexpressions in the
encoding/decoding procedure. So it makes perfect sense to make the lib
(one lib !) read/write.
> The second library should be a simple glue-layer between the first
...... ^ ^ ^ ^ ^ ^ ^ ... Please look there :
There shall be one lib that is not LibGGI*-oriented at all, that can
load/save picture formats.
And there shall be another lib that allows to easily access this lib
from LibGGI-aware applications by allowing to directly load into visuals
or creating appropriate memvisuals etc.
> So when we write two libraries, to load and save images - Should the
> file-target then be removed?
NO. There is _one_ lib to load/save images and _one_ to glue it to LibGGI.
This does not in any way touch the file target, which is intended primarily
for another situation anyway.
An application that _voluntarily_ wants to provide screenshots and stuff
can call into Lib1 (via Lib2) or whatever and do so with ultimate
flexibility. It doesn't need to go through the extra bloat of opening a
file target, crossblitting or drawing stuff there and closing it again.
The file target was designed for applications that do _not_ cooperate
(because you usually don't think about such stuff for normal apps).
CU, ANdy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
