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 522226 - PaintBrush extension framework
PaintBrush extension framework
Status: RESOLVED OBSOLETE
Product: GIMP
Classification: Other
Component: Tools
git master
Other All
: Normal enhancement
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2008-03-13 13:01 UTC by Souichi Takashige
Modified: 2018-05-24 12:20 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Snapshot of the prototype (169.46 KB, patch)
2008-03-13 13:50 UTC, Souichi Takashige
needs-work Details | Review

Description Souichi Takashige 2008-03-13 13:01:58 UTC
I'd like to introduce an extension framework into the GIMP.
The framework provides the way to add new features to the PaintBrush.
Framework itself is very simple: Add many event handler chains such as
"init-motion" "motion" "finish-motion" etc.
to the PaintBrush, PaintOptions, and PaintBrushTool objects.
Objects calls the handlers to "change" the behavior of the brush.

This framework is designed based on the following concepts:
- Flexible:
 Developer can easily add new features to the existing codes.
- Modular:
 Each new features can be implemented in one modules. two independent
 features are separated in other modules, and developers can develop
 new code independently.
- Dynamically loadable (planned)
 New features should be dynamically loaded on startup.
 Developers can distribute new features as a separate shared library.
Comment 1 Souichi Takashige 2008-03-13 13:50:54 UTC
Created attachment 107218 [details] [review]
Snapshot of the prototype

This is a current snapshot of the PaintBrush extension framework.
This patch can be applied to GIMP 2.4.1 release.

The approach is very simple: Brush has some event handler callback chain.
The brush calls the callbacks at proper point to change status of brush
properties and cursor position.

This patch is developed to prove the possibilities to implement extension framework, so all APIs are experimental, and we should keep improvement.

In this patch, The following classes and objects are introduced.

1. Sample brush classes to be enhanced.
* GimpCustomBrush (/app/paint/gimpcustombrush.{h,c})
  - Implementing fundamental brush behavior.
  - Few event handler chains are defined. (API is not fixed at all.) 
    Event handlers are called from CustomBrush object at proper point
    of the brush implementation.
    + init_motion : called when button becomes down.
    + motion : called when cursor is moved.
    + register_paste_canvas : 
      called when brush must paint something into tile. This function only 
      register the task list to be applied to the canvas. Registered tasks 
      are applied after all callback functions finished registering tasks.
    + finish_motion : called when button becomes up.
   - Event chain callbacks are implemented instances of BrushModifierCore and its derived classes.

* GimpCustomBrushOptions (/app/paint/gimpcustombrushoptions.{h,c})
   - Manages brush options and persistence.
   - It can be extended by instances of BrushModifierOptions and its derived classes.

* GimpCustomBrushTool (/app/tools/gimpcustombrushtool.{h,c})
   - Manages tool info and brush options GUI creation callback.
   - It can be extended by instances of BrushModifierTool and its derived classes.

2. Intermediate brush state
*GimpCustomBrushState
This object holds some status which is only valid in one stroke.
The status is reset when one stroke is finished.
Status contains:
   - Foreground color
   - Background color (planned)
   - canvas masks to be applied (planned)
   - and so on 

3. Modifier classes those implement modification to the brushes
Modifier objects are attached to the brush objects listed above, and change their behavior. Several modifiers can be attached to one brushes so that user can use several modifiers at once.  These objects has internal status which is required to implementing features (such as history of cursor pointers and so on.)
* GimpBrushModifierCore (/app/paint/gimpbrushmodifiercore.{h,c})
  - This class and its derived classes defines the callback methods to be called from GimpCustomBrush object.

* GimpBrushModifierOptions(/app/paint/gimpbrushmodifiercore.{h,c})
  - This class and its derived classes adds new properties to GimpCustomBrushOptions class, and defines the callback methods to be called from set_property/get_property method of GimpCustomBrushOptions. These manage set/get properties introduced by themselves.

* GimpBrushModifierTool(/app/tools/gimpbrushmodifiertool.{h,c})
  - This class and its derived classes defines the GUI creation functions which are called from the GUI creation functions of GimpCustomBrushTool.

4. Internal PasteCanvas task info
GimpPaintMaskInfo and GimpBrushCorePasteCanvasInfo defines the task to be done when canvas_buf and mask region are applied to the drawable. This API is very experimental and should be rewritten in the future.

5. Example Modifiers
Blending feature and Line point adjustment feature are implemented as examples of this framework. They extends GimpBrushModifierCore, GimpBrushModifierOptions, and GimpBrushModifierTool, and instances of those classes are attached to Brush objects(See *_load functions in gimpcustombrush*.c .) These modifiers should be loaded dynamically in the future.
Comment 2 Michael Natterer 2008-03-13 16:03:29 UTC
Wow that looks pretty impressive and interesting :-)

However, the chances that any developer applies and tries this patch
in their local tree are close to zero unless it is updated to apply
against SVN trunk...

Also, the GIMP core is a moving target, so developing against a tarball
instead of SVN trunk makes it significantly harder for you to update
the patch with changes from upstream, which you definitely have to do
in order to bring such a big patch into a state that makes it a 
candidate for inclusion at all.

I don't want to sound discouraging :) These are simply practical issues.
Comment 3 weskaggs 2008-03-16 04:48:02 UTC
This was discussed in the developer list, and I commented there, but just for completeness here:  I was able, after about two hours of struggling, to apply the patch to trunk, and found it very interesting.  Like mitch, I believe it would be a good idea to move development into an svn branch as soon as possible.  The code is not quite ready for trunk, but it is complex enough to make it good to use SVN.
Comment 4 david gowers 2008-03-17 07:09:53 UTC
Bill, 

I assume that what you've got is a bit messily done but works.
Have you sent a diff based on your results to Souichi? If not, would you attach such a diff to this bug report?
Comment 5 Alexia Death 2008-08-08 18:59:33 UTC
I to am interested in the patch as it stands updated against SVN, so if somebody has it, please post. Also, if mr Takashige would be interested working on this and making a full dynamics supporting and dynamically loadable brush tool framework, tho I lack the skills to do that on my own, I am willing to help with coding to the best of my ability.
Comment 6 Alexia Death 2011-08-11 16:34:37 UTC
This will need to wait for gegl paint core, where a new brush engine would just mean a new op.
Comment 7 Jehan 2012-08-05 05:15:22 UTC
Hello,

having just bought a DVD from the Blender Foundation which advices to use this patch, I discovered that this patch has some big success when searching the web for information about its usage; but its last version is for Gimp 2.6 (and we are 2.8). The bought DVD even provides a patched Gimp 2.6 in the DVD.

Now I see Alexia's message. Do you mean that in the GEGL support of Gimp, this new brush (or a similar feature, which would allow basically the same kind of things) is already supported, hence this patch is no more relevant? Or do you mean that once Gimp has full GEGL support, we would be able to try and port this patch to the dev tree?

I ask because I would be willing to try and port the patch to the Git repo if this still makes sense. Does it? I'd like to avoid working for no reason if possible. :-)
Thanks.
Comment 8 Jehan 2016-02-13 15:02:03 UTC
Very sad bitrotting. I doubt there is much which can be salvaged from this 2008 patch. But after a search, I discover that the author moved the development to GIMP 2.8, which is already much better!

See https://github.com/seagetch/gimp-painter

This is still not the master branch, so there is the whole GEGL issue, but it gives some new hope.

Souichi > would you not be interested to work with us to integrate your improved brush system into upstream GIMP?
Comment 9 GNOME Infrastructure Team 2018-05-24 12:20:13 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/268.