[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: MS Windows packages and modularity
- From: Allin Cottrell <cottrell wfu edu>
- To: Tor Lillqvist <tml iki fi>
- Cc: gtk-app-devel-list gnome org
- Subject: Re: MS Windows packages and modularity
- Date: Mon, 20 Oct 2008 20:05:13 -0400 (EDT)
On Tue, 21 Oct 2008, Tor Lillqvist wrote:
> >> Was there a compelling reason for this reversion?
>
> Not really. As has already been said, if/when the GDI+ -based
> pixbuf loaders would be used, then it would hopefully be 100%
> clear that it makes sense to build them as built-in in the
> gdk-pixbuf DLL.
Yes, that seems to make sense.
> But now when I was forced to revert to the libgpej and libtiff
> -based loaders...
Sorry (just out of ignorance): who or what forced you to revert to
the libjpeg- and libtiff-based loaders?
> there are two more or less equivalent choices, both which have
> their disadvatages: either 1) build separate png, jpeg and tiff
> loaders, which means there are more files to distribute for
> people who want to minimize the number of files in the GTK+
> runtime and still be able to load jpef or tiff files, or 2)
> build built-in loaders which means the png, jpeg and tiff DLLs
> are required even for a GTK+ runtime used in a situation where
> it doesn't use any png, jpeg and tiff files.
I'm not speaking from any great base of expertise, but just IMO:
1) "...more files to distribute for people who want to minimize
the number of files in the GTK+ runtime..."
Why would anyone want to minimize the _number of files_ in a GTK
runtime package, as opposed to the size in bytes of the package?
2) I suspect that most GTK apps (other than apps such as GIMP
which traffic in images) have no use for JPEG or TIFF
functionality. This is really quite specialized.
> Would the best solution be to build the png, jpeg and tiff
> libraries as static libraries, and link them statically into
> gdk-pixbuf?
This would avoid the need for the app developer to package
third-party DLLs, yet it still seems a bit awkward: it includes in
the byte-count of the GTK distro specialized functionality that, I
suspect, few will need. (I'd place PNG functionality in a
different category since in many ways it's treated as "native" in
GTK.)
--
Allin Cottrell
Department of Economics
Wake Forest University
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]