> 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 _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
