Re: [Gimp-developer] Libre Graphics Meeting
Sven Neumann a écrit : > Hi, > > it's probably about time that we start to plan some details and to book > flights for this year's Libre Graphics Meeting. > > http://www.libregraphicsmeeting.org/ Dear GIMP team! I'd like to post a few info here for the benefits of all travellers to LGM. 1. I know the website of LGM is outdated. I expect things to be straightened up in the coming days. :) 2. Meanwhile, the Create wiki has been updated : http://create.freedesktop.org/wiki/index.php/Conference 3. Visa. Please review the VISA info as it might apply to some of you when travelling to Canada. 4. Rooms. We have dealt a LGM special price on rooms at the Student Residences of the uni hosting the LGM. All info is on the wiki. What has guided me is to allow LGM participants and especially the devel teams to be together most of the time (remember we only have 3 days), have internet access and enough room to organize meetings. All that into a calm environment. The residences are on the site of the LGM at less than 5 minutes from the main auditorium. Arrival date : May 3 (Conference starts on May 4). We may be able to arrange things if you want to arrive earlier. Please let me know. And we also want to avoid getting people lost in the city (Montreal is a North American city, quite extended...) and taking up most of their time getting from their hotel to the LGM site and back. I have made a reservation on 50 Single rooms + 5 Cosy Suites (with large bed) and there are lots more room there if needed. On each other floor of the residence people have access to a Salon that can hold a good 10 to 12 people meeting and we also have access to another 3 large rooms for meetings with more than 20 persons at a time. 5. Sponsorship. I am deeply concerned by sponsorship. We have to be able to help people get to the LGM. So far, I am still waiting on confirmation but sponsors have shown clear interest in helping us again this year. It's a matter of time until we know for sure the exact amount we going to get from the sponsors. Please stay tuned. I will post the info as soon as I have something to say. 6. LGM speakers. I would appreciate that people interested in making a talk at LGM show up on the Create wiki. Some people have contacted me early by e-mail. Please fill the wiki as well. This is the only sure way to help me put the schedule together. Also, if you know someone that would be a good speaker, don't hesitate to propose his/her name. And don't forget the subject suggestions as well. 7. LGM Brochure (see wiki for details) : we'd like to have each project described. Cédric Gemy should be able to take care of the GIMP's description and maybe more. At the same time, if anyone on this list has high res images created with GIMP that we could use to show what the program can do, please contact me off list. We don't need that many images but since we're distributed in the graphic designers magazine, the higher the level the better the effect, imo. 8. If anyone has a question or comment or suggestion, please don't hesitate to get back to me. Hope to see you again at LGM2 and of course meet new people! Louis > > As far as I know there is supposed to be sponsoring for participants > from conference sponsors. We are also in the lucky position that quite > some money has accumulated from donations. Only recently we have > received a single donation of $5,000. > > That should allow us to get all active contributors together in Montreal > this May. So who is planning to come? It looks like large parts of the > website have not been updated yet. It would probably be a good idea to > change that. We will need a list of participants and the Wiki > (http://wiki.gimp.org/gimp/TellUsYoureComing) might be a good place for > that. > > Any volunteer for coordinating the GIMP participation to the conference? > > Sven > > ___ > Gimp-developer mailing list > Gimp-developer@lists.XCF.Berkeley.EDU > https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer > -- Louis Desjardins Mardigrafe inc. T 514 934 1353 F 514 934 3698 http://www.mardigrafe.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Marketing for 2.4
On Fri, Jan 19, 2007 at 08:28:08AM +1030, David Gowers wrote: > "EXIF metadata is used by many cameras to describe the settings a picture > was taken with" -- perhaps a little long. just the 'are->is' replacement > would be good then Grammar Nazis will tell you never to end a sentence with a preposition; this is better treated as a guideline than an inviolable rule. If you're ending a sentence with one, than it would probably be better reworked: "Many cameras use EXIF metadata to describe the settings used to take the picture." This is just a suggestion, of course. -- Alex Pounds (Creature) .~. http://www.alexpounds.com/ /V\http://www.ethicsgirls.com/ // \\ "Variables won't; Constants aren't" /( )\ ^`~'^ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Marketing for 2.4
On 1/19/07, cedric GEMY <[EMAIL PROTECTED]> wrote: Some weeks ago, i've involved on Irc to do a kind of Gimp brochure to show new functionnalities, one in the style i already made for Scribus or Inkscape. You can get it at http://www.le-radar.com/temp/Brochure2-4b.pdf I reached the step where it needs some proofing : - my english is not perfect at all ;) - may be some things should be changed - may be some things should be added All the comments are welcome. Okay, here are my corrections: "EXIF ans XMP support" ans->and "EXIF metadata are used by many cameras to sum up its settings" -> "EXIF metadata is used by many cameras to describe the settings a picture was taken with" -- perhaps a little long. just the 'are->is' replacement would be good then 'makes it a realty' -> 'make it a reality' 'Gimp's plug-ins are no more organized due' more->longer 'in the same time' -> 'at the same time' The Heal tool preview is not a preview of the heal tool, just a copy of the perspective clone images. 'extract object from a background' -> 'extract an object from a picture' 'older Gimp's release' -> 'older Gimp releases' I enjoy the use of the word 'graphists'. It is not an English word though. English might say 'graphic artists'. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Marketing for 2.4
Some weeks ago, i've involved on Irc to do a kind of Gimp brochure to show new functionnalities, one in the style i already made for Scribus or Inkscape. You can get it at http://www.le-radar.com/temp/Brochure2-4b.pdf I reached the step where it needs some proofing : - my english is not perfect at all ;) - may be some things should be changed - may be some things should be added All the comments are welcome. + need to save space for a general gimp description. NB : Please read this with a good pdf reader because of transparency issues. Cedric ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] How to get if the buffer is empty or not
Hi, On Thu, 2007-01-18 at 13:31 +0100, Bart wrote: > i'm developing a script that insert the clipboard as a layer Huh? How is that different to what Edit->Paste does? > and to avoid error messages to the user i'd > like to check up wether the clipboard is empty or not. > How to do that? You can't easily do that. However the error messages are of course a bug and IIRC there's a bug report for this. Most probably even on the 2.4 milestone. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Drawing zones
Hi, On Thu, 2007-01-18 at 10:10 +0100, Thorsten Wilms wrote: > > http://bugzilla.gnome.org/show_bug.cgi?id=86274 > > > If I understand the whole thread, it's about another way > to select any layer, not only one that has highest z-order > and non-zero alpha at a specific location (pointer). No, it's explicitely about making it easier to select one of the layers below the mouse pointer. That could probably be extended to selecting the one with the highest z-order. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] How to get if the buffer is empty or not
On 1/18/07, Bart <[EMAIL PROTECTED]> wrote: Hi, i'm developing a script that insert the clipboard as a layer (its based on older existing scripts) and to avoid error messages to the user i'd like to check up wether the clipboard is empty or not. How to do that? Maybe Script-fu has a similar capability, anyway this is natural to express in Python: try: floating = pdb.gimp_edit_paste(image.active_layer, False) except RuntimeError: # code that executes if gimp_edit_paste causes a runtime error goes here. I would expect this to just be the following: return ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] How to get if the buffer is empty or not
Hi, i'm developing a script that insert the clipboard as a layer (its based on older existing scripts) and to avoid error messages to the user i'd like to check up wether the clipboard is empty or not. How to do that? If you interested this script could bundeled with next version of Gimp. I register it to "Image/Edit/Paste as" like "Paste as brush" or "Paste as Pattern". Thanx. Karamba! Bart. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Drawing zones
On 1/18/07, Thorsten Wilms <[EMAIL PROTECTED]> wrote: I usually work with a bunch of alpha-locked layers (paint shape in flat-colour, lock alpha, paint shadows, light, texture ...) I guess the perfect zone implementation would actualy need some overlap to have the same effect of alpha-locked layers. In fact, the best simple solution could be to copy selection masks onto > layer masks. Like, you have a 'painting' layer, and when you change zones: >1. Any changes are saved onto the underlying layer >2. The entire content of the underlying layer is copied to the paint > layer >3. The layer mask is copied from the next zone-mask (channel) > > This would play well with my 'apply paint' plugin, which applies any paint > on a layer (specially marked by name, beginning with the character '+') to > the underlying layer and then clears it to a neutral color. In short, drawing zones happening on the level of layer masks? Drawing zones happening by layer masks. This would allow you to decrease the total layer count needed while maintaining cleanness. Another model I thought about would require a graph, so I guess it's really a bit far out for GIMP: Having a layer/node for Ehe, have you poked around with the GEGL editor at all? As GIMP begins to use GEGL more and more, there are various almost 'free' features that would be a side effect of using GEGL: Graph based image model (most likely shown as a simplification of the underlying GEGL graph), hence Layer grouping also. Adjustment layers Those are the most relevant features. I've heard that the painting system would also be GEGL-based, so what you describe below may be possible (though it would probably be after 2.6 at the least.) compositing drawing layers/nodes. It would be like a free-form multi-split view on a number of layers. Drawing starting in one zone of the view and continuing the stroke outside of it could paint on the underlying layer/node, maintaining the advantage that using layers has now: you can draw below a layer and later change the shape of an upper layer without having to fill a gap. What you describe is not exactly a graph -- because the destination is variable. I can think of a design with a few additional nodes that would make it work though. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enabling plugins to get the user to click a point on the image.
On Thursday 18 January 2007 04:58, David Gowers wrote: > Manuel pointed out, The gimp currently lacks any way for a plugin > to get a coordinate from the image (eg. click on the 'seed' pixel). > I've often wanted to do this, and it is a bit awkward without it. > Has implementing this been avoided, or is it just an oversight? > > Some example usages: > * Color mixer: click on any number of pixels then press ENTER to > set FGcolor to a mix of all those colors. > * Zone selector: click on a zone to select it > * Word balloon creation (see a recent post on gimp-user) -- click > a series of 5 points to draw a word balloon (size, point shape and > location) Hi David: If you do not need it in real time, that is, if picking a point and only then caling a plug-in suits your needs, one can use paths. I have a couple of python-fu scripts myself that pick coordinates from the first, or first two nodes on the active path, and it is quite usefull. js -><- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Drawing zones
On Thu, Jan 18, 2007 at 08:04:28PM +1030, David Gowers wrote: > >I like the idea of using a layer and a palette to draw the zones. > >Even though I talked about hard edges, I (and everyone else drawing) > >need anti-aliased ones in almost all cases :} > > > Well, the simple case of that is easily done -- I just inserted two lines in > my zonemap tool that automatically antialias the zone mask using potrace. I > think that repeatedly drawing in a non-binary selection is a mistake, though > -- layer masks or 'preserve layer alpha' do it better. > > I rarely ever use antialiased selections for drawing, only exclusively for > fills (either color fills, alpha-clearing fills, or editing layer masks). > Drawing into AAed selections makes selecting objects a no-win (ie. cannot > get a perfect result, because the colors along the edges are uncontrolled) > situation, and dirties colors. I usually work with a bunch of alpha-locked layers (paint shape in flat-colour, lock alpha, paint shadows, light, texture ...) I guess the perfect zone implementation would actualy need some overlap to have the same effect of alpha-locked layers. > In fact, the best simple solution could be to copy selection masks onto > layer masks. Like, you have a 'painting' layer, and when you change zones: >1. Any changes are saved onto the underlying layer >2. The entire content of the underlying layer is copied to the paint > layer >3. The layer mask is copied from the next zone-mask (channel) > > This would play well with my 'apply paint' plugin, which applies any paint > on a layer (specially marked by name, beginning with the character '+') to > the underlying layer and then clears it to a neutral color. In short, drawing zones happening on the level of layer masks? Another model I thought about would require a graph, so I guess it's really a bit far out for GIMP: Having a layer/node for compositing drawing layers/nodes. It would be like a free-form multi-split view on a number of layers. Drawing starting in one zone of the view and continuing the stroke outside of it could paint on the underlying layer/node, maintaining the advantage that using layers has now: you can draw below a layer and later change the shape of an upper layer without having to fill a gap. -- Thorsten Wilms Thorwil's Creature Illustrations: http://www.printfection.com/thorwil ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] getting 2.4 out of the door
Von: Sven Neumann <[EMAIL PROTECTED]> > I get the impression that some people on this list are not really > interested in getting 2.4 out. Otherwise we wouldn't be discussing so > many things that are unrelated to the 2.4 release. Can we perhaps try to > concentrate everyone's efforts on the next release? I would really like > to iron out the remaining bits and get it out. There are a few patches attached to 2.4 bugs. Some of them have "needs-work" comments, some don't apply anymore, some have a "what's left to do?" comment. Would be nice if the authors could have a look at them. Michael -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Drawing zones
On 1/18/07, Thorsten Wilms <[EMAIL PROTECTED]> wrote: On Thu, Jan 18, 2007 at 02:57:30AM -0300, Manuel Quiñones wrote: > I've had a similar idea than yours, and implemented it right away. But > instead of changing zones with keystrokes, the zone can be selected > using the crosspoint of two perpendicular guides. I know this is ugly, > and maybe your idea about changing to next/previous zone is better. > Here it is: (...) > http://wiki.gimp.org/gimp/DrawingZones I like the idea of using a layer and a palette to draw the zones. Even though I talked about hard edges, I (and everyone else drawing) need anti-aliased ones in almost all cases :} Well, the simple case of that is easily done -- I just inserted two lines in my zonemap tool that automatically antialias the zone mask using potrace. I think that repeatedly drawing in a non-binary selection is a mistake, though -- layer masks or 'preserve layer alpha' do it better. I rarely ever use antialiased selections for drawing, only exclusively for fills (either color fills, alpha-clearing fills, or editing layer masks). Drawing into AAed selections makes selecting objects a no-win (ie. cannot get a perfect result, because the colors along the edges are uncontrolled) situation, and dirties colors. In fact, the best simple solution could be to copy selection masks onto layer masks. Like, you have a 'painting' layer, and when you change zones: 1. Any changes are saved onto the underlying layer 2. The entire content of the underlying layer is copied to the paint layer 3. The layer mask is copied from the next zone-mask (channel) This would play well with my 'apply paint' plugin, which applies any paint on a layer (specially marked by name, beginning with the character '+') to the underlying layer and then clears it to a neutral color. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Drawing zones
On Thu, Jan 18, 2007 at 07:56:47AM +0100, Sven Neumann wrote: > Hi, > > On Wed, 2007-01-17 at 18:03 +0100, Thorsten Wilms wrote: > > > Thinking some more about this, a "switch to highest in the stack > > layer with non-zero alpha at pointer location", option, triggered > > on button/pen-down before drawing is actually executed could > > do the trick while been least intrusive in GIMP. > > This is to some extent already handled in > http://bugzilla.gnome.org/show_bug.cgi?id=86274 If I understand the whole thread, it's about another way to select any layer, not only one that has highest z-order and non-zero alpha at a specific location (pointer). [Anyway, this made me think about showing layers as tabs on the image window or doing Apple Expose style thumbnailing or the variation of it in MS Vista.] -- Thorsten Wilms Thorwil's Creature Illustrations: http://www.printfection.com/thorwil ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Drawing zones
On Thu, Jan 18, 2007 at 02:57:30AM -0300, Manuel Quiñones wrote: > I've had a similar idea than yours, and implemented it right away. But > instead of changing zones with keystrokes, the zone can be selected > using the crosspoint of two perpendicular guides. I know this is ugly, > and maybe your idea about changing to next/previous zone is better. > Here it is: (...) > http://wiki.gimp.org/gimp/DrawingZones I like the idea of using a layer and a palette to draw the zones. Even though I talked about hard edges, I (and everyone else drawing) need anti-aliased ones in almost all cases :} The selection via 2 guides isn't practical, of course. I understand why you do it for now, lets hope there will be a solution. -- Thorsten Wilms Thorwil's Creature Illustrations: http://www.printfection.com/thorwil ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Drawing zones
On Wed, Jan 17, 2007 at 10:30:32PM -0200, Joao S. O. Bueno Calligaris wrote: > I have the followwing proposal: > what if one had a set of pre-loaded selections, and could switch back > and forth among then with a single keystroke - Do you (and others) > think it could be as usefull/more usefull/just the same as these > proposed drawing zones? Useful, yes. Just the same no. You need to explicitly switch and keep track of the order of selections to navigate efficiently. > Ok, you can imagine that what it brings of convenience for some it > brings of complication to certain user groups. Well, I think drawing zones could have a tab like layers and co, so the feature could stay completely hidden if someone wishes so. > The idea I propose, instead, would use already existing objects, like > this: one would store his drawing zones as a set of selections, each > in a separate image channel, and a simple script, with no imput > parameters, would replace the current selection with a selection in > the channel stack. > > Todo this manually, one would have to: > 1) select the channel tab in the layers/channels dock > 2) select the apropriate channel > 3) click on "channel to selection" > 4) change back to the layers tab on the dock > 5) select the actyual layer where one is drawing back > 6) start painting. > > Looking at this, it si a lot of work, and the drawing zones seems a > better idea. > However, a script fu can perform steps 1-5 with a single keystroke (if > one will select the next/same/previous channel on the stack that has > been previusly used). so it becomes: > 1) hit key that changes teh selection until the desired selection is > set > 2) start painting > > Which seems as practical as the drawing zones proposal. > > There is a final advantage in this proposal: it is ready for serving > _now_,a s writing such a script would take less than 30min. > > What do you say? It's just not the same, but cool nonetheless and I'm glad my proposal has led to thinking and experimentation and propably useful scripts :) -- Thorsten Wilms Thorwil's Creature Illustrations: http://www.printfection.com/thorwil ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Drawing zones
I've had a similar idea than yours, and implemented it right away. But instead of changing zones with keystrokes, the zone can be selected using the crosspoint of two perpendicular guides. I know this is ugly, and maybe your idea about changing to next/previous zone is better. Here it is: http://www.box.net/public/arhs7a3h9m I'm sorry but not direct link. I cannot register it to the gimp registry, because of http errors. And a fine tutorial: http://wiki.gimp.org/gimp/DrawingZones Regards, Manuel 2007/1/17, David Gowers <[EMAIL PROTECTED]>: > > > > On 1/18/07, Joao S. O. Bueno Calligaris <[EMAIL PROTECTED]> wrote: > > Ok - I've read the request and got the idea. > > > > I have the followwing proposal: > > what if one had a set of pre-loaded selections, and could switch back > > and forth among then with a single keystroke - Do you (and others) > > think it could be as usefull/more usefull/just the same as these > > proposed drawing zones? > > > > Why do I ask this? > > Because implementing what you are asking requires some fiddling in the > > core, and will complicate the interface with another kind of object, > > besides selections, channels, layers, masks, guides, sample points > > and the grid... > > > > Ok, you can imagine that what it brings of convenience for some it > > brings of complication to certain user groups. > > > > The idea I propose, instead, would use already existing objects, like > > this: one would store his drawing zones as a set of selections, each > > in a separate image channel, and a simple script, with no imput > > parameters, would replace the current selection with a selection in > > the channel stack. > > > > Todo this manually, one would have to: > > 1) select the channel tab in the layers/channels dock > > 2) select the apropriate channel > > 3) click on "channel to selection" > > 4) change back to the layers tab on the dock > > 5) select the actyual layer where one is drawing back > > 6) start painting. > > > > Looking at this, it si a lot of work, and the drawing zones seems a > > better idea. > > However, a script fu can perform steps 1-5 with a single keystroke (if > > one will select the next/same/previous channel on the stack that has > > been previusly used). so it becomes: > > 1) hit key that changes teh selection until the desired selection is > > set > > 2) start painting > > > > Which seems as practical as the drawing zones proposal. > > > > There is a final advantage in this proposal: it is ready for serving > > _now_,a s writing such a script would take less than 30min. > > > > What do you say? > > > > js > > -><- > > That sounds good. It allows some sort of status display (make the active > zone the only visible channel) and is flexible. > It misses one of the values of binary, mutually-exclusive selections, though > -- they can all be stored in > one channel, and if you decide a certain area should belong to a different > zone, you only have to fill that area on one channel. > > In Python, this is fairly simple to implement: > * Name the channel like "10-Zonemap; Current: AA" >(layertattoo-Zonemap; current: XX) > > * The cycle op extracts the 'current' specifier (ranging 00-ff -- ie a > pixel intensity in hex) and chooses the next unique value found in the > channel. It loads the zonemap into the selection and thresholds it > accordingly. > Then it updates the channel name: "10-Zonemap; Current: CC" > > I want this, so I'll implement it today. > > ___ > Gimp-developer mailing list > Gimp-developer@lists.XCF.Berkeley.EDU > https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer > > > ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Drawing zones
I've had a similar idea than yours, and implemented it right away. But instead of changing zones with keystrokes, the zone can be selected using the crosspoint of two perpendicular guides. I know this is ugly, and maybe your idea about changing to next/previous zone is better. Here it is: http://www.box.net/public/arhs7a3h9m I'm sorry but not direct link. I cannot register it to the gimp registry, because of http errors. And a fine tutorial: http://wiki.gimp.org/gimp/DrawingZones Regards, Manuel 2007/1/17, Joao S. O. Bueno Calligaris <[EMAIL PROTECTED]>: > Ok - I've read the request and got the idea. > > I have the followwing proposal: > what if one had a set of pre-loaded selections, and could switch back > and forth among then with a single keystroke - Do you (and others) > think it could be as usefull/more usefull/just the same as these > proposed drawing zones? > > Why do I ask this? > Because implementing what you are asking requires some fiddling in the > core, and will complicate the interface with another kind of object, > besides selections, channels, layers, masks, guides, sample points > and the grid... > > Ok, you can imagine that what it brings of convenience for some it > brings of complication to certain user groups. > > The idea I propose, instead, would use already existing objects, like > this: one would store his drawing zones as a set of selections, each > in a separate image channel, and a simple script, with no imput > parameters, would replace the current selection with a selection in > the channel stack. > > Todo this manually, one would have to: > 1) select the channel tab in the layers/channels dock > 2) select the apropriate channel > 3) click on "channel to selection" > 4) change back to the layers tab on the dock > 5) select the actyual layer where one is drawing back > 6) start painting. > > Looking at this, it si a lot of work, and the drawing zones seems a > better idea. > However, a script fu can perform steps 1-5 with a single keystroke (if > one will select the next/same/previous channel on the stack that has > been previusly used). so it becomes: > 1) hit key that changes teh selection until the desired selection is > set > 2) start painting > > Which seems as practical as the drawing zones proposal. > > There is a final advantage in this proposal: it is ready for serving > _now_,a s writing such a script would take less than 30min. > > What do you say? > > js > -><- > > > On Tuesday 16 January 2007 20:54, David Gowers wrote: > > On 1/17/07, Thorsten Wilms <[EMAIL PROTECTED]> wrote: > > > Hi! > > > > > > So I was asked to suggest new features on the mailing-list and > > > only file bug report after they have been discussed there ... and > > > it seems theres a misunderstanding to be resolved and i wouldn't > > > mind more exposure for this ... :) > > > > > > > > > My proposal is about an alternative to using either layers > > > or saved selections to draw on areas of an image with sharp > > > edges between them. > > > > > > http://bugzilla.gnome.org/attachment.cgi?id=80388 > > > > > > Shows a typical case, ignoring the background we have > > > two such areas: body and hand. > > > > > > Drawing zones are about dividing the image into 2 or more > > > (non-overlapping) regions. These zones would be a bit like > > > multiple selections. If you start drawing in one zone, you can't > > > draw over another zone without releasing the mouse-button / > > > lifting the pen (same effect as drawing outside of the current > > > selection). > > > > > > Such a feature would remove the need for using layers and moving > > > between them > > > or constantly changing selections in cases where adjacent areas > > > need sharp edges between them. > > > > > > Using layers would mean constant switching between them. Same for > > > selections. Long mouse-ways in both cases. Zones, once setup > > > could be left active for long durations. > > > > > > This has nothing to do with split-views, Sven, as the image is > > > shown the same way, not in parts. You would just need marching > > > ants or similar for the zone extents and the ability to hide > > > them. > > > > > > If it's still unclear, I'll provide graphical explanation. > > > > > > > > > http://bugzilla.gnome.org/show_bug.cgi?id=397237 > > > > This would be wonderfully useful to me for CGing. You would need to > > be able to define zones per-layer - It would only greatly reduce > > the need for layers, not obviate them completely, for example when > > I'm making an alternate coloration or remake of something, I like > > to paste it over the original as a new layer, and use the enter key > > to toggle it's visibility. > > > > I think you would have to use saved selections rather than layers, > > to avoid the strange 'sibling-effects-sibling' behaviour (ie one > > layer is real, other is zonemasks, but they're both in the same > > list). If you specified a rule such as 'zonemasks are always the > > layer immediately abo
