Re: [Gimp-developer] is watercolor (brush color blending mode)...
Hi, 2008/7/29 <[EMAIL PROTECTED]>: > It is, right now that test program is destructive in that it forces a > save/merge-down of the stroke as a temporary workaround until cache > management in GEGL becomes better. [...snip...] > The task of the painting operation is to provide the rendered result for a > series of input events/coordinates, as well as a configuration for how it > should be rendered. The code is written in a manner that makes it possible to > append to the path and recompute a minimal region (semi working, but has some > visual artifacts). All the things GIMP currently do can > be expressed using this. It can also be easily extended to store line width > and opacity varying along the stroke. > > When it comes to implementing more destructive like buffer access for > performance reasons one could implement an operation that operates on a > GeglBuffer in-place. It would still be possible to replay it from history, > but there wouldn't be valid caches for each operation, and the replay would > be much more expensive. We could add a smaller undo stack for the buffer > though adding support for undo tiles for GeglBuffers has existed in the past > and could be resurrected. Such a smaller undo stack might be useful, but that > is probably something to keep in mind later after purging of caches, and copy > on write works better. Thank you for your explanation. Now I understand what you mean "destructive", and your idea of brush implementation. Basically brush operations are ready to be non-destructive in that it has a path information. And we can choose destructive operations instead of default cache updating algorithm for better performance as needed. I think implementing undo cache is a good idea. My main concern is about the performance of the brush processing both for speed and memory usage. I'm anxious about the performance a little yet, but I hope GEGL to have enough performance in the future. -- Souichi TAKASHIGE ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] is watercolor (brush color blending mode)...
Hi, 2008/7/29 David Gowers <[EMAIL PROTECTED]>: [...] > I was only addressing what you said "So it can't be non-destructive > unless we save > that cache forever.", by indicating why little caching is needed for > the non-destructive case -- the actual parameters of the operation are > kept. I see. Thank you for your explanation. >> Let's say, If the following operation sequences are executed, how can >> we undo and redo the brush operation (C) and (D)? And what will happen >> if we change the prarameter of the operation (B)? > After a destructive operation, you cannot change parameters of earlier > steps -- the information necessary to do so no longer exists. > Therefore, after C happens, changing B is meaningless -- B no longer > exists in any sensible way. [...snip...] > I also think it's important to keep in mind, when working fully with > GEGL, undo and redo would be implemented by modification of the GEGL > graph. I admit I do not understand how there can really be any > destructive operation, in that framework; unless you allow old graph > modifications to expire (and turn that branch into a GeglBuffer) I think so too. So I wonder how can I manage non-destructive and destructive operations together without corrupting its non-destructive semantics. > I personally believe that destructive editing doesn't have merit by > itself, it doesn't save time or improve the responsiveness of a > program. > Rather, it is worth using as a tool similar to 'clear undo history' -- > in GEGL, it is like collapsing a branch of the graph into a single > leaf. I have no idea when to use non-destructive feature as for painting work with a brush tool. It's more natural and more intuitive to make new strokes on top of existing one to modify the part of the existing strokes rather than to modify the parameters of existing path. So current implementation is enough. Replacing brush tools with a non-destructive one has little merit, and it has a risk to be slower and more memory consuming in certain situations for painting artists. Making a brush tool non-destructive itself is a great work, so I think it's better to separate destructive layers from other non-destructive operations. Painters may use destructive layer to avoid the risk to be slow, and others may use non-destructive one. I think it is a GIMP's design matter rather than the implementation problem of the GEGL. -- Souichi TAKASHIGE ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] is watercolor (brush color blending mode)...
Hi, > No, it's only destructive if we have no way of regenerating the cache as > needed. > With GEGL, we can cache just at the newest node in the graph. Stroke > information can be fully stored in the node. I'm confused. >From my understanding, if stroke information is stored in the node, then the stroke can be regenerated, and that operation will be non-destructive since the cache can be regenerated. I think David says about "non-destructive" brush operation. I saw source code of gegl-paint. It seems that gegl_vector stores the information of the path, so I think it is also about non-destructive brush tool. On the other hand, Øyvind says that we can implement "destructive" brush. I think being "destructive" implies that there's no way to regenerate the stroke since being able to regenerate the stroke means that the cache is regeneratable, so the operation must not have any path information. My concern is about this case. Let's say, If the following operation sequences are executed, how can we undo and redo the brush operation (C) and (D)? And what will happen if we change the prarameter of the operation (B)? (A) load an image from external resource. (B) do filter operation, "non-destructive." (C) do brush operation, "destructive." (D) do another brush operation, "destructive." (E) do filter operation, "non-destructive." If my assumption is wrong, please let me know. -- Souichi TAKASHIGE ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] is watercolor (brush color blending mode)...
Hi, 2008/7/28 Øyvind Kolås <[EMAIL PROTECTED]>: > The situation would be the same for GEGL once the bug in > http://bugzilla.gnome.org/show_bug.cgi?id=502465 gets resolved. Since > the part of the processing graph underneath the top most added stroke > doesn't change, and it can be recomputed from the parameters of the > nodes in the graph there is no need to always persist the actual > pixels. This is a general optimization that also will help other parts > of GEGL. Experimenting with the gegl-paint example in the GEGL sources > will be a natural thing to do when fixing this bug. (The code in there > should be easily modifiable to become full non-destructive again). Thank you for your comment. I don't how to recompute the destructive brush stroke yet. Or I might misunderstanding the meaning of "destructive." I thought destructive means "destroy image itself and cannot undo it nor redo it" unless we manage the undo cache. So it can't be non-destructive unless we save that cache forever. But maybe it's better to check the source code of gegl-paint first. -- Souichi TAKASHIGE ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] is watercolor (brush color blending mode)...
2008/7/28 Liam R E Quin <[EMAIL PROTECTED]>: > On Mon, 2008-07-28 at 01:19 +0900, Souichi TAKASHIGE wrote: >> [...] > >> But it costs too much memory when we >> make a lot of strokes -- and we *DO* make thousand of strokes when we >> draw an image -- compared to the current implementation which has a >> buffer per each layers. > > That's something that needs to be measured. I see. It takes much memory when we draw brushmarks many times on the same area, I think that is very usual situation. Perhaps we should study the memory usage for this situation. > Don't forget that right now, the strokes are stored individually in > the undo history anyway. Yes and no. GIMP copies previous tiles prior to its modification, but that is part of previous layer image, not a stroke itself. GIMP can forget the undo cache, and do forget the undo cache (on program termination for example.) On the other hand, GeglBuffers for each strokes should be kept persistently. That is a big difference between undo cache and contents of GeglBuffer. But we can estimate the rough memory usage for the situation above from the memory usage of the undo cache. -- Souichi TAKASHIGE ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] is watercolor (brush color blending mode)...
Hi, > They do not need to be made fully non-destructive, for the paint core > I have been experimenting with on top of GEGL[1] I have both a > destructive and a non destructive version. The difference between them > being that the destructive one continuously replaces the contents of a > GeglBuffer instead of building a graph. Making things non-destructive > doesn't necessarily imply additional work when creating brush painting > processes if the infrastructure to do so exists. I'm very glad to hear that. I think keeping destructive brush tool is essential for painting tool. I will try to find the way to add features such as color blending when that code is merged into the svn tree. But then, I have another question about destructive brush tool. How does the GEGL manage the non-destructive and destructive operations together? In my understanding, if we modify GeglBuffer directly with destructive operations, contents of the GeglBuffer can't be purged because we can't reproduce the brush strokes. That means all of the non-destructive operations prior to the last destructive operations can't be non-destructive any more. One solution is to have one GeglBuffer for each stroke, and combine them when update the display. But it costs too much memory when we make a lot of strokes -- and we *DO* make thousand of strokes when we draw an image -- compared to the current implementation which has a buffer per each layers. Another idea is to separate destructive layers from non-destructive layers. The destructive layer can have only destructive operations, and GeglBuffer of this layer can be replaced repeatedly with no matter. I think this idea make sense. If this question does not related to GIMP at all, I will post a new question to the GEGL ML. If the GIMP has to solve the problem, please tell me your idea to mix the destructive and non-destructive operations. > These are features that might easily be added on top of a GEGL based, > both destructive and non-destructive paint core. At least if using > hardware acceleration like the ClutterGegl view widget to display the > final composite. At GUADEC this year I showed a mini painting app > embedded in a presentation tool where I could freely rotate the GEGL > paint demo and paint at it at any angle. Great! I'm looking forward to see these nice features on the GIMP. -- Souichi TAKASHIGE ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] is watercolor (brush color blending mode)...
Hi, >> 1.is this going to be avaiable in some of the 2.5 releases, because if >> it is,i'm gonna bug tests it > No, it is not going to be available in 2.5, unless you fix the patch > or persuade Souichi Takashige to do so. Sorry, I'm currently working on another program, so I have not maintained the patch any longer. GIMP will be fully non-destructive editor in the future, but I think that is not a good news for users who use GIMP as a painting tool. Non-destructive editing is convenient in some situations, but a lot of brush painting processes don't need to be non-destructive, and making all of them non-destructive is a waste of time and resources. GEGL and GIMP are great work of cource, it is very powerful photo retouching tool. But it's not good for painting images from scratch since it lacks a lot of features specialized for painters (like view rotation and flipping.) I think being general purpose program is a waste of time: code size will grow constantly and the architecture will be more and more complex. No one can maintain it. So GIMP should focus on the photo retouching, and other programs like Artweaver, Gogh, and MyPaint should focus on painting features. -- Souichi TAKASHIGE ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] batch-processing gallery
Hi, 2008/3/26, Sven Neumann <[EMAIL PROTECTED]>: > Whatever you do to the image is represented as a graph. If you are doing > a series of operations on an image, then your graph boils down to a load > operation, a chain of manipulations and a save operation. Do you mean every stroke path like interactive paint tool MUST become an graph nodes ? Or do you mean only some specific operations (one that is suitable for batch) are represented as gegl node, and rest of the operations can still modify image directly ? If we chose first policy, the operation nodes quickly be flooded with enormous amount of stroke path history for users who use GIMP as a paint tool. I believe that we should classify operations into destructive ones (like paint brush) and non-destructive ones (like filters and rotations etc.) , and user can use combination of destructive and non-destructive operations in some ways. Or we should allow users to blit a part of the nodes into newly created image to save memory space by discarding some of the operation history. Please let me know the treatment of the destructive editing operations in future gimp. -- Souichi TAKASHIGE ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Prototype of PaintBrush extension framework.
2008/3/23, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Prototype of PaintBrush extension framework.
Hi, 2008/3/23, Sven Neumann <[EMAIL PROTECTED]>: > 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Prototype of PaintBrush extension framework.
Hi, 2008/3/14, Sven Neumann <[EMAIL PROTECTED]>: > 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 |<---GimpPaintModifier | - coords | | - colors | | - canvas_buf | | - mask| | - opacity | +---+ | | apply or replace V GimpDrawable In this model, modifiers can access share context and read only operation of GIMP core objects. 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.) -- Souichi TAKASHIGE ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Prototype of PaintBrush extension framework.
Thank you for your advice.
2008/3/13, Martin Nordholts <[EMAIL PROTECTED]>:
> 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 56 – PaintBrush extension framework .)
Should we go bugzilla to discuss the idea ?
2008/3/13, Sven Neumann <[EMAIL PROTECTED]>:
> 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.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] 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<http://prdownloads.sourceforge.jp/gimp-painter/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 [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Prototype of PaintBrush extension framework.
Sorry, I sent same mail for three times. Souichi TAKASHIGE [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] 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 [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] 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 [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
