Re: bug(s) in all-in-one bundle?
--- Tor Lillqvist [EMAIL PROTECTED] wrote: 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. Sorry, your development + distribution model is fundamentally flawed. The needed info should be available from the package, people should be needed to file bugs against in this context. --- Richard Boaz [EMAIL PROTECTED] wrote: Shouldn't the instructions include such a thing? What instructions? ;) and we programmers wonder why we have such a poor reputation re: documentation of our work. :( - hasn't anyone looked for an answer remembering the Why do women have period ? question :-) ? Regards, Sergei. Applications From Scratch: http://appsfromscratch.berlios.de/ ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: bug(s) in all-in-one bundle?
Tor Lillqvist wrote: 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? sorry, I forgot to mention gtk-theme-name = MS-Windows a gtkrc file. Of course, different people expect different things. sure, I expect it to work :-) Some expect the ms-windows theme engine to be used by default, and I didn't know it but I guess that might be what I was expecting. What instructions? ;) I suspected 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 Don't worry, I won't get upset. I can't afford to annoy those from whom I am trying to get help anyway. on ftp.gnome.org are expected to be used by people who develop GTK+ applications and/or bundle GTK+ with installers for applications. Just That would be me, or at least I hope to do that. like people who package GTK+ for various Linux distros, they are expected to know about gtkrc files and the kind of things one can I really do hope to learn that stuff but please understand it is hard to just know all that when one is just getting started. change by providing such a file. If they don't, well, it shouldn't be that hard to find people who can give advice. I haven't been all that lucky. 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 This is interesting 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. Thanks for taking the time to explain. I did a little experiment with the .pc files and with those two files in C:\GTK\etc\gtk-2.0. I found that GTK still worked, Glade worked and so did pkg-config So, I guess there aren't any bugs with the files discussed. It does seem to me that there really is a need for a README file. Perhaps as a minimum, the README should have 1. upzip bundle to desired location (something like c:\GTK) 2. PATH and environment variable stuff 3. optional create file C:\GTK\etc\gtk-2.0\gtkrc gtk-theme-name = MS-Windows 4. Test. maybe a simple app with compile instructions? Damon Register ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: bug(s) in all-in-one bundle?
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@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: bug(s) in all-in-one bundle?
Shouldn't the instructions include such a thing? What instructions? ;) and we programmers wonder why we have such a poor reputation re: documentation of our work. :( ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
