On Friday, 16 Feb 101, Miles O'Neal wrote:
Robert L Krawitz said...
|
|Under what circumstances is RUN_WITH_LAST_VALUES intended to be used?
|Is it something I should be particularly concerned with in the print
|plugin, or would dropping it be reasonable?
It's for when you want to rerun
On , 9 Feb 2001, Jens Lautenbacher wrote:
Therefore I propose to completely rewrite everything that can be
considered a "PaintObject" into a generic provider form, where the
paintcore for each operation asks the provider for it's data.
It would be nice to be able to use loadable modules to
On Saturday, 10 Feb 2001, David Monniaux wrote:
Exactly which functions handle the low-level actual enlargement or
shrinking of display? I'd like to write MMX versions for them.
I modified the original code to handle non-integer scale factors. It
lives in image_render.c
I'm not sure how
On Monday, 5 Feb 2001, Jay Cox wrote:
Linear, Log, and sqrt are all common ways to scale histograms for display.
Perhaps we should make it an option in preferences (or in the histogram
display itself).
sqrt() - I haddn't thought of that. That sounds plausibly like what
Photoshop is using.
On Thursday, 8 Feb 2001, Frank de Lange wrote:
[fonts work on some images, but not others]
Check both image's resolution: they're probably different.
If you ask the text tool for text in a particular "point size", then
it needs to scale it so it comes out at the right size for the image's
On Sunday, 4 Feb 2001, Roel Schroeven wrote:
I noticed in the source code that the histogram widget uses a logarithmic
scaling. Is there a reason to do it that way, as Photoshop et al. seem to
use a linear scaling.
I just checked the CVS history; we've been using a log y axis (ie
pixel
On Sunday, 4 Feb 2001, Nick Lamb wrote:
What does the GTK+ selector bring to the party anyway?
Nothing: it's a "demo" piece of code showing how to interface your
colour selector to the GIMP module API. The point being that there is
no actual colour selector code there, since it's all in GTK,
On Saturday, 3 Feb 2001, Roel Schroeven wrote:
In gimphistogram.c there is a function to calculate the histogram for a
subregion, declared as follows:
gimp_histogram_calculate_sub_region (GimpHistogram *histogram,
PixelRegion *region,
PixelRegion
On Wednesday, 24 Jan 2001, Scott McDaniel wrote:
Unfortunately, one of the responses was a tad over the top, and I
felt I needed to reconfirm our request...
Yes, we understand the license; yes, we also understand that Gimp CAN be
distributed freely, however, we chose to be courteous and
On Saturday, 6 Jan 2001, Orson Jones wrote:
As I was reading 'Grokking the GIMP' I came up with some ideas.
Unfortunantly, I don't have the skills/knowledge to implement these
myself, So I hope I can describe them well enough that you can
figure out what I'm thinking. If I still don't
On , 8 Jan 2001, Sven Neumann wrote:
A short patch like this one can always be sent through this list.
But I'd prefer if you could redo the patch, because of the following
reasons:
- it reverts a change in the preferences dialog. You obviously
didn't cvs update before creating the
On Wednesday, 13 Dec 2000, Rebecca J. Walter wrote:
"Guillermo S. Romero / Familia Romero" wrote:
[EMAIL PROTECTED] (2000-12-13 at 0057.14 +0100):
I think it would be a good idea to add a grid function like some other
Are you speaking about something like the Perl scripts that
On Monday, 11 Dec 2000, Paul E.C. Melis wrote:
Hi, I wrote about the "initial_sub_region:: error :: src-w * (src-bytes +
1) 521" bug/message to this list some time ago, and now it appears
somebody has submitted a bug report to the bug list about it (which I should
have done myself in the
Please Yosh, can we have another 1.1.x pre-1.2 test release? There
are a bunch of bugfixes that have gone into 1.1.29 and it would be
nice to get another release candidate out.
Austin
On Tuesday, 5 Dec 2000, David Bonnell wrote:
On Wed, 6 Dec 2000, Austin Donnelly wrote:
...
Probably the easiest way would be to use select by colour, but that
would catch other stuff that was a similar colour.
Could change "Select by Colour" to only select pixels within t
On , 24 Nov 2000, Philip Armstrong wrote:
I've patched the PhotoCD (pcd) plugin xhpcd to work with the latest
devel gimp, but had no response from the author. So if anyone wants a
copy of the patch, feel free to mail me at [EMAIL PROTECTED]
Yes.
If it's short, please send your patch to
On Friday, 24 Nov 2000, Lourens Veen wrote:
About three weeks ago now I found a bug in the TGA loader. I patched it
and sent the patch to [EMAIL PROTECTED] I got a reply that it had been
forwarded to the maintainer of the plugin, but I haven't heard anything
since. So I'm trying the
On Friday, 24 Nov 2000, Philip Armstrong wrote:
On Fri, Nov 24, 2000 at 10:27:08AM +, Austin Donnelly wrote:
On , 24 Nov 2000, Philip Armstrong wrote:
I've patched the PhotoCD (pcd) plugin xhpcd to work with the latest
devel gimp, but had no response from the author. So if anyone
On Friday, 17 Nov 2000, Garry R. Osgood wrote:
If no one objects, I would like to elevate #10498 from 'critical'
to 'grave.' Through a chain of causuality originating with edit-select
not being able to perform a thaw, eventually (sometimes) there is
a fatal crash in undo. Not sure why, but
On Friday, 17 Nov 2000, Garry R. Osgood wrote:
[...]
In light of an (is it coming? Really?) 1.2 Release
The question I have for the group is:
1) Document, warn, but otherwise ignore the problem.
It affects users with a certain type of tablet hardware
and only when that hardware is
Donnelly
[EMAIL PROTECTED]; merged with #22375; 99 days old.
#17906: layer move mouse handling not pixel-perfect
Subject: gimp; Severity: grave; Reported by: Austin Donnelly [EMAIL PROTECTED]; 99
days old.
#25272: [gimp-bug] The thumbnails (.xvpics) do not always match the image.
Subject: gimp
On Wednesday, 25 Oct 2000, Jeff Sheffield wrote:
the splash screen hangs with the subtitle
Plug-ins
and the path
/opt/gimp/gimp-1.1.28/lib/gimp/1.1/plug-ins/script-fu
another interesting thing that happens is.
when I ctrl-C the app I get the following strange output
-
On Friday, 20 Oct 2000, Tuomas Kuosmanen wrote:
While I have been doing some larger images, mostly 1600x1200 size and
bigger, I have noticed that if I zoom the image smaller, I get a lot of
one-pixel wide vertical artifacts when I move floating selections around. I
think I have had the "view
Can anyone actually access cvs.labs.redhat.com?
I don't get any replies to my SYNs!
Austin
On Monday, 2 Oct 2000, Raphael Quinet wrote:
On Sun, 01 Oct 2000, "Dr. David Kirkby" [EMAIL PROTECTED] wrote:
Thanks to everyone who suggested I increase the amount of shared
memory on my SPARC so Gimp would not disable shared memory tile
transport. I added this to /etc/system:
set
On Monday, 25 Sep 2000, Nick Lamb wrote:
1. VAGUE: Documentation should be "good" (definition anyone?)
2. Critical/ Severe bug reports should be fixed or marked down (bug #s?)
3. VAGUE: Gimp should build out-of-box on lots of systems
99. Find and #ifdef any debug scribble to console
100.
On Tuesday, 26 Sep 2000, Tim Mooney wrote:
@@ -2322,6 +2322,7 @@
G_IO_ERROR_NONE,
G_IO_ERROR_AGAIN,
G_IO_ERROR_INVAL,
+ G_IO_ERROR_INTR,
G_IO_ERROR_UNKNOWN
} GIOError;
This breaks backwards binary compatibility, since the numeric value of
G_IO_ERROR_UNKNOWN changes. I
On Thursday, 31 Aug 2000, Maurits Rijk wrote:
3) sometimes it's just lack of C knowledge:
if (p)
free(p);
can be simply replaced by just:
free(p);
I would not assume that it is safe to free() a NULL pointer in _all_
vendor's libc implementations. That's why
On Tuesday, 22 Aug 2000, Uwe Koloska wrote:
possibly this one is fixed -- for now I am only using 1.1.18 from SuSE 6.4.
(I'm checking this with 1.1.25).
With this (and possibly later versions) it is possble to save an RGB image
to xpm format. I don't know the xpm format, but the xpm code
On Tuesday, 1 Aug 2000, Marc Lehmann wrote:
On Mon, Jul 31, 2000 at 09:29:01PM -0400, Robert L Krawitz [EMAIL PROTECTED] wrote:
Any suggestions? Is Red Hat broken, or is it our configure script?
Obviously, if gimptool is missing the rpm source (e.g. the distro) is
broken, as is the usual
On Tuesday, 1 Aug 2000, Alexander Skwar wrote:
Can I somehow use gimptool to do this? I thought about something like
"gimptool --prefix ~/tmp/prefix-dir --install-admin-bin pluginfile", and
then gimptool should install "pluginfile" to
"``~/tmp/prefix-dir''/usr/lib/gimp/1.1/plug-ins/",
On Monday, 31 Jul 2000, Kevin Turner wrote:
[Kevin checks the latest mail. Now it seems we have a help template
file in HTML. Okay. Uh-oh, it's under a non .gimp.org domain, Sven
will frown about that.]
The template includes "-" as a menu path separator.
The problem with this is that it
On Wednesday, 19 Jul 2000, Sven Neumann wrote:
Can someone close the following bugs? I have reported this twice to
[EMAIL PROTECTED], but no one closed them.
#12303, #12302, #12298
Wouldn't it be easier to close them yourself instead of asking other
people? Especially since closing
On Tuesday, 18 Jul 2000, [EMAIL PROTECTED] wrote:
Attached is a patch file for gif.c that fixes a bug that made a dialog pop
up when running noninteractively, which was messing up my scripts.
It was written against 1.1.23 and 3.0.2 of gif.c in plug-ins/common/.
If someone with the right
On Monday, 5 Jun 2000, Carey Bunks wrote:
Yes, I've seen this bug, too. Although it is impossible to undo these
operations with C-z, it is possible to undo them by opening the Undo
History dialog and explicitly clicking on the preceding strip in the
list. After having done this, C-r and
On Tuesday, 30 May 2000, [EMAIL PROTECTED] wrote:
On Tue, 30 May 2000 11:27:37 -0400, Phil Schwan [EMAIL PROTECTED] said:
Do you know who all of the copyright holders of that code are?
At least myself, Peter, Spencer, and Adam Moss. There are almost
certainly others.
I can't remember
On Friday, 12 May 2000, Marc Lehmann wrote:
[1: plugins should have the system default signal handers, not gimp ones]
[2: main gimp app should have system default SIGPIPE handler]
Point 1: I mainly agree with this. I can't think of a need to hook
any signals. Did plugins used to give
On Monday, 8 May 2000, Michael Natterer wrote:
Unfortunately this is not the reason why gimp dies on just any aborting
child. Although I 100% agree that SIGPIPE being fatal is the wrong thing
to do. I browsed CVS and Gimp is connecting SIGPIPE to on_signal() since
the beginning of CVS time.
On Tuesday, 9 May 2000, [EMAIL PROTECTED] wrote:
-- Problem description:
When compiling, SA_NOMASK is undefined.
-- Other comments:
Checking a RedHat 6.2 machine indicates this is simply
#define'ed from SA_NODEFER. Adding the folowing code to
app/main.c and libgimp/gimp.c solves the
Please can people put a quick explanation of why they're closing a bug
report into the close email. If it's fixed in CVS, a cut-n-paste of
the relevant ChangeLog entry that addresses the problem would be
cool. Otherwise, just a sentence or two would be enough.
Austin
Current gimp (1.1.21) seems to have problems with recovering from any
plugin that dies. Things start going wrong when it takes a SIGPIPE
while trying to write(read?) to the pipe to the plugin which is dead.
Rather than ignoring SIGPIPE, and collecting an EPIPE from the io
operation and using
On Monday, 27 Mar 2000, Simon Budig wrote:
Well - unfortunately this disables "user multitasking" with working
on multiple images. Admittedly I dont do this too often, but sometimes
it is nice to paint something while waiting for a big image to
rotate. (just tested - multiple plugins do
On Saturday, 25 Mar 2000, Simon Budig wrote:
The defaults from gimprc are questionable IMHO. The default imagesize
is not specified and defaults to something around 950x760, which is
pretty close to my screen resolution. Maybe we should default to
something like 300x300 ?
The default is
On Saturday, 19 Feb 2000, Robert L Krawitz wrote:
Pending a general way to scale images separately on X and Y axes, what
would be your (collective) suggestions about how to handle an image
with different X and Y resolutions?
This happens so rarely that I would (for the moment) ignore it.
On Thursday, 17 Feb 2000, Raphael Quinet wrote:
My 0.02 Euro: I would like to change the Edit-Fill behaviour globally
and at the same time provide a three-lines script (or code in the
core) that would register itself as "Edit-Fill with BG" and would
swap the colors, call gimp-edit-fill and
On Monday, 14 Feb 2000, Thomas Linder wrote:
May well be all three of my suggestions already got discussed:
Save Copy As...
with its own set of file paramaters including filename
This already exists. The menu option is "File/Save as..."
Autosave
option to save automatically
On Sunday, 13 Feb 2000, Kevin Cozens wrote:
So I am not the only one that has the usage pattern with fill listed
above. I don't know if its from other graphics programs I have used
or just what made sense to me but I expected fill to use the
foreground colour. I mean after all, you don't
I just spoke to someone who tried to get rid of the alpha channel on
their image before saving it (his gimp was pre-export stuff).
It's true that, even though I knew what I was looking for, it took me
a while to find the flatten option.
The deceiving thing is that while "Image/Image/Alpha/Add
On Saturday, 12 Feb 2000, Sven Neumann wrote:
[well known cursor pos overwriting bug]
This is not a bug in gimp but in the gtk theme you are using. Therefore it
is not our problem.
Maybe we should make it our problem.
I think that given the number of people who are bitten by this, is
Hi,
One problem that people mention on comp.graphics.app.gimp quite
regularly is that gimp says "load failed" on some EPS files.
This happens when the EPS file doesn't have a "showpage" command on
the end of it.
Actually, EPS files probably shouldn't use an explicit showpage, since
they're
On Thursday, 13 Jan 2000, David Monniaux wrote:
#: app/undo.c:2874
msgid "FS to layer"
msgstr "FS vers calque"
#. ok
#: app/undo.c:2875
msgid "gimage"
msgstr "gimage"
#: app/undo.c:2876
msgid "FS rigor"
msgstr ""
#: app/undo.c:2877
msgid "FS relax"
msgstr ""
What do these
On Sunday, 9 Jan 2000, Marc Lehmann wrote:
On Sun, Jan 09, 2000 at 05:08:26PM +0100, "Guillermo S. Romero / Familia Romero"
[EMAIL PROTECTED] wrote:
that means quality loss (original where 256 colors only?), and I am looking
Yes, quality loss in many cases...
for the PPM, not
On Saturday, 13 Nov 1999, Olof S Kylander wrote:
The above statements leads to the conclusion that you often need to
zoom in out quickly.
What's wrong with the "+" and "-" keys? I used them exclusively to
control the zoom level, and find it quite convenient.
It would be even better if the
On Friday, 12 Nov 1999, Sven Neumann wrote:
Here is my list of minor things to clean up and make better (Without
breaking the freeze). First the list and then the discussion below it.
YES!!
I also like the new layout. It seems more consistent.
I'm not sure about leaving out all the
On Wednesday, 10 Nov 1999, Sven Neumann wrote:
- Grab GtkXmHtml seperately. This is difficult at the moment, but I was
told that the gEdit application offers a seperately bundled one.
If gEdit needs GtkXmHtml, and so does Gimp, does this not mean there's
a real requirement to make
On Wednesday, 10 Nov 1999, Tamito KAJIYAMA wrote:
I found a bug that gimp-drawable-get/set-pixel swapped the
specified x and y coordinates when getting/setting a pixel.
Ouch!
gimp-drawable-{get,set}-pixel is such a slow API not many people use
it, I reckon. That's probably why it's taken so
On Monday, 8 Nov 1999, Asbjoern Pettersen wrote:
The GIMP's modules for OS/2 need some extra handling.
It's copied into the 3-4 modules C files and it's also not
updated. I want to clean up this code.
The same problem was occurring on Solaris2. Yosh has now tweaked some
of the libtool
[Lots of people writing barking mad things about tile swapping]
Look, you're all missing the point.
Gimp does it's own tile swapping not because it wants to control the
layout on disk. As some of you have pointed out, this is futile.
The only reason to swap a tile at a time is to do with
58 matches
Mail list logo
