urgent
Hi I am porting gimp-1.1.24 to AIX-4.3.3. I have installed glib-1.2.8, gtk-1.2.8 , xlc compiler and configured gimp-1.1.24 as --disable-plugins --disable-nls --disable-ansi. however now I am getting errors in make as follows -- cc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I/usr/l ocal/lib/glib/include -I/usr/local/include -I/usr/local/inc lude -DLOCALEDIR=\""/usr/local/share/locale"\" -g -c url.c "url.c", line 214.25: 1506-195 (S) Integral constant expression with a value gre ater than zero is required. make: 1254-004 The error code from the last command is 1. -- The file url.c is in /gimp-1.1.24/plug-ins/common, Please help me to proceed further. Thank you Rashmi
Cannot read 16 bit TGA
GIMP cannot read 16 bit TGA files. Has anyone a patch?
Re: UTF-8 vs. current locale charset mess...
On Thu, Aug 10, 2000 at 09:24:42PM +0300, Tor Lillqvist wrote: GTK+ 1.3 (and 2.0) uses UTF-8 internally, while the file system related C runtime calls like stat(), open() and opendir() uses a "current codepage" (the Windows term, on Unix you want to use whatever encoding/charset the user's locale uses). For Linux at least the filesystems speak UTF8. I don't see a problem (well, OK as usual Windows doesn't work, but Tor you're used to hacking around that without needing to consult us) how about *BSD, Solaris etc? Nick.
Re: UTF-8 vs. current locale charset mess...
On Fri, Aug 11, 2000 at 12:50:12PM +0100, Nick Lamb [EMAIL PROTECTED] wrote: For Linux at least the filesystems speak UTF8. While this is the proposed standard, there exist about zero systems in practise that follow it, and the kernel does neither check nor enforce it. around that without needing to consult us) how about *BSD, Solaris etc? "unix", in general, only supports characters from the portable filename character set, so "in theory" there is no problem at all, as characters 127 do not exist in that set. So there is no way around supporting native character sets. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Cannot read 16 bit TGA
GIMP cannot read 16 bit TGA files. Has anyone a patch? I just wrote a TGA reader for the SDL library, including 16-bit reading. The only hard part was finding valid 16-bit images for testing it; after some searching I found some kind of budget Windows program (I think it was called paint pro shop) that would generate them. Pixels are stored in little-endian order, in BGR555 format. The highest bit could be used as a 1-bit alpha channel but seems mostly unused, so perhaps it could be ignored.
Re: UTF-8 vs. current locale charset mess...
Marc Lehmann writes: "unix", in general, only supports characters from the portable filename character set, so "in theory" there is no problem at all, as characters 127 do not exist in that set. True, but in real life, I would assume most Unix systems are quite happy with using any bytes in path names except '/' and '\0'. It's then up to the site-specific or user-specific locale what charset these are interpreted to be in. I would also guess that very few Unix installations actually use UTF-8 locales now and in the immediate future. However, GTK+ 2.0 will use UTF-8. (And GTK+ 1.3 as used on Windows use it already.) It's good to start thinking a bit on the implications now. What I was looking for with my message was mostly an okay (or strong opposition) to adding code to GIMP at this point to convert back and forth between the file system charset and UTF-8. (As I said, said code would expand to semantically no-op g_strdup() calls on GTK+ 1.2.x, and thus would mostly be just a cosmetic issue.) One decision would be good to make now: Are the file names passed around in PDB calls in UTF-8 or in the "file system" charset (the current locale's charset)? Both approaches have pros and cons: - pass around UTF-8: GIMP and plug-ins have to convert to the current locale charset before doing system calls with path names. OTOH the strings can be directly passed to GTK+. - pass around path names as they are in the system: GIMP and plug-ins have to convert to UTF-8 when passing path names to GTK+ for display, and from UTF-8 when receiving pathnames from user input. OTOH they can be directly used in file system calls. My guess is that the second approaches is preferrable? --tml
Re: urgent
In regard to: urgent, [EMAIL PROTECTED] said (at 11:10am on Aug 11, 2000): cc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I/usr/l ocal/lib/glib/include -I/usr/local/include -I/usr/local/inc lude -DLOCALEDIR=\""/usr/local/share/locale"\" -g -c url.c "url.c", line 214.25: 1506-195 (S) Integral constant expression with a value gre ater than zero is required. make: 1254-004 The error code from the last command is 1. This has already been fixed in the CVS version of gimp. See http://bugs.gnome.org and search by package for gimp Wander around on http://www.gimp.org to find the info on how to get the CVS version. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J1, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164
urgent please
Hi I am porting gimp-1.1.24 to AIX-4.3.3. I have installed glib-1.2.8, gtk-1.2.8 , xlc compiler and configured gimp-1.1.24 as --disable-plugins --disable-nls --disable-ansi. While make I was getting error in url.c as it is excepting some constant value in line number 214, this file is present in /gimp-1.1.24/plug-ins/common , hence I have changed that line as gchar buf[1055 + 1]; however while running ./gimp I got error as - Segmentation fault in glink.g_main_pending at 0xd13ca814 ($t1) 0xd13ca814 (g_main_pending+0x30) 800clwz r0,0x0(r12) (dbx) where glink.g_main_pending() at 0xd13ca814 gtk_set_locale(), line 444 in "gtkmain.c" main(argc = 1, argv = 0x2ff22c88), line 132 in "main.c" (dbx) - Please help me to proceed further. Thanks Rashmi
