Re: [Gimp-developer] floating layers
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
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
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
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
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
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
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?
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