[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.gim
(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), a
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 b
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 generat
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 w
Tor Lillqvist writes:
> [...] you are saving an image that has been loaded from a .tub file
> and thus has the gimp-brush-pipe-parameters parasite set up
> already, containing the necessary information.
Hmm, but note that many of the .tub files out there *don't* have
Marc Lehmann writes:
> no, but I have this (this is what I originally used on tehe fair), it
> comverts all *tub-files given as arguments to .gih-files.
>
> perl -MGimp -e 'Gimp::init; Gimp::set_trace(-1); for(@ARGV) { \
> my $img = Gimp->file_load(($_)x2); s/.tub$/.gih/; \
Marc Lehmann writes:
> On Sat, Nov 11, 2000 at 08:19:55PM +0200, Tor Lillqvist <[EMAIL PROTECTED]> wrote:
> > I see two calls to gimp_pixpipe_params_init(&gihparms)?
>
> None of whose are called with GIMP_RUN_NONINTERACTIVE.
Umm, yes ;-) There is a FIXME comment abo
Marc Lehmann writes:
> file_gih_save in current cvs saves ALL images with the following header
> (or similar):
> H Bare Bush.gih:0 ncells:0 cellwidth:0 cellheight:0 step:0 dim:0 cols:0
> rows:0 placement:(null)
>
> and no image information at all. (file_gih_save does not allow you to
> sp
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
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
Marc Lehmann writes:
> No, this is not a spam, but rather funny... A friend of mine saw a
> windows-"freeware"-cd with all sorts of features, including "gimp version
> 2". He bought it and installed it (it was, of course, a gimp-1.1.2x).
Heh. BTW, did the CD include the source zipfiles? I alwa
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-interact
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 byte
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.
Daniel writes:
> Will Gimp 1.1.24 work with gtk+ 1.3.0? I am working on Gimp for BeOS
> and the port of gtk+ that I have is roughly 1.3.0 and there is no
> port of the 1.2.x branch.
I would say so, yes, if you by 1.3.0 mean GTK+ as it was some months
ago. The Win32 port has been using the g
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,
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 thi
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., G
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 im
Irfan Skiljan writes:
> My name is Irfan, I am the maker of IrfanView, maybe you know it ;-)
Yup, I have read recommendations for it, sorry to say I haven't tried
it myself yet.
> I got now several emails from users with the wish to add XCF reading
> support in my viewer.
I don't know if th
I think it would be a very useful feature to be able to open a JPEG in
the GIMP, do some editing that touches just a small minority of the
pixels like correcting red-eyes, and save just the edited parts,
keeping the rest of the JPEG unchanged. (Not talking about individual
pixels, of course, but t
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
Adam D. Moss writes:
> > * app/cursorutil.c (gtkutil_compress_motion)
> > * app/edit_selection.c (process_event_queue_keys): Guard against
> > gdk_event_get returning NULL (which can happen at least on Win32).
>
> I'd kinda like to see this reverted and fixed at the WIN32 GDK level
> --
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 t
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 r
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 Lillqvis
> libartprovides convenient and optimized functions for all sorts of
> gdk-pixbufimage-loading and simple (but fast) transformations (we may
FYI, these two libraries are quite portable, there was little problem
in building them on Win32. (Well, I skipped the recently added
gnomecan
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
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 platfo
Kelly Lynn Martin writes:
> Just a note: ambiguities in the terms or scope of a license are
> resolved in favor of the licensee.
Which I guess means that one should grab the sources *now* while they
are under the LGPL, before he changes his mind ;-) ?
--tml
Martin Weber writes:
> Here is an interesting colormanagement for future GIMP releases:
> http://www.abaforum.es/martim/lcms.htm
Yes, that seems very interesting. But it says: "lcms only works under
windows/Intel platforms". The READ.ME says: "lcms has been written for
Borland C++ 4.5 [...] Vis
Ar't writes:
> proposition (despite Gimp freezing):
I like your idea. (I still think it's definitely inappropriate to add
this kind of new functionality, even if it is very nice, to GIMP 1.1
(1.2), sorry.)
However, I don't quite see how dragging the mouse around in the
popped-up window could be
Glyph Lefkowitz writes:
> XInput *obviously* won't
> work on Win32, since it's **X**input ^_^ (hm, I wonder, maybe we
> could use DirectX-Input or something))
The tablet input was just temporarily broken in the Windows GTk+
version in the currently distributed GIMP for Windows snapshot. The
br
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 o
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 Image>Scale Image>Print S
Hans Breuer writes:
> That's all. Could somebody be so kind to apply these changes to CVS
> (or tell why not).
I'll apply most of these soon. Except for the makefile.{cygwin,msc}
changes to use the gtk_cfg.inc file, I am trying to think of some
better way to handle that first. (Yeah, auto* etc
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 in
Marc Lehmann writes:
> However, if we solve this problem by *linking* libintl against libgimpui
> we get another problem: linking against libintl automatically puts
> libgimpui under the GPL.
That depends on exactly what source code you use to build libintl. The
"intl" directory from glibc is
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
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.
>
>
Marc Lehmann writes:
> There certainly is the COPYING file and the files all refer to the library
> GPL, I think that is clear enough!
> Except... gimpenv.c...
Hmm. It was I who originally created that file, and I don't remember
if putting in a header referring to the GPL (and not the LGPL) w
> 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, ther
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
Thanks for suggesting GIMP to TUCOWS, but there are a couple of points:
- The GIMP is not Shareware. It's Free Software.
- The prebuilt "installer" version of GIMP for Windows I distribute
from my web page needs to be cleaned up a bit before it can be
redistributed by TUCOWS or others in a l
Marc Lehmann writes:
> a) unlink might not succeed on non-unix-systems. cure: ignore the error from
>unlink and try to unlink it again after closing the file
At least on Win32, and probably on OS/2, too, it is possible to open a
file so that it will be automatically deleted after closing. T
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. B
47 matches
Mail list logo
