Hi,
Patrick McFarland [EMAIL PROTECTED] writes:
Actually, you probably should really convert. Convert to Pixels
would infact destroy the text object, and make it a real
image. And of course, while destroying the text object, you can no
longer edit the text.
The text layer is always a real
Hi,
Joao S. O. Bueno [EMAIL PROTECTED] writes:
For example, this is the line in current gimp code that does the
merge mode :
sum = src1[b] + src2[b] - 128;
It will be doable by typing:
ED = E1 + E2 -0.5;
as the custom layer mode. (E stands for every channel. A is already
used for
Am Die, 2003-07-29 um 10.33 schrieb Sven Neumann:
The shape displayed is what's used to sample, that's not a question.
Make it configurable doesn't seem like a good idea here. I guess most
people will agree that a circle is the natural choice.
I don't. The colorpicker ist quite handy to
Hi,
Daniel Egger [EMAIL PROTECTED] writes:
I don't. The colorpicker ist quite handy to determine the average color
in some area and a square is much more natural to handle.
How is a square more natural to handle than a circle? All other apps
I've seen so far use a circle.
Also for a circle
Hi,
Daniel Egger [EMAIL PROTECTED] writes:
I guess I don't really understand your question. Do you want to know
whether it makes sense to display the shape actually used for sampling
or whether to use a circle instead of a square?
I'd say: Make the shape configurable and always display the
On 29-Jul-2003, Sven Neumann wrote:
I don't want to discourage you and it's certainly a nice expert/geek
feature but I doubt that the casual GIMP user wants to type in any
formulas.
No, but I doubt the casual GIMP user cares about a feature they arnt smart
enough to use yet. AFAIK this isnt a
On Tuesday 29 July 2003 1:25 am, Patrick McFarland wrote:
On 28-Jul-2003, Joao S. O. Bueno wrote:
It will be doable by typing:
ED = E1 + E2 -0.5;
as the custom layer mode. (E stands for every channel. A is
already used for alpha - I myself dislike the every, and will
accept other
From: Sven Neumann [EMAIL PROTECTED]
To: Joao S. O. Bueno [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Subject: Re: [Gimp-developer] Grain modes are just the beginning - was
McFarland's Re: Startup Notification support...
Date: Tue, 29 Jul 2003 10:38:02 +0200
Hi,
Joao S. O. Bueno [EMAIL PROTECTED]
From: Daniel Egger [EMAIL PROTECTED]
To: Sven Neumann [EMAIL PROTECTED]
CC: Gimp Developer [EMAIL PROTECTED]
Subject: Re: [Gimp-developer] Wrong terminology in color picker tool
Date: 29 Jul 2003 13:39:02 +0200
MIME-Version: 1.0
Am Die, 2003-07-29 um 10.33 schrieb Sven Neumann:
The shape
On Tuesday 29 July 2003 5:38 am, you wrote:
Hi,
Joao S. O. Bueno [EMAIL PROTECTED] writes:
For example, this is the line in current gimp code that does the
merge mode :
sum = src1[b] + src2[b] - 128;
It will be doable by typing:
ED = E1 + E2 -0.5;
I don't want to discourage
On Tue, 29 Jul 2003, Phil Harper wrote:
The shape displayed is what's used to sample, that's not a question.
Make it configurable doesn't seem like a good idea here. I guess most
people will agree that a circle is the natural choice.
I don't. The colorpicker ist quite handy to
Henrik Brix Andersen writes:
Removing the fallback definitions broke compilation on at least one
platform, namely GNU/Linux which doesn't define _O_BINARY and/or
_O_TEMPORARY. Most likely other unix-like platforms where affected as
well.
Since Unix systems don't distinguish between binary
Hi,
Daniel Egger [EMAIL PROTECTED] writes:
It's easier to handle for arbitrary shaped regions IMHO. Coolest would
be of course to provide a possibility to select a brush for the sample
area; the grey value would determine the importance of the pixel on a
given position. Selecting a black
At 23:22 27.07.03 +, Tor Lillqvist wrote:
[...]
One irritating thing with GIMP on Windows currently is GTK bug
#112402, I really need to fix that soon. GIMP's toolbox and some other
windows are currently positioned with their title bar exactly off
screen.
This is a regression of previous
Hi all,
Ummm - this is going to be a short mail. There wasn't any.
Feedback, that is.
There were a few comments in bugzilla (which is always welcome),
but of the 1.3 milestone bugs, 3 have been resolved in the past 4
days. One of these was a duplicate bug, another was a simple
patch
Hans Breuer writes:
This is a regression of previous versions. IIRC it was caused
by the usage of gdk_eindow_new() with parameters 'in range' and
additional adjusted by SafeAdjustWindowRect and the code
later calling gdk_window_move with coordinates directly derived
from the current
16 matches
Mail list logo
