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
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
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,
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
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
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
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
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
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
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,
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
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
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
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
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
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
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.,
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?
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,
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
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
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
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
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
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
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
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
(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
[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
29 matches
Mail list logo
