problems with windows gimp
[EMAIL PROTECTED] writes: Below is the error message i get, if there is a quick resolve to this problem then please direct me to the proper online documentation, Remove either tiff_nolzw.exe of tiff.exe from your GIMP plug-ins directory. This is explained, perhaps a bit vaguely, on www.gimp.org/win32/ . (No, I don't know why duplicate PDB procedures cause strange errors and not just warnings. Anyway, GIMP seems to handle this situation better in the current gimp-1-2.) --tml
Re: perl script in gimp for Windows : is it possible ?
(See the end of message for Perl-relevant stuff, mostly digression first...) On Fri, Jan 05, 2001 at 02:44:42AM +0200, Tor Lillqvist [EMAIL PROTECTED] wrote: producing a glib-config or gtk-config for people who download the headers and prebuilt libs (in a zipfile), and install them in some random place, and then would like to build some application. Marc writes: Well, I thought that people capable of building gimp (in win32 this is not common ;) could build gtk+ as well, but in general (when gimp for win32 is being built by millions of users wordlwide) this is a hindrance. Umm, I didn't mean that there were more people building GIMP themselves that people building GLib or GTK+. But there are a number of people who don't care building GLib or GTK+, but do want to build *other* GTK+ applications. They are the the ones that sometimes ask "where is gtk-config?". However, when it is possible to create downloadable binary distributions for linux it should not be that difficult to do so for windows as well (c:\gnu\gtk+ required ;) If it only was so easy... I can easily imagine that a potential GTK+ developer which uses different workstations each day doesn't want to put anything on any C: drive, but instead in his home directory, which could be something simple like H:\, or complex like \\redmond42\lusers\b\billgates. and MSVC. (One difference is that gcc uses long long and the LL suffix for long long literals, MSVC uses __int64 and the i64 suffix. The Of course, in GLib- and GTK+-using code one should use G_GINT64_CONSTANT, so the point is moot anyway. It's just a matter of time for msvc to support C, though, so even this difference will soon vanish (or so). You mean "to support C99"? Probably. I should check the (free beer) beta of the next MSVC that is said to be included with the .NET (sheesh) SDK. On Win32, the mingw gcc *is* compatible with MSVC (for C; C++ is yes, but msvc isn't and when you pick, e.g. activestate as your perl then Umm, huh? Gcc-produced code (from C source) is binary compatible with MSVC-produced. (As long as you use the -fnative-struct switch to gcc.) I haven't looked at Gimp-Perl yet, I kinda assumed a working Gtk-Perl is a prerequisite. No. gimp-perl will detect (not using autoconf this time) wether Gtk is installed and will not try to do anything graphically if it isn't. This means thast many scripts will run with default values (somewhat useful) and the ones depending on Gtk will not be instaled, but scriptability is still 100%. OK, great. I will first try to get Gimp-Perl running without Gtk-Perl then. OTOH, the main gimp makefile also uses test and a lot of unix-things. Is gimp not build using autoconf on win32? Nope. Now that's cool! Is that an art form? ;) More like a form of masochism. Actually, it is easier in a way to keep manually written makefiles up-to date than struggling with auto*, configure, and libtool on Win32. At least it's much faster. You can imagine how slowly auto* and libtool run on Win98, or cygwin hosted on Win98 even. All those sed, awk, test etc invocations do slow it down. (It is especially irritating to wait for a configure run to finish when you consider that one already *knows* what the result of all the frigging checks configure is running will be. It is not like the features in Win32 and MS's C runtime would change under you between configure runs.) But anyway, I do realise that the Right Thing is to use the normal configuration mechanism, and will move to it, eventually. As I understand it, mingw is just a gcc that threw away POSIX and gives you a "standard" win32 build environment. It is a bit debatable what mingw is. Personally I would define it as simply gcc and binutils running on Win32, producing code for Win32, with no cygwin or other POSIX emulation in sight. Some people talk about a "mingw runtime" but I don't like that, mingw-produced apps should and do work just like MSVC-produced ones, they don't use any "mingw runtime". I looked at the "standard" README.win32 and it seems to be a truely native port, it works with borland, msvc AND: Mingw32 with GCC version 2.95.2 or better The last of these is a high quality freeware compiler. Support for it is still experimental. (Older versions of GCC are known not to work.) I think this sounds like the right perl to use. Indeed. I will switch... (PS. When I considered using a Perl running under cygwin, I was on the wrong track. Cygwin is its own operating system in a way, so using cygwin-hosted tools to build for Win32 is a cross-compilation. It isn't possible to cross-compile Perl modules, is it?) --tml
Re: perl script in gimp for Windows : is it possible ?
Marc Lehmann writes: - Makefile.PL wants to use gtk-config. No such on Win32. (How could there be one? On Win32, people typically don't build GTK+ themselves, but fetch the headers and libraries The same, of course, is true for the gimp. most people who build gimp would be able to build gtk as well ;) gtk-config (or glib-config) is not a problem for people who *build* glib and/or gtk+ themselves, they know where they are going to install it, and they could generate a suitable *-config script. The problem is producing a glib-config or gtk-config for people who download the headers and prebuilt libs (in a zipfile), and install them in some random place, and then would like to build some application. This is, of course, not solvable in any case. Changing the compiler means that all the autodetected stuff goes wrong. It isn't necessarily that bad, remember that mingw and MSVC use the same runtime, and all header files that are present in MSVC have clones in mingw. Most autodetected stuff is equally valid for mingw and MSVC. (One difference is that gcc uses long long and the LL suffix for long long literals, MSVC uses __int64 and the i64 suffix. The corresponding printf format is obviously the same, though, as the C library is the same.) This also means that the compiler used to build gtk+, gimp, gtk-perl and gimp-perl must be the same. Wrong. Nothing prevents mixing MSVC- and gcc-compiled DLLs and EXEs of GLib, GTK+. I don't think Gtk-Perl or Gimp-Perl should need to care either. We have a lot of problems with this (obvious for me but not others it seems), e.g. on IRIX where the preinstalled perl is compiled with the commercial sgi compiler but most people only have access to gcc (which is not compatible). On Win32, the mingw gcc *is* compatible with MSVC (for C; C++ is another matter). The bleeding edge of binutils (which I personally don't use yet) can even link to DLLs directly (autogenerating import libraries on the fly), or use libraries in MS's format. The better option IMHO would be to make glib (source available!) compilable against perl, as a compatibility measure on win32. Yes, the dirent emulation is GLib has caused some problems before, as it isn't the same emulation as that in the libmingw32 library (which the mingw gcc automatically links with). I will probably move the dirent stuff out to a separate library (so that it is available for MSVC users), and make it identical to the one in libmingw32. (I think it was wrong to include dirent emulation in libmingw32, and a dirent.h header, as that breaks being able to compile the same code with either gcc or MSVC.) Certainly. Also not concentrating on gtk-perl but instead on gimp-perl would also help. I haven't looked at Gimp-Perl yet, I kinda assumed a working Gtk-Perl is a prerequisite. OTOH, the main gimp makefile also uses test and a lot of unix-things. Is gimp not build using autoconf on win32? Nope. This most likely will change at some point when I have the time to look into it. One problem I can think of right now is that the gimp modules want to use entry points in the gimp executable, and for that to work on Win32 you must mark those entry points for export when building the exe. I.e. build the exe kinda like you would build a DLL. There is no mechanism in auto* or libtool to handle that, I think. It now seems as it indeed would be easier to use a Perl running on cygwin to produce the Makefiles for Gtk-Perl and Gimp-Perl (Makefiles for GNU Make and a cygwin shell), but still have those Makefiles run the mingw gcc. (That's the kind of Makefiles I build GLib, GTK+ and GIMP with.) --tml
Re: Gimp for Windows v1.2 seems to have new bug
I wrote: Maybe the flame plug-in is very sensitive to what random number generator is used, and works well only with the random() function available on most Unixes (but not in MS's C library). Problem solved. Mea culpa. It wasn't that flame would be sensitive to the random number generator's deeper statistical properties, but it did require that it returns non-negative values. I had set RAND_FUNC as g_random_int in GIMP's config.h, without thinking. The random() or lrand48() functions that normally are used on Unix both return a non-negative integer. g_random_int(), however, can return any integer. Having RAND_FUNC returning nagtive values half of the time probably can cause all kind of strange behaviour in plug-ins that use it. When I changed the definition of RAND_FUNC to: #define RAND_FUNC() g_random_int_range (0, G_MAXINT) and recompiled the flame plug-in, it behaves just like on Unix. Recompiled plug-ins that use RAND_FUNC are available in www.gimp.org/win32/updates-rand-func-plug-ins.zip. Put them in GIMP's plug-ins directory. --tml
Re: Gimp for Windows v1.2 seems to have new bug
Moritz Grimm writes: These flames don't seem to work any more Well, somebody complained on the gimpwin-users mailing list that the *earlier* GIMP release's flame plug-in did not work very well compared to how it works on Unix... I really don't understand how the plug-in works... so I guessed wildly that maybe switching random number generator (from rand() to GLib's g_random_int()) might help. It did have some visible effect, but I still didn't manage to produce anything even vaguely like the example images on http://draves.org/flame/ . Maybe the flame plug-in is very sensitive to what random number generator is used, and works well only with the random() function available on most Unixes (but not in MS's C library). Does anybody on gimp-developer have any idea? However, now that I read that webpage, I notice that there is a stand-alone flame generator for Windows, using the same algorithms, available at http://www.uvm.edu/~msargent/main.htm . Have a look at that... It probably is faster than the GIMP flame plug-in. --tml
Splash screen suggestion from a user...
Forwarded from Scott Myers [EMAIL PROTECTED] hiya .. i was wondering if you knew where someone might submit a splash screen? i have one that doesnt look so bad, and thought maybe i'd send it to tigert (or whoever) maybe you know, get it included in the next dist. Put it on the web somewhere, and tell me, and I'll post a pointer to the gimp-developer list. http://home.rochester.rr.com/iamthecheeze/gimp/splash.html --tml
Re: [gimpwin-users] gtkrc
Fraxinus writes: Too change font/colors I have edited the global gtkrc at %windir%\gtk+ Im not too comfortable with that, shouldn't it be possible to do that on a per-user basis. I have tried to put it in %home% and in the %home%\_gimp1.1 dir, but it doesn't seem to work. It used to be posssible to have a user-specific gtkrc file for GIMP, in the user's .gimp1.1 directory (_gimp1.1 on Windows), but apparently this has changed at some time. (I had not noticed.) The user-specific gtkrc file that user_install (.bat) copies from the gtkrc (_user) file is not used at all. The GIMP's gtkrc file is now supposed to be a common one for all users of a GIMP installation. (Isn't the copying in user_install of gtkrc to the user's .gimp1.1 directory now unnecessary?) --tml
Re: Another bug in the lighting plug-in
I must be tired, I can't figure out a way to verify this, but I assume
this is a correct fix for a real problem? Unless somebody opposes,
I'll commit this.
Piet van Oostrum [EMAIL PROTECTED] writes:
I found another case where the lighting plug-in doesn't initialize
variables in non-interactive mode. This one didn't cause a crash, but
it gave wrong results. I suspect that there might another one as the
results for an interactive and a non-interactive application with the
same parameters are slightly different.
here is the (cumulative) diff:
--- lighting_apply.c.~1~Sun May 28 21:23:50 2000
+++ lighting_apply.cTue Aug 15 20:36:18 2000
@@ -94,13 +94,15 @@
{
gimp_pixel_rgn_init (bump_region, gimp_drawable_get(mapvals.bumpmap_id),
0, 0, width, height, FALSE, FALSE);
- precompute_init(width,height);
}
+ precompute_init(width,height);
if (!mapvals.env_mapped || mapvals.envmap_id==-1)
ray_func = get_ray_color;
else
{
+ env_width = gimp_drawable_width (mapvals.envmap_id);
+ env_height = gimp_drawable_height (mapvals.envmap_id);
gimp_pixel_rgn_init (env_region, gimp_drawable_get(mapvals.envmap_id),
0, 0, env_width, env_height, FALSE, FALSE);
ray_func = get_ray_color_ref;
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
UTF-8 vs. current locale charset mess...
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).
This causes some problems in GIMP. The code in fileops.c and
otherwhere doesn't take into consideration that strings obtained from
the user and strings that are passed to GTK+ are in in UTF-8, while
pathnames used in stat()/open() etc should be in the current
locale charset.
In GTK+ 1.3 currently the gtk_file_selection_get_filename() function
returns a string in the current locale charset, not UTF-8. However, if
it leads to cleaner code, this can be changed GTK+ 1.3 is a developer
version, and really used for "production" only on Windows, mainly for
GIMP. (What other apps might use it on Windows probably don't even try
to be i18n-correct anyway.)
GLib 1.3 has the functions g_filename_from_utf8() and
g_filename_to_utf8() to convert back and forth. They are not carved
into stone yet, either.
But... What do you think. Is it OK at this late stage to add code to
GIMP to do conversions back and forth to UTF-8? It would obviously be
done in such a way that everything would work as before on GTK+ 1.2.x
and Unix. There would just be some extra g_strdup()ing and
g_free()ing. The code would get a bit more verbose, like this:
#if defined (GTK_CHECK_VERSION) GTK_CHECK_VERSION (1,3,1)
#define FILENAME_TO_UTF8(fn) g_filename_to_utf8 (fn)
#define FILENAME_FROM_UTF8(fn) g_filename_from_utf8 (fn)
#else
#define FILENAME_TO_UTF8(fn) g_strdup (fn)
#define FILENAME_FROM_UTF8(fn) g_strdup (fn)
#endif
...
else if (status != PDB_CANCEL)
{
temp_filename = FILENAME_TO_UTF8 (filename);
g_message (_("Open failed.\n%s"), temp_filename);
g_free (temp_filename);
}
...
temp_filename = FILENAME_FROM_UTF8 (mfilename);
err = stat (temp_filename, buf);
g_free (temp_filename);
Etc. One would have to precisely indicate what string
variables/parameters are in UTF-8 and which are in the current locale
charset, and make sure these invariants hold. Or should I just ignore
this issue, and let it wait until GIMP 1.[34], which I assume will be
targetted to work with GTK+ 2.0?
Come to think of it, maybe it would be a good idea to introduce an
opaque type to GLib 1.3 "GSystemCharsetString" or something, to be
used for all strings that are in the locale-dependent charset. This
type would actually be just gchar[], but the compiler wouldn't know
that, and thus it would be easier to keep count of what strings are in
what encoding. Have to think more on this.
--tml
Re: Gimp Win32 and -Wall patch
I already tried to answer this from Berlin, but apparently CCC's SMTP server didn't like me. Apologies to gimp-developers who couldn't care less for the Windows version ;-) Hans Breuer writes: Attached a patch to compile Gimp on Win32 with M$VC again. Could anyone with CVS access apply it, please? Yes, I will, to the extent it doesn't interfer with other stuff. * */makefile.msc: - get the definition of GLIB, GTK etc. out of a single file instead of copy and pasting between all makefiles. This is particular usefull while the CVS version on Win32 is quite broken. This is in the progress of being taken care of on the gcc side by using the CVS module "build" which has a makefile snippet in "build/win32/make.mingw" to be included in other makefiles when building for mingw with gcc. Your file belongs there. Actually, I wouldn't mind if somebody else (you) would take over the maintenance of the MSVC build stuff completely. It is hard enough to keep the gcc/mingw makefiles up-to-date... (Well, not hard, but tedious. Yes, I know I really should look closer into getting the latest-and-greatest auto*, configure and libtool stuff working also for gcc builds on Win32. It is not necessarily that hard. After my vacation...) As for the CVS version of GTk+, it is indeed currently very much broken on Win32. (Especially after the recent merge of the Pango stuff. I won't be able to make publicly available any work I'll do on it until July, as I am leaving for vacation without net access tomorrow. I will take my laptop and hack on stuff...) For a working GTk+ on Windows, use the CVS sources as they were before the merge of the no-flicker branch. (Probably easiest to download the gtk+-src zipfile from the web page.) * plug-ins/makefile.msc: Change all Plug-Ins to console build - no known drawbacks, main benefit: reusage of Gimp's console. Hmm, but isn't gimp.exe's console window destroyed as soon as it has started? I don't remember the reason why gimp.exe was changed to be a console application in the first place. In fact, I have been considering changing it back to a windowing application to get rid of the annoying flashing console window at start. --tml
Re: IrfanView
Hago Ziegler writes: Now he told me that he can't find sources or specifications, so he can't do it. Huh? The GIMP sources are easy to find. The only documentation for the xcf format *is* the source code in xcf.c and other files. It's a pity. What's going wrong, that it ends up like this? Wouldn't it be good for Gimp, if there would be an external viewer to watch the files? Yes and no. He told me that he wouldn't be making the viewer able to parse xcf files completely, anyway, as that would be too complex. Only the bottom layer would probably be shown. (This is how IrfanView works for psd (Photoshop) files, too, I think.) And as the only reasonable reason to use xcf format in the first place is when you are working on some multi-layer or otherwise complex image in the GIMP and want to save it between editing sessions, wouldn't it be counter-productive if IrfanView would show only the bottom layer? Xcf is not intended to be an image distribution format, or an image interchange format between applications. I don's see why anybody would distribute xcf images except if they are 100% sure that the recipient(s) are going to work on them with the (same version of) GIMP. --tml
missing export gtk_paned_set_gutter_size from GTK-1.3.DLL
Antti Lukats writes: I get missing export gtk_paned_set_gutter_size from GTK-1.3.DLL where can I get GTK dll that works or is there something else wrong? I am trying to use GTK with freepascal/lazarus on win32 That's the price one has to pay when using in-development libraries (i.e., GTk+ 1.3). There is no such function any longer in GTk+. You have to recompile the freepascal/lazarus (whatever they are) libraries with the same version GTk+ headers as your DLL and import library is. I.e., the headers I distribute either in the gtk+-src or gtk+-dev zipfiles. (This is quite off-topic for gimp-developer, btw, so please don't send follow-ups there.) --tml
Re: signal invalidate preview?
Emil Brink writes: Um, is there currently a nice, clean, preferrably non-periodic way of determining (from a plug-in) if a drawable has changed? If not, are there plans to add one? It would be very useful... A somewhat related question: What should a plug-in do to get guidelines on an image updated? The gpb plug-in (when saving an image as a gih (pixmap brush pipe)) adds guidelines to the image, but they don't show up until you force a redraw of the image. It also deletes and re-adds the guidelines at new positions as feedback to the user input in the save dialog, but again this doesn't show up until you cause a redraw of the image. The plug-in calls gimp_displays_flush(), but that doesn't help. --tml
Colour balance
I think it is time to repeat this message, from a year ago... The same
strange-looking code is still present in color_transfer.c. Is it a
bug? Should it be fixed before 1.2? Is my suggestion below a good one?
It seems obvious to me that the current color_transfer_init() function
in color_transfer.c has some cut-and-paste bug in it:
for (i = 0; i 256; i++)
{
highlights_add[i] =
shadows_sub[255 - i] = (1.075 - 1 / ((double) i / 16.0 + 1));
midtones_add[i] =
midtones_sub[i] = 0.667 * (1 - SQR (((double) i - 127.0) / 127.0));
shadows_add[i] =
highlights_sub[i] = 0.667 * (1 - SQR (((double) i - 127.0) / 127.0));
}
Note how the third assignment statement uses the same value as the
second. Can this be the intention, that adjusting shadows up is the
same as adjusting midtones up? (And adjusting highlights down the same
as adjusting midtones down.)
And, what *is* the definition of what the colour balance adjustment
should do? I couldn't find any deeper explanation in my Photoshop
books. Are the sliders you adjust from -100 to 100 percentages (in
that case, percentages of what?), or pixel values?
I would tentatively suggest replacing those lines with the following
code. This uses Bernstein polynomials as weight curves, with are
scaled with the difference from the min or max channel value (0 or
255) and the current value, depending on if we are subtracting or
adding. (Er, that probably isn't very clearly said. Play with gnuplot
to visualize these curves... Gnuplot rocks.)
for (i = 0; i 256; i++)
{
/* Let's try using Bernstein polynomials... At least this gives
* a certain smoothness to the transfer functions. This is
* definitely not what P*shop, uses, however. In P*shop if you
* apply +100 shadows and -100 highlights, you get back what you
* started with. Should this be our goal, too? To me, this seems
* conceptually a bit odd, why should reducing red from
* highlights be the opposite of adding red to shadows? Note
* that it doesn't work in the other order, though, so maybe
* it's just a coincidence, and not a design goal. */
#define C41 ((4*3*2*1)/(1 * 3*2*1))
#define C42 ((4*3*2*1)/(2*1 * 2*1))
#define C43 ((4*3*2*1)/(3*2*1 * 1))
#define B14(u) (C41*u*(1-u)*(1-u)*(1-u))
#define B24(u) (C42*u*u*(1-u)*(1-u))
#define B34(u) (C43*u*u*u*(1-u))
shadows_add[i] = B14((double) i / 255.0)*(255 - i);
shadows_sub[i] = B14((double) i / 255.0)*i;
midtones_add[i] = B24((double) i / 255.0)*(255 - i);
midtones_sub[i] = B24((double) i / 255.0)*i;
highlights_add[i] = B34((double) i / 255.0)*(255 - i);
highlights_sub[i] = B34((double) i / 255.0)*i;
}
And the code that uses these tables, in the function
color_balance_create_lookup_tables() in color_balance.c, would be
modified as follows (treat the slider values as percentages of the
above values, clamp each channel value only once ).
r_n += cbd-cyan_red[SHADOWS]/100.0 * cyan_red_transfer[SHADOWS][r_n];
r_n += cbd-cyan_red[MIDTONES]/100.0 * cyan_red_transfer[MIDTONES][r_n];
r_n += cbd-cyan_red[HIGHLIGHTS]/100.0 * cyan_red_transfer[HIGHLIGHTS][r_n];
r_n = CLAMP0255 (r_n);
g_n += cbd-magenta_green[SHADOWS]/100.0 * magenta_green_transfer[SHADOWS][g
_n];
g_n += cbd-magenta_green[MIDTONES]/100.0 * magenta_green_transfer[MIDTONES]
[g_n];
g_n += cbd-magenta_green[HIGHLIGHTS]/100.0 * magenta_green_transfer[HIGHLIG
HTS][g_n];
g_n = CLAMP0255 (g_n);
b_n += cbd-yellow_blue[SHADOWS]/100.0 * yellow_blue_transfer[SHADOWS][b_n];
b_n += cbd-yellow_blue[MIDTONES]/100.0 * yellow_blue_transfer[MIDTONES][b_n
];
b_n += cbd-yellow_blue[HIGHLIGHTS]/100.0 * yellow_blue_transfer[HIGHLIGHTS]
[b_n];
b_n = CLAMP0255 (b_n);
cbd-r_lookup[i] = r_n;
cbd-g_lookup[i] = g_n;
cbd-b_lookup[i] = b_n;
Comments, please?
--tml
Dead code in app/selection.c?
Looking at selection.c, I think I notice that there is some dead code in there. As USE_XDRAWPOINTS is #defined (and apparently always has been?), the gc_in field (GdkGC*) in GSelection structs doesn't seem to be actually used for anything. It is created, and various attributes of it are set, but the only place where it would be used is in the #else part of an #ifdef USE_XDRAWPOINTS. --tml
Re: An experiment (was Re: Move help menu item...)
One suggestion would be to not have the toolbox user-resizeable via the window manager at all, but to have in the Preferences a setting where you use a spinbutton to set the number of columns. If you start from, say, three columns, and keep increasing the number, at the point where the number of rows is less than the number of columns, the colour, brush, pattern and gradient selectors could automagically jump to be at the right side instead of the bottom. --tml
Let's squeeze that i18n bug!
Could this be related to this bug that I found in GTk+ in November. Tue Nov 16 10:15:54 1999 Owen Taylor [EMAIL PROTECTED] * gtk/gtkitemfactory.c (gtk_item_factory_parse_path): If translation does not include a '/', use entire translation instead of crashing. (That was after GTK+ 1.2.6 was released.) From: Owen Taylor [EMAIL PROTECTED] To: Tor Lillqvist [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: gtk_item_factory_parse_path() problem with incorrect translations Date: 16 Nov 1999 10:30:51 -0500 Tor Lillqvist [EMAIL PROTECTED] writes: Hi, There is a problem with gtk_item_factory_parse_path() if it encounters a bogus translation string (typically one of those fuzzy translations I assume the gettext tools generate as more or less pathetic guesstimates by themselves?). If the translation doesn't contain any Hmmm, but fuzzy matches are disabled by default until someone hand-edits them in... slash, the code at the end of gtk_item_factory_parse_path() obviously will crash. This can be demonstrated by running the GIMP with LANG=ru, for instance. It might be argued that translations are supposed to be correct, and that crashing is thus OK? Anyway, suggested fix below. Hmmm, sort of embarassing. I've been saying for a long time that the translations do _not_ need to contain the full path, since everything but the last component is simply ignored. So, the change that makes it do what I thought it was doing is: Index: gtkitemfactory.c === RCS file: /cvs/gnome/gtk+/gtk/gtkitemfactory.c,v retrieving revision 1.21.2.5 retrieving revision 1.21.2.6 diff -u -r1.21.2.5 -r1.21.2.6 --- gtkitemfactory.c1999/10/07 21:29:41 1.21.2.5 +++ gtkitemfactory.c1999/11/16 15:25:48 1.21.2.6 @@ -968,7 +968,10 @@ translation = str; p = strrchr (translation, '/'); - p++; + if (p) +p++; + else +p = translation; *item = g_strdup (p); Thanks for pointing this out, Owen
Re: Translation inconsistency
My vote: (B) don't mark the strings for translation, not in the core, neither in the plug-ins There is enough work for translators anyway, without having to translate stuff intended only for developers. --tml
Re: Colormanagement
Marc Lehmann writes: So much for ANSI-C: ../include/lcms.h:38: windows.h: No such file or directory typedef HANDLE cmsHPROFILE; WORD GammaTable[1]; cmsHPROFILE LCMSEXPORT cmsOpenProfileFromMem(LPVOID MemPtr, DWORD dwSize); Well, he does say it is intended for the Windows platform, so this is to be expected. Including windows.h is for a programmer on Windows as natural as including stdio.h for C programmers in general. Of course it is sad that people write an inherently portable library using Windows-specific types etc, but that's life. (Note: I do *not* consider myself a Windows programmer, but I play one on this list ;-) Most of these types have obvious counterparts in GLib. (WORD = guint, HANDLE = gpointer, LPVOID = gpointer) The real challenge when/if porting this is if some Win32 feature that does not have a portable equivalent is used. the c standard (double definitions, indented preprocessor constructs, nice calls to the ansi function "MessageBox" etc..) And a corresponding Unix library would call the ansi function "syslog"? GIMP certainly is better, but for instance much of GNOME was pretty infested with non-ANSI gccisms or gnumakeisms still quite recently. --tml
Re: opinion of end-users
Glyph Lefkowitz writes: XInput *obviously* won't work on Win32, since it's **X**input ^_^ (sarcasmhm, I wonder, maybe we could use DirectX-Input or something/sarcasm)) The tablet input was just temporarily broken in the Windows GTk+ version in the currently distributed GIMP for Windows snapshot. The brokenness was a side-effect of the code changes when the GDK backends were reorganised. The code to support tablet input on Windows has been in GTk+ for some time. (Obviously it doesn't use XInput, but another API, called WinTab.) That said, I certainly admit that the tablet support on Windows needs improvement. --tml
[patch] escaping double quotes in SF_STRING values
Tamito KAJIYAMA writes: I've just installed 1.1.15 and found a bug (IMO) that Script-Fu failed if a string containing double quotes was given as an argument of the SF_STRING type. Attached is a quick and dirty patch for fixing that bug. This patch is unnecessary when using GLib 1.3 or later, as the whole point of g_strescape() (which is what the ESCAPE macro in the source calls) is to escape chars that are risky in a C (or script-fu) string, like double quotes or nonprinting characters. Unfortunately g_strescape as implemented in GLib 1.2 escapes only backslashes... (because or my shortsightedness, I confess), not double quotes (or nonprinting characters). However, the code in the GIMP that uses g_strescape() gets unnecessary complex if we start taking that into consideration. Wouldn't it be far simpler to release a newer version of GLib 1.2, with g_strescape() having the same calling convention as before (the prototype was changed in GLib 1.3 (partial sigh)), but with a wider range of characters handled, and then require this GLib version (1.2.7?) for the development GIMP? --tml
[gimpwin-users] PNG blank display bug
Matt.Wilkie writes: I'm getting this weird display problem with some PNG images, a sample is attached. Please let me know if you do/don't have similar problems. The PNG apparently claims to have the display (and print) resolution of 0 pixels/inch... Set it with ImageScale ImagePrint Size Display UnitResolution X and Y and the image appears. The PNG plug-in probably should check for this and use some sensible default if the file claims 0 dpi? --tml
minimal install?
Seth Golub writes: Given enough disk space, sure, I'll install whirlpinch, but 55MB is more than I can afford on my school account. Er, why don't you ask the sysadm to install the GIMP in some public place for everybody to use? Isn't it rather counter-productive if possibly several users install private copies of useful applications like the GIMP? --tml
CVS Gimp does not compile
Jarda Benkovsky writes: whenever I try to compile CVS Gimp, it crashes when compiling gdyntext - undefined symbol gdk_font_list_free You shouldn't be using the HEAD branch of GTk+ on Unix/X11. Especially not now when its in the middle of massive changes. (It used to be for a long time that the X11 parts of HEAD GTk+ wasn't being touched, but now that has changed.) Use GTk+ 1.2 (the gtk-1-2 branch in CVS). --tml
Re: GIMP Plug-ins for other Apps? - LGPL for some GIMP modules?
Marc Lehmann writes: On Thu, Nov 11, 1999 at 10:47:48PM +0200, Tor Lillqvist [EMAIL PROTECTED] wrote: It is possible that I decided to use the GPL header because the code in gimpenv.c was partly moved from gimp proper, which is GPL. That's bad, so libgimp in cvs is actually GPL ;- My dreams come true ;) I don't think gimpenv.c is in any way unique in this sense, probably many of the other files in libgimp also contain code snippets that have originally been in some file in the GIMP proper. --tml
Re: [gimp-devel] Re: Help System
Maybe the time has come to fold GtkXmHtml into the main library. Ugh... cough, cough. Have you looked at the GtkXmHTML (or however it should be capitalized) source code? One would hope GTk+ has higher standards. Not to mention that the "Gtk" part of the GtkXmHTML name is quite misleading, there are lots of direct Xlib calls. --tml
Re: modules cleanup
Asbjoern Pettersen writes: The OS/2 and UNIX code is doing the same ! The structure PLUG_IN_INFO is a REAL input and should be a parameter input to gimp_main().ex: gimp_main(argc,argv, PLUG_IN_INFO); On UNIX they trust/use fork() to input the structure, but my OS/2 version will work on all system with or without forking. Sorry, I don't follow you here, I don't see any forking going on. To my understanding, PLUG_IN_INFO is (on Unix) a (data) entry point (i.e. a externally visible variable) in the plug-in executable, and the libgimp shared library references it. The problem with PLUG_IN_INFO on OS/2 apparently is that it's hard on OS/2 to refer to exported variables in the executable that has loaded a shared library from the library. Although on Win32 you could look up the PLUG_IN_INFO address in the plug-in executable from the DLL (as long as it is marked for export), I do it almost like OS/2: I pass the address of PLUG_IN_INFO to a function in libgimp, that stores it in a place easily accessible to libgimp. (On OS/2, you store a copy of PLUG_IN_INFO in libgimp, while on Win32 I only store a pointer.) I agree with you, the "pass PLUG_IN_INFO address as parameter from the plug-in to gimp_main in libgimp" approach could well be used for all platforms, it would clean up the ifdefs in gimp.c and gimp.h quite a bit. --tml
Re: Help System
Uwe Koloska writes: Consider that GtkXmHTML cannot be compiled on linux libc5 systems (or generally systems without thread support) because it needs the threaded version of strok() strtok_r(). Not to mention it's a bit impossible to build on non-X11 systems ;-) But I'm not complaining. But I (or somebody) will probably eventually write a separate winhelpbrowser plug-in for Windows that just uses the user's default Web browser (Netscape or IE). --tml
