GNOME Bugzilla – Bug 140165
A Paint Tool that allows stroke events to callback plug-in procedures
Last modified: 2005-02-21 14:50:25 UTC
Hi, I know it had been thought before, but anyway could not find it in bugzilla. So here it comes: GIMP should implement a "Generic Paint Tool" that would not affect the image, but rather provide a callback with each stroke/pointer movement parameters. This would allow plug-ins to implement a lot of functionality currently only available to things implemented directly on the core (therefore clugging the UI). One example of an existing plug-in that would take advantadge of it is "i-warp". BUG 140161 also requests a feature that would be easily implemented via plug-in (even script-fu) if this functionality was available. The API for this could be something like: gimp_generic_paint (helper_string, callback_function, generic_paint_mode) Were generic paint mode would say which events/data should be passed to the call back (coordinates, movement, button press, button release, pressure, tilt, time of event) Or better, a fixed struct with all this date filled in, and the call back would use whatever data it needed.
The problem is that Gimp plug-ins are not callbacks, they are external programs that communicate with the core in a defined way. At the moment, the communication is pretty much controlled by the plug-in: it sends a message to the core, and the core responds. Your idea would require reversing the interaction, and that would take quite a bit of work. I have been thinking about a different way of accomplishing something similar, using the GtkPlug-GtkSocket mechanism. In principle it should be possible for the core to create a socket encompassing the image display, and pass it to the plug-in, which could place an EventBox there and thus get full pointer information in the coordinate system of the display.
I would confirm this enhancement request but the current title/summary is completely misleading.
Regarding Comment #1 - that would give a low level access to events, and would make some tasks otherwise simple too complicated. Maybe it would be nice to have such low-level operationa available, but I was thinking more of a callback taht would bring the drawable, gimpcoordinates, time, pressure and tilt. The gimp core already has plenty of code for dealing with all this - no need to duplicate that for most plug-ins that could use this callback.
Adding a new paint-core to the GIMP core is trivial. So if anyone wants to hack a nice new painting tool, this can be easily done in the GIMP core and we will certainly accept such patches. Adding a module or plug-in API for this would however be a very complex task. So if you are asking for this to be able to develop a nice new way of painting, why don't you have a look at app/paint. You will notice that it is actually very simple code. All that needs to be done to add a new paint tool is to derive from GimpPaintCore or (GimpBrushCore if your paint-tool wants to use brushes) and implement the functionality defined therein. The existing paint-core objects can serve as an example. In order to use the new paint-core, you would then have to add a new paint tool. If you have a look at for example app/tools/gimppaintbrushtool.c, you will notice that this is a trivial thing to do.
Ok, reading Sven's comments and recent e-mails, I thought of other ways of doing this. Instead of a callback API, a normal paint tool could be made to use what could be called "procedural brushes" - description files that would contain parameters, including certain parameters stored in a programatically way - like a string of operators used to specify certain fractals, or the old APPLE ][ 'shapes' - Also, these brushes could ask for some parameters to be appended in the Tool Options itself - like registering a script-fu does. It could be thought so that with different brush scripts it could address: Bug 65118 Bug 74554 Bug 109801 Bug 111082 and a full image version of the Iwarp plugin. -- Again, this bug report is more for tracking the idea, and formalize it. I am not asking anybody to rush and implement it or all the infrastructure needed. (Actually, a part of the structure is factoring of the "time smoothing" code from the ink tool. It is a separate issue that could IMHO be addressed in early 2.3 cycle, which would allow implementing this and a couple other painting related bugs)
Well, "some description files" isn't very descriptive. Nor is "a string of operators". And you could certainly not do anything like Iwarp based on such an infrastructure. Joao, this report is void. It's a loose collection of buzzwords, nothing else. Either you come up with a reasonable description of what you want or we will have to close this report.
Setting to NEEDINFO for the reasons given in comment #6.