On Thu, 30 Apr 2009 11:01:08 +0930
David Gowers 00a...@gmail.com wrote:
X could work almost unchanged (just, pressing X multiple times in
quick succession would move back through the 5-slot color history,
rather than just swapping the two newest slots. So your current usage
of X would be
I guess some third-party plug-ins rely on fg/bg values. For instance, FX
Foundry - Convert color temperature. That's for compatibility. And
there should be a way to a provide an interaction between script-fu and
user selectable colors.
With respect,
Alexander Rabtchevich
Hi Jon!
On Thu, Apr 30, 2009 at 4:35 PM, Jon Senior j...@restlesslemon.co.uk wrote:
On Thu, 30 Apr 2009 11:01:08 +0930
David Gowers 00a...@gmail.com wrote:
X could work almost unchanged (just, pressing X multiple times in
quick succession would move back through the 5-slot color history,
I just ran through my scripts.
In the .scm files distributed with gimp, there were:
38 files containing gimp-context-set-foreground
65 files containing gimp-context-set-background
looking at the scripts I have installed in my home directory, there were:
49 files containing
On Thu, Apr 30, 2009 at 9:13 PM, yahvuu yah...@gmail.com wrote:
Hi David,
here's a mockup idea on your proposal; might or might not help
to identify the current-previous color pair... just brainstorming.
I hope you're not bothered i'm sending private mail - it's just
i can't contribute
On Thu, Apr 30, 2009 at 10:36 PM, Rob Antonishen
rob.antonis...@gmail.com wrote:
I just ran through my scripts.
In the .scm files distributed with gimp, there were:
38 files containing gimp-context-set-foreground
65 files containing gimp-context-set-background
The ones I have looked at,
another round of review:
OK, first the 5-slot color history:
So far, no one has given any feedback on the idea, or indeed any
acknowledgement of it. This disappoints me
Sorry, I had to think about it more before stepping in to this,
doing that yesterday would have been too fast.
I see we
Hi all,
David Gowers schrieb:
When Martin said that, I thought that just means it's inappropriate
for us to make the decisions. It doesn't mean we shouldn't do research
-- in fact, I'm sure Peter Sikking would appreciate it.
Hence, I've CCed this to the list.
yep. Me too regards this as
guys,
here is sort of a review of what has been discussed here:
To take this top-down: I can only see this change as an UI
improvement if it means getting rid of the bg color swatch.
Only then we can reach the goal of less user thinking,
instead of more.
but some crucial things depend on the bg
On Wed, Apr 29, 2009 at 5:37 PM, peter sikking wrote:
guys,
here is sort of a review of what has been discussed here:
To take this top-down: I can only see this change as an UI
improvement if it means getting rid of the bg color swatch.
How is one supposed to paint on mask without bg/fg
Hi all,
peter sikking schrieb:
- png bKGD. looks to me it should be honoured on import
(as file creating import, that is), no extra dialogs please.
I tend to say it should not be used (by default) on export.
a set bg-color-layer should be merged into the pixels. but
then there is
Alexandre Prokoudine wrote:
On Wed, Apr 29, 2009 at 5:37 PM, peter sikking wrote:
guys,
here is sort of a review of what has been discussed here:
To take this top-down: I can only see this change as an UI
improvement if it means getting rid of the bg color swatch.
How is one supposed
Hello,
On Wed, Apr 29, 2009 at 11:17 PM, Alexandre Prokoudine
alexandre.prokoud...@gmail.com wrote:
On Wed, Apr 29, 2009 at 5:37 PM, peter sikking wrote:
guys,
here is sort of a review of what has been discussed here:
To take this top-down: I can only see this change as an UI
improvement if
Hi all,
peter sikking schrieb:
and I do not really follow what you wrote in there.
I do have the feeling we draw different conclusions.
indeed, obviously we draw different conclusions from the very same specs.
Here's my take on why png bKGD is complementary to any (future) element of XCF:
2009/4/29 peter sikking pe...@mmiworks.net
guys,
here is sort of a review of what has been discussed here:
To take this top-down: I can only see this change as an UI
improvement if it means getting rid of the bg color swatch.
Only then we can reach the goal of less user thinking,
instead
Hi all,
peter sikking schrieb:
but some crucial things depend on the bg color.
the gradient tool being the big show-stopper for me.
the tool needs a redesign, but up to then the fg-bg
type of interaction looks to be the most (universally)
usable to me.
i think the gradient tool would work
On Thu, Apr 30, 2009 at 12:49 AM, Filipe Soares Dilly fil...@gmail.com wrote:
2009/4/29 peter sikking pe...@mmiworks.net
but some crucial things depend on the bg color.
the gradient tool being the big show-stopper for me.
the tool needs a redesign, but up to then the fg-bg
type of
David Gowers wrote:
On Thu, Apr 30, 2009 at 12:49 AM, Filipe Soares Dilly fil...@gmail.com
wrote:
Unless you make a ease and nice way of swathing (or alternating) colors, I'm
against it.
When you are painting (making a digital painting or painting on a mask...)
in the current version
Hi saulgoode,
On Tue, Apr 28, 2009 at 7:00 PM,
saulgo...@flashingtwelve.brickfilms.com wrote:
Quoting David Gowers 00a...@gmail.com:
The eraser currently does change color values, in the case of layers
without alpha (it's like using paintbrush or pencil with the
background color). Yahvuu's
Hi,
Sparr schrieb:
I just want to point out that PNG supports a background color (and the
GIMP plugin to save PNG offers an option to save the current brush
background color as the image background color), and being the only
format to do so we should probably consider its specified functions
Quoting David Gowers 00a...@gmail.com:
The eraser currently does change color values, in the case of layers
without alpha (it's like using paintbrush or pencil with the
background color). Yahvuu's proposition would make sure it never
changed color values because there would be no layers
Hi,
David Gowers schrieb:
Hi saulgoode,
On Tue, Apr 28, 2009 at 12:29 PM,
saulgo...@flashingtwelve.brickfilms.com wrote:
If a PNG is loaded as a layer, should the image background color be
updated to the PNG file's background color? or should it remain what
it was originally? If a JPEG is
Hi,
David Gowers schrieb:
Yahvuu's proposition is essentially
a) have a 'virtual layer' always at the bottom of the stack, filled with a
color
and
b) make all layers have an alpha channel
Nothing more.
Yep.
Just in case this rooted a misunderstanding, i'd like to add that
the eraser is
Hi,
David Gowers schrieb:
On Mon, Apr 27, 2009 at 2:20 AM, yahvuu yah...@gmail.com wrote:
Hi all,
David Gowers schrieb:
One bump I see is things like Cut and Float -- quite often I want
them to fill the source area with a solid color rather than with
transparency. When this doesn't happen,
yahvuu wrote:
And i'm not aware of a raster file format which features that concept.
PNG. http://www.w3.org/TR/PNG/#11bKGD
HTH,
Michael
--
GIMP http://www.gimp.org | IRC: irc://irc.gimp.org/gimp
Wiki http://wiki.gimp.org | .de: http://gimpforum.de
Plug-ins
On Sun, Apr 26, 2009 at 8:01 AM, yahvuu yah...@gmail.com wrote:
peter sikking schrieb:
I like the innovative nature of the idea.
And i'm not aware of a raster file format which features that concept.
I just want to point out that PNG supports a background color (and the
GIMP plugin to save PNG
Perhaps I am misunderstanding this proposal, but the ramifications
seem to be more confusing than the present method. And while I realize
that GIMP does not make any guarantees about retaining the colors of
transparent pixels, its current behavior is quite useful for editing
files destined
Hi saulgoode,
On Tue, Apr 28, 2009 at 12:29 PM,
saulgo...@flashingtwelve.brickfilms.com wrote:
Perhaps I am misunderstanding this proposal, but the ramifications
seem to be more confusing than the present method. And while I realize
that GIMP does not make any guarantees about retaining the
Hi all,
peter sikking schrieb:
I like the innovative nature of the idea.
it would not be without a hint of irony if, after 40+ years of digital image
processing,
GIMP were the first to finally introduce the concept of a background color ;-)
And i'm not aware of a raster file format which
Hello yahvuu,
On Sun, Apr 26, 2009 at 9:31 PM, yahvuu yah...@gmail.com wrote:
Hi all,
peter sikking schrieb:
I like the innovative nature of the idea.
it would not be without a hint of irony if, after 40+ years of digital image
processing,
GIMP were the first to finally introduce the
Hi,
David Gowers schrieb:
What happens when we want to save a 24bit png with no alpha from a
single layered image? how is this detected?
The current distinction between layers with and without alpha channel
allows the user to make that clear..
A set of good rationales is IMO:
GIMP is an XCF
Hi all,
David Gowers schrieb:
One bump I see is things like Cut and Float -- quite often I want
them to fill the source area with a solid color rather than with
transparency. When this doesn't happen, it's awkward (as the layer)
in terms of the model under discussion, this is a shortcut for
On Mon, Apr 27, 2009 at 2:20 AM, yahvuu yah...@gmail.com wrote:
Hi all,
David Gowers schrieb:
One bump I see is things like Cut and Float -- quite often I want
them to fill the source area with a solid color rather than with
transparency. When this doesn't happen, it's awkward (as the layer)
Peter (yahvuu) wrote:
there's one solution i haven't seen yet:
assign a background color to GIMP images. Not a layer, just a single
color.
This way, the eraser can always work on alpha, and all layers
consistently can have an alpha channel.
I like the innovative nature of the idea.
Hi all,
reading through some discussion which steps on default alpha for layers? and
erase to alpha or to white? questions, there's one solution i haven't seen
yet:
assign a background color to GIMP images. Not a layer, just a single color.
This way, the eraser can always work on alpha, and all
35 matches
Mail list logo
