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 <gwidion@xxxxxxxxxx>: > 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 <t_w_@xxxxxxxxxx> 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 above the layer they apply to, if the layer has > > zonemasks at all' you could probably manage layer based zonemasks > > (of course they're better cause they can be in color.) > _______________________________________________ > Gimp-developer mailing list > Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx > https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer > _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
