Re: MS Windows packages and modularity



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]