On Sat, 6 Feb 1999, Alexander Larsson outgrape:
> On 6 Feb, Lars R. Clausen wrote:
>>> 1. While imlib is very easy to use for the programmer it is not as easy
>>> to use for the user. It creates very large dependencies to stuff that
>>> not everyone has. And not everyone have imlib either. On the other
>>> hand, having to do your own loading of images is a royal pain in the
>>> ass, so we might have to run with it.
>>
>> It actually only depends on gtk, which we have already. Making our own
>> library would just be duplicate effort and introducing bugs.
> Well, to be usable it depends on libpng, libtiff, libjpeg, zlib,
> ImageMagick, libungif. These are libraries that exists in most linux
> distributions, but they rarely exists in commercial unixes like
> Solaris or AIX. They can of course be downloaded and compiled, but
> that takes a lot of time and space, and you might only have some 5 or
> 10 Meg quota on you home-dir and no root-access.
But we already depend on gtk, which is way larger and not generally
installed either. But I guess we could make pictures optional and just
leave out the button if they're not compiled in.
>> That's what I thought, too. Maybe it could be a saving option? In most
>> cases, you'd only want to save the filenames, but when distributing, you
>> would want it all in there.
> Yeah, maybe. Then we need to be able to convert images to/from ascii
> strings.
>
> Another thing. I want a thin wrapper around imlib. It should be
> basically possible to swap imlib for something else, and just have to
> recompile all the objects. Something like i have done with gnome-xml,
> check out lib/dia_xml.h. No object ever includes anything from
> gnome-xml or calls any gnome-xml function directly. The interface is
> very slim though.
Will do.
-Lars
--
Lars R. Clausen ([EMAIL PROTECTED])
A *real* smart bomb would call in sick, perhaps move to another country,
changing its name in the process, open a beach bar maybe and live out its
days in safe anonymity. -- Barry O'Neill in rhod
