Re: bug(s) in all-in-one bundle?

["Tor Lillqvist" <tml iki fi>]

> the gladewin32 package had the file
> C:\GTK\etc\gtk-2.0\gtkrc while the all-in-one bundle does not.  I copied
> that one line file to the all-in-one bundle and it worked.  The font
> problem was solved.

What was the contents of the gtkrc file that solved your (perceived) problem?

> Is this a bug with the all-in-one bundle?  Shouldn't that file be
> included?  If not, why?

The intent is that GTK+ should work as expected (well enough) without
a gtkrc file. Of course, different people expect different things.
Some expect the ms-windows theme engine to be used by default, and
they then would expect the gtkrc file to contain the line
gtk-theme-name = "MS-Windows". As I don't know what exactly your font
problem was, and what the gtkrc file contains that you say solved it,
I can't comment about that particular issue.

> Shouldn't the instructions include such a thing?

What instructions? ;)

I am afraid I must again use the term "is expected" that seemed to
upset some people last time... The Win32 binaries for the GTK+ stack
on ftp.gnome.org "are expected" to be used by people who develop GTK+
applications and/or bundle GTK+ with installers for applications. Just
like people who package GTK+ for various Linux distros, they are
expected to know about gtkrc files and the kind of things one can
change by providing such a file. If they don't, well, it shouldn't be
that hard to find people who can give advice.

> Speaking of instructions, the bundle does not have a README file (at
> least not at the top).  Wouldn't it be a good idea to have one?

Sure, why not.

> Should this README include things like editing these files that have
> wrong paths:
>    gtk+-bundle-2.12.9\etc\pango\pango.modules
>    gtk+-bundle-2.12.9\etc\gtk-2.0\gdk-pixbuf.loaders
>    gtk+-bundle-2.12.9\etc\gtk-2.0\gtk.immodules
>    gtk+-bundle-2.12.9\lib\pkgconfig\*.pc

No they don't. Let's look for instance at gdk-pixbuf.loaders file from
gtk+-2.12.9-1. It contains lines like:

"c:/devel/target/5f04c8d97eb7e9b6066c1f1a6dafa66b/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-ani.dll"

This is as intended. There is no need for that oddly named folder to
actually exist on the machine where this GTK+ build is used, and there
is no need to edit the file to contain the "true" paths instead. If
you don't touch the file, and don't move files or directories around
in the directory structure as unpacked from the zip files, it will
just work.

There is code in GTK+ and Pango that notices if the pathnames read
from the gdk-pixbuf.loaders, gtk.immodules and pango.modules files use
the compile-time prefix (that existed only ephemerally on the
builder's, i.e. mine, machine). In that case the pathnames are
corrected at run-time to point to the actual installation location of
GTK+ or Pango.

(Actually current Pango Win32 binaries don't even need a pango.modules
file, as the relevant modules are statically built-in in the DLLs.)

As the hex string is different for each build of each module (it's the
md5sum of the module name and version...), this means that if one
mixes for instance a gdk-pixbuf.loaders file from one build and a
libgtk-win32-2.0-0.dll from another build, it will not work. In that
case you indeed then needs to use true actual paths in the
gdk-pixbuf.loaders file.

The case with the .pc files is similar: It is perfectly fine that for
instance glib-2.0.pc contains:

prefix=c:/devel/target/2c9495bb1b32cc89212ac45c77727a65

(in glib-2.16.3). The pkg-config program, when running on Windows,
doesn't use the value of "prefix" set in the .pc file but instead
deduces the installation prefix at run-time based on where the .pc
file is located. If glib-2.0.pc is in
g:\foo\bar\tem\lib\pkgconfig\glib-2.0.pc, then pkg-config assumes that
the prefix for that package is g:\foo\bar\tem and acts as if that .pc
file would have said prefix=g:/foo/bar/tem instead.  Again. this works
only if the directory structure has been kept intact, and files and
folders from the zipfile package not moved around relative to each
others after unzipping.

--tml