Re: [Gimp-developer] improving QMask mode

2007-12-01 Thread Sven Neumann
Hi,

On Sat, 2007-12-01 at 18:05 +1030, David Gowers wrote:

   b) Push the context before entering qmask mode, and pop it when
   exiting qmask mode.
 For Chris's benefit : it means that the context that was being used is
 stored, and restored after qmask. so the FG and BG that you were
 previously using return.

It would mean a lot more than that. Also any changes to the current
brush, pattern, gradient, paint-mode, ... would be undone when the
context is popped.

We currently use this to allow scripts to work in their own context. I
am not sure if it is a good idea to use the context push/pop mechanism
in the user interface.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] improving QMask mode

2007-12-01 Thread David Gowers
Hi Sven,

On Dec 1, 2007 9:37 PM, Sven Neumann [EMAIL PROTECTED] wrote:
 Hi,

 On Sat, 2007-12-01 at 18:05 +1030, David Gowers wrote:

b) Push the context before entering qmask mode, and pop it when
exiting qmask mode.
  For Chris's benefit : it means that the context that was being used is
  stored, and restored after qmask. so the FG and BG that you were
  previously using return.

 It would mean a lot more than that. Also any changes to the current
 brush, pattern, gradient, paint-mode, ... would be undone when the
 context is popped.

I thought that you could mask it so that only FG and BG were effected.

 We currently use this to allow scripts to work in their own context. I
 am not sure if it is a good idea to use the context push/pop mechanism
 in the user interface.


 Sven



___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] improving QMask mode

2007-11-30 Thread Chris Mohler
On Nov 30, 2007 6:15 AM, David Gowers [EMAIL PROTECTED] wrote:
 I believe that QMask mode could be made quicker to use, by providing
 an option to:
 a) Reset the FG/BG colors to black and white upon entering qmask mode
 and
 b) Push the context before entering qmask mode, and pop it when
 exiting qmask mode.

 With the sum effect that you needn't destroy the colors that you were
 using in order to paint on the QMask (I myself always find myself
 resetting the colors to default before I draw on the QMask), and you
 start out with the two most useful 'colors' set as FG+BG.

 What do you think of this? If I get the go ahead I'll implement this.

I like a - I switch to black and white in QMask very often.  Not
sure exactly what you mean by b, so no opinion...

Chris
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] improving QMask mode

2007-11-30 Thread David Gowers
Hi Liam,
On Dec 1, 2007 6:15 AM, Liam R E Quin [EMAIL PROTECTED] wrote:
 On Fri, 2007-11-30 at 22:45 +1030, David Gowers wrote:
  I believe that QMask mode could be made quicker to use, by providing
  an option to:
  a) Reset the FG/BG colors to black and white upon entering qmask mode
  and
  b) Push the context before entering qmask mode, and pop it when
  exiting qmask mode.
For Chris's benefit : it means that the context that was being used is
stored, and restored after qmask. so the FG and BG that you were
previously using return.


 Interesting idea.  I admit I hardly ever use quickmask because most
 of the images I work with are grayscale, and if you paint with a soft
 brush in the gray quickmask you can't tell where you selection starts.
That depends on what mask color you set. Set black or white instead of
the default red, does that help?

 So I have to switch to RGB mode first right now.

 This makes me wonder if there should be separate sets of colours
 stored for different painting modes, rather than a push/pop model.

For QMask (which is an editing mode), certainly. For 'paint modes' (eg
multiply, screen, dissolve), it would be fast; I suspect it would also
be confusing for novices. I would definitely like it as an option,
because I almost never want the same colors for drawing in Multiply
mode or Grain Merge mode as I do for drawing in Normal mode.

Let's review the paint modes:
1. Normal, Dissolve, Behind,  Color erase.
2. Overlay, Soft light, Hard Light, Grain Merge, Grain Extract
3. Multiply, Divide, Screen
4. Difference, Addition, Subtract,  Dodge, Burn
5. Darken, Lighten, Hue, Saturation, Color, Value

Each number represents a group of paint modes, in which a given color
has more or less the same meaning.
1. Direct color change.
2. Linear color change
3. Cumulative color change
4. Linear one-way color change
5. Direct partial color change (effects only some components)

Surely some people disagree with me here. I expect that, as GEGL
approaches, this sort of control will become more important. Now, I'm
talking about sharing color settings between each group of paint
modes; Later, it will become sharing (X) settings between different
Ops (since gegl will greatly diversify the available ways to paint, a
static mode list becomes infeasible). Therefore I believe that a
facility that allows the user to group modes which will share contexts
is the way to go for future compatible handling of this issue.


 If I change the colour in quickmask mode, e.g. to 50% gray, next time
 I use quickmask it could go back to that.

This is a good idea! Does anyone know how to do it non-hackishly? Is
new support code needed?

 Liam

 --
 Liam Quin - http://www.holoweb.net/~liam/
 XML Activity Lead, W3C, http://www.w3.org/People/Quin/
 Pictures from old books: http://fromoldbooks.org/
 Ankh: irc.sorcery.net irc.gnome.org www.advogato.org


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer