Prototype of PaintBrush extension framework.
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
Prototype of PaintBrush extension framework.
Hi,
I'm recently working on developing new PaintBrush extension framework. It's on early development stage, but I'd like to get comments about the framework.
This framework provides the way to add new features to the PaintBrush.
Framework itself is very simple: Add many event handler chains such as
"motion-event-handler" to the PaintBrush, PaintBrushOptions, and
PaintBrushTool.
PaintBrush 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.
Currently patch against GIMP 2.4.1 is available. (Sorry, but it can't be
applied to
the latest stable release.)
You can get the patch from
http://sourceforge.jp/projects/gimp-painter/files/?release_id=29937#29937
gimp-custombrush-2.4.1-sig-080311-1.diffis the latest development snapshot.
I'm implementing color blending feature and line smoothing feature as
examples
of the framework.
You can also see some examples of the currently working demonstrations at http://www.youtube.com/watch?v=SIg8Omew9Ps
I'm keeping development of this framework and want to commit this framework
in the
future.
If you have any comments about this framework or similar ideas, please let
me know.
Regards.
--
Souichi TAKASHIGE
sigetch@gmail.com
Prototype of PaintBrush extension framework.
Hi,
I'm recently working on developing new PaintBrush extension framework. It's on early development stage, but I'd like to get comments about the framework.
This framework provides the way to add new features to the PaintBrush. Framework itself is very simple: Add many event handler chains such as "motion-event-handler" to the PaintBrush, PaintBrushOptions, and PaintBrushTool. PaintBrush 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.
Currently patch against GIMP 2.4.1 is available. (Sorry, but it can't
be applied to
the latest stable release.)
You can get the patch from
http://sourceforge.jp/projects/gimp-painter/files/?release_id=29937#29937
gimp-custombrush-2.4.1-sig-080311-1.diff is the latest development snapshot.
I'm implementing color blending feature and line smoothing feature as examples of the framework.
You can also see some examples of the currently working demonstrations at http://www.youtube.com/watch?v=SIg8Omew9Ps
I'm keeping development of this framework and want to commit this
framework in the
future.
If you have any comments about this framework or similar ideas, please
let me know.
Regards.
--
Souichi TAKASHIGE
sigetch@gmail.com
Prototype of PaintBrush extension framework.
Hi,
I'm recently working on developing new PaintBrush extension framework. It's on early development stage, but I'd like to get comments about the framework.
This framework provides the way to add new features to the PaintBrush. Framework itself is very simple: Add many event handler chains such as "motion-event-handler" to the PaintBrush, PaintBrushOptions, and PaintBrushTool. PaintBrush 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.
Currently patch against GIMP 2.4.1 is available. (Sorry, but it can't
be applied to
the latest stable release.)
You can get the patch from
http://sourceforge.jp/projects/gimp-painter/files/?release_id=29937#29937
gimp-custombrush-2.4.1-sig-080311-1.diff is the latest development snapshot.
I'm implementing color blending feature and line smoothing feature as examples of the framework.
You can also see some examples of the currently working demonstrations at http://www.youtube.com/watch?v=SIg8Omew9Ps
I'm keeping development of this framework and want to commit this
framework in the
future.
If you have any comments about this framework or similar ideas, please
let me know.
Regards.
Souichi TAKASHIGE sigetch@gmail.com
Prototype of PaintBrush extension framework.
Sorry, I sent same mail for three times.
Souichi TAKASHIGE sigetch@gmail.com
Prototype of PaintBrush extension framework.
Hi,
On Thu, 2008-03-13 at 03:06 +0900, Souichi TAKASHIGE wrote:
I'm recently working on developing new PaintBrush extension framework. It's on early development stage, but I'd like to get comments about the framework.
This looks very interesting. It would help a lot if you could send the patch to the mailing-list so that one wouldn't have to click through web ads in order to review it.
So far I have not quite understood what your patch does. Nor did I understand why you haven't discussed the design before starting to implement it. Perhaps it would be a good idea to explain the ideas of your approach now.
Sven
Prototype of PaintBrush extension framework.
Souichi TAKASHIGE wrote:
Hi,
I'm recently working on developing new PaintBrush extension framework. It's on early development stage, but I'd like to get comments about the framework.
Hello
This is very interesting and something that I think we definitly should consider to integrate into GIMP trunk. Maybe not into GIMP 2.6 since the 6 months development cycle since GIMP 2.4 is coming to an end, but at least for GIMP 2.8.
In order to make it easier to track changes to the patch, could you please create an enhancement request about this in Bugzilla? (bugs.gimp.org) We can still continue discussion on the list but the patch will be much easier to track in Bugzilla.
Thanks,
Best regards, Martin Nordholts
Prototype of PaintBrush extension framework.
Thank you for your advice.
2008/3/13, Martin Nordholts :
In order to make it easier to track changes to the patch, could you please create an enhancement request about this in Bugzilla? (bugs.gimp.org) We can still continue discussion on the list but the patch will be much easier to track in Bugzilla.
I submitted this request (Bug 522226 – PaintBrush extension framework .) Should we go bugzilla to discuss the idea ?
2008/3/13, Sven Neumann :
So far I have not quite understood what your patch does. Nor did I understand why you haven't discussed the design before starting to implement it. Perhaps it would be a good idea to explain the ideas of your approach now.
I posted some explanation of the patch at bugzilla. Same description
is copied below.
Actually, I had studied about the PaintCore and its derived classes, and
implemented "hardcoded" blending feature at first. This framework is
the result of clean-up work of existing color blending codes.
=== description start here === 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.
Prototype of PaintBrush extension framework.
On Thu, Mar 13, 2008 at 8:06 AM, Souichi TAKASHIGE wrote:
patch will be much easier to track in Bugzilla.
I submitted this request (Bug 522226 – PaintBrush extension framework .)
I'm about to post a longer comment, but just as a quick response to this: I think it's a very bad idea to try to use Bugzilla for this purpose: the bug report will quickly become too long to handle. It would be best by far if you could do your development within SVN, which is really designed for things like this.
-- Bill
Prototype of PaintBrush extension framework.
I managed to get this patch to build with trunk yesterday, after some struggling. I am only starting to understand what is going on here, but I thought it might be useful to dash off a thumbnail review.
First, for readers who might not examine the patch in detail, it is worth saying that this is a significant effort, representing several months of work, and a design that has been thought out with a lot of care. It is by no means a finished product, but it is already very impressive.
The general concept is to create something like a "pluggable brush". The code sets up a "custom paintbrush tool", with a customizable paint core. (The paint core is the set of C functions that render brushmarks on the image.) The paint core is customized by registering a set of "paint core modifiers". Each "modifier" inserts a gui-block into the tool options, and includes C code for modifying the brush in some way. When the user paints, all of the modifiers are applied in sequence before the mark is finally made on the image.
In the patch, three modifiers are included: a "brush modifer", a "blend modifier", and a "smooth modifier". The code for these is at present added to app/paint, but the idea is eventually to make it possible to add modifiers as "modules".
In Gimp, and other programs that use Glib, *modules* are program-fragments that can be compiled separately from the main application, and linked in dynamically while the program is running. They differ from plug-ins in that once loaded they function as part of the application, not as separate programs that communicate with the application. The danger of modules is that if they crash, the whole program crashes with them. The power is that they have complete access to everything that Gimp can do. Currently Gimp does not use modules very heavily: they show up mainly as color selectors, display filters, and handlers for exotic types of input.
Adding modules to Gimp is easy in principle: you just place them in the "modules" folder in your Gimp directory. There are very few Gimp developers who have actually written a module, though, and it isn't clear to me whether it is intrinsically more difficult than writing a plug-in, or whether it simply lacks a good set of instructions and a good "template".
It's pretty clear that this code will not be ready for 2.6, which is on a fast development track. In any case, the code looks very promising, and I would favor getting the development process into SVN as soon as possible, perhaps in a special branch dedicated for the purpose.
-- Bill
Prototype of PaintBrush extension framework.
On Thursday 13 March 2008 17:56:40 Bill Skaggs wrote:
I managed to get this patch to build with trunk yesterday, after some struggling. I am only starting to understand what is going on here, but I thought it might be useful to dash off a thumbnail review.
Thanks for that... I would really like to see it in some branch of trunk... It sounds like a leap towards those dream brushes and I'm interested in helping out as much as I can :) Kudos to the author:)
Prototype of PaintBrush extension framework.
Hi,
On Thu, 2008-03-13 at 08:56 -0700, Bill Skaggs wrote:
In Gimp, and other programs that use Glib, *modules* are program-fragments that can be compiled separately from the main application, and linked in dynamically while the program is running. They differ from plug-ins in that once loaded they function as part of the application, not as separate programs that communicate with the application. The danger of modules is that if they crash, the whole program crashes with them. The power is that they have complete access to everything that Gimp can do.
Sorry, but the latter is not true. We don't allow modules to access internals of the GIMP core. A module implements a certain class and that's it. It must not do any calls into GIMP. Thus, modules are a lot more limited than plug-ins as the plug-in API is richer and more powerful.
Sven
Prototype of PaintBrush extension framework.
Hi,
2008/3/14, Sven Neumann :
On Thu, 2008-03-13 at 08:56 -0700, Bill Skaggs wrote:
> In Gimp, and other programs that use Glib, *modules* are > program-fragments that can be compiled separately from the main > application, and linked in dynamically while the program is running. > They differ from plug-ins in that once loaded they function as part of > the application, not as separate programs that communicate with the > application. The danger of modules is that if they crash, the whole > program crashes with them. The power is that they have complete > access to everything that Gimp can do.
Sorry, but the latter is not true. We don't allow modules to access internals of the GIMP core. A module implements a certain class and that's it. It must not do any calls into GIMP. Thus, modules are a lot more limited than plug-ins as the plug-in API is richer and more powerful.
I think design of API is the biggest issue.
Performance is very important for interactive tool, From my experience, it is
necessary to allow modifier objects to access some of gimp core objects
or internal image buffer directory to keep high performance.
Of course it is also important to limit the functions that modifier
can access to
keep the framework simple and to avoid the dependency on Gimp core API.
I am currently refactoring the code and APIs. The brush and modifiers share
some context. Modifiers get informations like pixels, alpha channels
and bit depth etc.
from the drawable object, and modify shared context. Then brush object
draw strokes
using the context.
GimpDrawable, GimpPaintOptions |
| Get Information (read only)
Set +-------------------+ Modify V
GimpPaintCore ------------>| GimpPaintContext | modules to
access internals of Gimp core objects (those are passed as the
arguments of the callback
functions.)
--
Souichi TAKASHIGE
Prototype of PaintBrush extension framework.
Hi,
On Sun, 2008-03-23 at 17:45 +0900, Souichi TAKASHIGE wrote:
To implement the brush modifier framework, I want to allow some "privileged" modules to
access internals of Gimp core objects (those are passed as the arguments of the callback
functions.)
Sorry, but that is not going to happen. We are not going to expose the interal API to modules or plug-ins as that would make it very hard to do the large changes to the core that are planned for the next development cycles.
If you absolutely insist on the idea of having a public module API for your framework, then we will have to introduce proxy objects. These proxies can then be exposed to modules and they will interface with the actual core objects. This extra abstraction level should be kept as small as possible and it should not have a noticeable impact on performance.
Sven
Prototype of PaintBrush extension framework.
Hi,
2008/3/23, Sven Neumann :
Sorry, but that is not going to happen. We are not going to expose the interal API to modules or plug-ins as that would make it very hard to do the large changes to the core that are planned for the next development cycles.
I know that it is difficult to expose the API for modules. But as for
"privileged" modules, since it aims to enhance existing code directory from
external modules, when the internal structure changes, framework itself
must be changed. So module developer should know the internal structure
for well.
I think it is responsibility of module developers for
synchronizing its code to the latest version of API so that exposing API
does not prevent to change its interface.
That policy may breaks the compatibility of "privileged" modules, but that risk is reasonable until the internal structure becomes stable. If the compatibility matters much, we can introduce some version number validation protocol to check the incompatibility easily.
But anyway, I will try to list the API which may be accessed from
privileged modules.
--
Souichi TAKASHIGE
Prototype of PaintBrush extension framework.
On Sun, 23 Mar 2008 14:03:58 +0100, Souichi TAKASHIGE wrote:
I think it is responsibility of module developers for synchronizing its code to the latest version of API so that exposing API does not prevent to change its interface.
That is not a very helpful attitude. Having a stable API is essential. Version dependancies are already a major headache on linux , repeating that within Gimp does not seem attractive. I dont think it is helpful to envolve everyone who ever wrote/writes some tool, module or plugin into a some weekly maintainance loop. This just wont happen.
What will happen is that a lot of useful code will quickly become obsolete and if it becomes a major long term comittment to mainainance those willing to contribute will deminish further.
Changes to APIs can be necessary sometimes but this should only be done as matter of last resort , not as a matter of course.
You cannot expect the turn the whole situation on its head because it suits what you would like to do.
It's your responcability to find a solution not let everyone else deal with fall out for the rest of time.
Prototype of PaintBrush extension framework.
2008/3/23, gg@catking.net :
That is not a very helpful attitude. Having a stable API is essential. Version dependancies are already a major headache on linux , repeating that within Gimp does not seem attractive. I dont think it is helpful to envolve everyone who ever wrote/writes some tool, module or plugin into a some weekly maintainance loop. This just wont happen.
Sorry, but in my previous post, module refers to the "privileged module", which differs from normal module. Anyway, now I see the importance of the stable API. Thank you for your comment.
But stable API must be designed on top of new core API (maybe GEGL
ops.) to keep good performance. So we have to suspend the further
discussion until new paint core APIs are released.
Maybe privileged module should access to some internal GEGL nodes
before it is applied to the drawable, and modify its parameters to
change the brush behavior.
--
Souichi TAKASHIGE
