After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 55018 - Gradient along a path
Gradient along a path
Status: RESOLVED OBSOLETE
Product: GIMP
Classification: Other
Component: Tools
git master
Other All
: Normal enhancement
: Future
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2001-05-21 16:34 UTC by Jon Hoskins
Modified: 2018-05-24 10:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
python plug-in that implements feature (2.84 KB, application/x-python)
2007-08-15 06:04 UTC, Joao S. O. Bueno
  Details
Update to script implementing feature (2.97 KB, patch)
2008-01-27 20:04 UTC, Joao S. O. Bueno
needs-work Details | Review

Description Jon Hoskins 2001-05-21 16:34:28 UTC
Desired plugin/scriptfu would basically create half of a "shapeburst" or 
apply a gradient along a path so that the gradient shifts colors 
perpendicular to the direction of the path itself.

A rainbow is a good analogy.  

Desired wish item would either apply the gradient along a path or fill a 
selection like shapeburst does currently without shifting back to the 
initial color.  i.e; shapeburst = FG->BG->FG
new tool = FG->BG
Comment 1 Alan Horkan 2003-07-23 18:39:55 UTC
Changes at the request of Dave Neary on the developer mailing list.  
I am changing many of the bugzilla reports that have not specified a target
milestone to Future milestone.  Hope that is acceptable.  
Comment 2 Artis Rozentāls 2004-03-25 09:34:54 UTC
Wouldn't it be better to have the option to apply a gradient perpendiculary as a
Pencil/Brush/Airbrush option? Than "Stoke Path" could be used to achieve the effect.
Comment 3 Joao S. O. Bueno 2004-11-15 01:59:31 UTC
In order for this to work as #2 suggests, BUG #119240 would have to be fully 
implemented first, with the additional ability for the gradient brush, and 
even them, it would take a handfull of control adjusting for the effect 
desired here to be achieved.  
This better be implemented as a "stand alone" feature of the stroking options, 
when it is handled. 
 
 
Comment 4 weskaggs 2006-06-16 16:00:58 UTC
Upgrading target from Future to 2.6.
Comment 5 Joao S. O. Bueno 2007-08-15 06:04:44 UTC
Created attachment 93703 [details]
python plug-in that implements feature

python plug-in which implements requested feature. (requires gimp 2.3/2.4 API)
Comment 6 Michael Schumacher 2007-09-19 21:15:49 UTC
Does this handle case 3) of bug #143203?
Comment 7 Joao S. O. Bueno 2008-01-27 20:04:05 UTC
Created attachment 103834 [details] [review]
Update to script implementing feature

I'd like some feedback on whether this is script is suitable for inclusion (therefore, closing this bug). If so, I will reformat it accordingly to the other python=fu plug-ins and submit it as a patch.

Answering to Schumanl: I think not. This script combines several other gimp functions in a hackis^w clever way to achieve the desired effect. Bug #143203 would require different algorythms on the blend tool itself.
Comment 8 Martin Nordholts 2008-05-28 05:10:37 UTC
Thanks for the patch Joao

IMO the plug-in approach works (even though it would be nice with more integrated UI, but no idea how it would look).

There seem to be some issues left:

 * The plugin doesn't seem to do gradient start -> gradient end, but gradient start -> gradient end -> gradient start. AFAICS the original reporter would like the former, so that a rainbow effect can be created with a rainbow gradient.

 * The plug-in crashes when using the Abstract 3 gradient with a width of 70, and when when Use Inverted Gradient is 'yes'. Also, it would be nice of the selected gradient by default would be the gradient selected in the GIMP user context. Not sure if this is possible though.
Comment 9 Sven Neumann 2008-07-07 11:15:23 UTC
IMO the approach taken here is too hackish to be included. We should concentrate on implementing the real thing. Can this functionality be implemented using Cairo? Otherwise someone would first have to implement it in Cairo. Since this is unlikely to happen for 2.6, let's bump this to the Future milestone.
Comment 10 weskaggs 2008-07-07 15:42:33 UTC
I don't see why Cairo is needed here.  Imho this would be pretty easy to implement, but hard to implement efficiently.  What is needed is, for each point in the selection, to find the nearest point on the path, and calculate the distance of that point from the start, and use that distance to derive a color from the gradient.  If this calculation is done independently for every point in the selection, it will be wickedly slow.  It seems to me that some sort of faster flood-fill-type method ought to be possible, but I can't quite work it through.
Comment 11 Sven Neumann 2008-07-07 17:52:11 UTC
Cairo is not needed. But since we stroke paths using Cairo, it would be the easiest solution if Cairo would provide the capability to render a gradient along the path. Other applications could certainly also benefit from that. But of course an implementation in GIMP, or preferably in GEGL, would also be fine.
Comment 12 GNOME Infrastructure Team 2018-05-24 10:32:55 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/9.