Re: [Gimp-developer] floating layers

2005-02-16 Thread Carol Spears
On Wed, Feb 16, 2005 at 08:28:38AM +0100, David Neary wrote:
 Carol Spears wrote:
  if i try to New Layer a floating layer that has been pasted onto a
  mask, gimp refuses with an error message.
 
 This is not new behaviour. 
 
fairly new.  there is no way that i did not make that mistake ever with
gimp-1.2.

  for my limited understanding of the reason for floating layers to still
  exist, this behavior tells me that the need for them has gone.
 
 This is the only behaviour which justifies floating selections,
 actually.
 
   if gimp
  can tell the difference between a drawable or an image
 
 Actually, it's the difference between a GimpLayer and a
 GimpLayerMask (which are both drawables).
 
yes, and gimp can see the difference.  the last time i asked, they
explained the logic in that the difference couldnt be seen by gimp.


  can floating layers go away now?  the arguments for them have ceased to
  have meaning.
 
 What UI do you suggest?
 
 1) If we are pasting a selection which was made from a layer then
 create a new layer
 2) If we are pasting a selection which was made from a mask or a
 channel, create a floating selection, but don't display it in the
 layers dialog, and only allow anchor selection
 
 Does that sound like what you would like to happen?
 
nope, more like if you are pasting onto a layer then a new layer is
created (Edit --Paste).  and if you are pasting onto a layer mask then
it lands itself on the mask area.  both cases, floating layers are not
needed.  

for those who will miss floating layers, you could add 
Edit --Paste Float as a menu option.

carol

___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] floating layers

2005-02-16 Thread Sven Neumann
Hi,

Carol Spears [EMAIL PROTECTED] writes:

 if i try to New Layer a floating layer that has been pasted onto a
 mask, gimp refuses with an error message.

Sure, it has always worked like that.

 for my limited understanding of the reason for floating layers to still
 exist, this behavior tells me that the need for them has gone.  if gimp
 can tell the difference between a drawable or an image -- and it
 obviously does, there is no need for this floating step.  also, since
 you cannot see the layer while it is floating, there is no positioning
 that can be done.

 can floating layers go away now?  the arguments for them have ceased to
 have meaning.

There is no such thing as a floating layer, it's called a floating
selection.  Your argumentation is flawed. Of course if I paste
something into a layer mask, I want to be able to position it. That's
the whole point of a floating selection. This has, IMO, been discussed
enough in Bugzilla. There is certainly room for improvement here and I
am all for reducing floating selections as well as for making them
easier to deal with. But we can certainly not get rid of them
completely. That would be a major regression.


Sven
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] floating layers

2005-02-16 Thread Sven Neumann
Hi,

Carol Spears [EMAIL PROTECTED] writes:

 This is not new behaviour.
 
 fairly new.  there is no way that i did not make that mistake ever with
 gimp-1.2.

This is from the gimp-1-2 source code (app/floating_sel.c):

  /*  Check if the floating layer belongs to a channel...  */
  if (GIMP_IS_CHANNEL (layer-fs.drawable))
{
  g_message (_(Cannot create a new layer from the floating\n
 selection because it belongs to a\n
 layer mask or channel.));
  return;
}


Sven
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] floating layers

2005-02-16 Thread Carol Spears
On Wed, Feb 16, 2005 at 11:10:55AM +0100, Sven Neumann wrote:
 Hi,
 
 Carol Spears [EMAIL PROTECTED] writes:
 
  if i try to New Layer a floating layer that has been pasted onto a
  mask, gimp refuses with an error message.
 
 Sure, it has always worked like that.
 
  for my limited understanding of the reason for floating layers to still
  exist, this behavior tells me that the need for them has gone.  if gimp
  can tell the difference between a drawable or an image -- and it
  obviously does, there is no need for this floating step.  also, since
  you cannot see the layer while it is floating, there is no positioning
  that can be done.
 
  can floating layers go away now?  the arguments for them have ceased to
  have meaning.
 
 There is no such thing as a floating layer, it's called a floating
 selection.  Your argumentation is flawed. Of course if I paste
 something into a layer mask, I want to be able to position it. That's
 the whole point of a floating selection. This has, IMO, been discussed
 enough in Bugzilla. There is certainly room for improvement here and I
 am all for reducing floating selections as well as for making them
 easier to deal with. But we can certainly not get rid of them
 completely. That would be a major regression.
 
 
what is the bug report.

carol
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Re: floating layers

2005-02-16 Thread David Neary
Hi,

GSR - FR wrote:
 [EMAIL PROTECTED] (2005-02-16 at 0828.38 +0100):
   can floating layers go away now?  the arguments for them have ceased to
   have meaning.
  What UI do you suggest?
  1) If we are pasting a selection which was made from a layer then
  create a new layer
 
 How do I paste (adjusting if necesary) layer-A data into layer-B's
 mask then?

Refinement - if we're pasting into a mask or channel. Pasting
from a channel to a layer could Just Work. It might be decided it
shouldn't which is, of course, valid, but it could.

Cheers,
Dave.

-- 
David Neary,
Lyon, France
   E-Mail: [EMAIL PROTECTED]
CV: http://dneary.free.fr/CV/
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] GIMP and multiple processors

2005-02-16 Thread Sven Neumann
Hi,

I couldn't resist and changed the PixelProcessor to use a thread pool.
Main motivation was to make progress callback work for the threaded
case. So there's now a variant of pixel_regions_process_parallel()
that takes progress function and data. This allows us to parallelize
some of the slower core functions (like for example gradient blend).

It would be interesting to know if this actually gives a noticeable
speedup on SMP systems. Would be nice if one of you could give this
some testing. Please try to do gradient blends (w/o adaptive
supersampling!) on large images. Changing the number of processors in
the preferences dialog allows you to switch between using the thread
pool and the single-threaded code.


Sven
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6

2005-02-16 Thread David Gowers
An 'adjust related keybindings' menu item for relevant docks would help a lot 
to ease keyboard-configuration. This would open the prefs-configure keyboard 
shortcuts dialog, scrolled to the relevant area.

the difficulty of dynamic-keyboard-shortcutting, you can avoid by creating a 
shortcut scheme in advance.
In mine,
I have P mapped to pencil, shift+P to paintbrush, ctrl+P to clone, 
ctrl+shift+P to airbrush, ctrl+alt+P to ink, alt+shift+p to dodge/burn. I 
followed this scheme through all the keybindings. commonest used - quickest 
to access, least used == slowest to access. (another example: C == Copy. 
SHIFT+C == Cut, CTRL+C == Copy Visible, CTRL+ALT+C == Copy Named, 
CTRL+ALT+SHIFT+C == Cut Named. and all the clear/fill with.. actions are 
mapped to F plus modifiers. Undo/redo is mapped to ; because i have a dvorak 
keyboard.) . 


___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] Palette next/prev color actions?

2005-02-16 Thread David Gowers
I implemented hackishly something like this before. With recent changes 
related to gtk_accel_get_closure(), I want to know if I can now do this 
cleanly.
What i want to do is add two invisible-in-the-menus actions to the 
PaletteEditor menupath, that i can shortcut (I've reserved [ and ] for the 
purpose).

I want to do this soon, as i really tire of not having it, it is so 
ubiquitously useful for any painting. Is what i described currently possible?
Can i do it in some better way?

David Gowers


___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer