On Thu, 18 Nov 2004, Juhana Sadeharju wrote:

Date: Thu, 18 Nov 2004 13:21:49 +0200 From: Juhana Sadeharju
To: gimp-developer@lists.xcf.berkeley.edu Subject: [Gimp-developer] Re: whishes for Gimp

From: Sven Neumann

Adding more tools has the disadvantage of cluttering the toolbox.

Just suggestions:

Solution 1: everything goes to menu (tree) and each non-default menu item would have toggle which would append it to the toolbox.

The toolbox can already be customized, you can see for yourself if you try one of the version 2.2 prereleases.
Go to
File, Dialogs, Tools,
and if you have an up to date version there will be an 'eye' icon next to each tool allowing you to show/hide whatever tools you want.

Sven's point still stands though, adding more tools to the default toolbox is not a great idea.

Sincerely

Alan Horkan

Free SVG Clip Art http://OpenClipArt.org Abiword is Awesome http://abisource.com

On Sunday 21 November 2004 09:29, Juhana Sadeharju wrote:

From: Alan Horkan

Sven's point still stands though, adding more tools to the default toolbox is not a great idea.

I agree completely, because I did not suggest that.

We still need a system which allows us to add as many tools as needed to the tool pucket --- a tool plugin system (or extended existing plugin system) would help. You can hide non-default tools as deep in the system if you wish, but users should be able to have the tool they want and need.

It just does not make sense to keep a user in doing things more complicated way only because somebody wants keep the tool number down to minimum or wants avoid alternative tools (being too similar to existing tools).

Could existing plugin system be expanded so that the plugins may create the control objects as overlays to the image windows?

One idea that is one of the pre-requisites for plugable tools is a way for plug-ins to receive pointer actions and coordinates.

I have openned bug 140165 to track such idea and help develop it, hopefully over the next development cycle. ( http://bugzilla.gnome.org/show_bug.cgi?id=140165 )

We should refine the idea of a plug api for a tool to register itself as such, and possibly to make itself visible or not in the main toolbox.

JS
->

Juhana

Hi,

"Joao S. O. Bueno Calligaris" writes:

I have openned bug 140165 to track such idea and help develop it, hopefully over the next development cycle. ( http://bugzilla.gnome.org/show_bug.cgi?id=140165 )

I have added some comments to that bug report that you and everyone else who's asking for pluggable paint tools should read. Before any effort is spent to build a framework to allow for pluggable paint tools, I would want you to understand how easily you can add a new paint tool to the GIMP core. We have put a lot of effort into cleaning up this code to the point where it becomes trivial to experiment with new ideas for paint tools. Exporting this API to some sort of plug-ins or modules would not be impossible but it would be a major effort. Before this is even considered, I would want to see someone working on a new paint tool in the core. Before that didn't happen, I do not believe that there is serious interest in pluggable paint tools.

Seriously, if you have an idea for a new paint tool, tell us about it. With a little help from me and Mitch you or anyone else should have the new paint tool added to the GIMP core in less than a day.

Sven

---------- Forwarded message ---------- From: Laxminarayan Kamath
Date: Mon, 22 Nov 2004 23:41:01 -0800 Subject: Re: [Gimp-developer] Re: whishes for Gimp To: Sven Neumann

On Tue, 23 Nov 2004 00:32:23 +0100, Sven Neumann wrote:

Hi,
......................
Seriously, if you have an idea for a new paint tool, tell us about it. With a little help from me and Mitch you or anyone else should have the new paint tool added to the GIMP core in less than a day. Sven

I would like an "interpolate brush". wherever you paint, it interpolates from the *REST* of the image or selection what the "brushed" part must look like.
--
Laxminarayan Kamath Ammembal
+91 98450 61385
kamathln@gmail.com
kamathln@rediffmail.com
kamathln@yahoo.com
www.geocities.com/kamathln

On Tuesday 23 November 2004 05:41, Laxminarayan Kamath wrote:

---------- Forwarded message ---------- From: Laxminarayan Kamath
Date: Mon, 22 Nov 2004 23:41:01 -0800 Subject: Re: [Gimp-developer] Re: whishes for Gimp To: Sven Neumann

On Tue, 23 Nov 2004 00:32:23 +0100, Sven Neumann

wrote:

Hi,
......................
Seriously, if you have an idea for a new paint tool, tell us about it. With a little help from me and Mitch you or anyone else should have the new paint tool added to the GIMP core in less than a day. Sven

I would like an "interpolate brush". wherever you paint, it interpolates from the *REST* of the image or selection what the "brushed" part must look like.

Oh, I see. You mean like they are requesting here:

http://bugzilla.gnome.org/show_bug.cgi?id=65118

My idea of asking the possibility of a callback brush is that any such impelementation would take lots of parameters. And Huge amounts of trial and error before good results are achieved. And even them, if someone would like to try with other parameters/methods than the hard coded ones , there 'd be a need to rebuild the GIMP.

So, we may think of a compromise - a tool that would read a special type of "brush" files that would contain descriptions of how to paint. It could even contain some procedural descriptions - and have a pool of available parameters - the stroke parameters - which could be used on its computations -
It could use a simple, graphic turtle like vetorial description of mask of the actual brush to use on raster painting, and maybe some other parameters - (different masks for each component color, masks to apply from other drawables (patterns, etc), that would them work as texture maps, maybe special mask type to indicate spreading of the underlying colors)

That would avoid the issue of having to call an external program and still allow flexibility and functionality.

I think we can discuss this idea and get a better idea of what said "procedural brush file" could look like in some more e-mails.

Regards, JS
->

--
Laxminarayan Kamath Ammembal
+91 98450 61385
kamathln@gmail.com
kamathln@rediffmail.com
kamathln@yahoo.com
www.geocities.com/kamathln

Hi,

"Joao S. O. Bueno Calligaris" writes:

My idea of asking the possibility of a callback brush is that any such impelementation would take lots of parameters. And Huge amounts of trial and error before good results are achieved. And even them, if someone would like to try with other parameters/methods than the hard coded ones , there 'd be a need to rebuild the GIMP.

So what? You would have to recompile a single C file and relink. That is in no way different from rebuilding a plug-in or module.

So, we may think of a compromise - a tool that would read a special type of "brush" files that would contain descriptions of how to paint. It could even contain some procedural descriptions - and have a pool of available parameters - the stroke parameters - which could be used on its computations -
It could use a simple, graphic turtle like vetorial description of mask of the actual brush to use on raster painting, and maybe some other parameters - (different masks for each component color, masks to apply from other drawables (patterns, etc), that would them work as texture maps, maybe special mask type to indicate spreading of the underlying colors)

That would avoid the issue of having to call an external program and still allow flexibility and functionality.

I think we can discuss this idea and get a better idea of what said "procedural brush file" could look like in some more e-mails.

You obviously didn't understand me. Adding such an API would be a major undertaking and we are not going to add such a framework for anyone unless that someone has at least built a prototype in the core. I do simply not believe that there is serious interest for developing other paint tools. People toss these ideas (see above) back and forth. If you look at them closely, you notice that they are vague and that the changes that are needed to make them possible are huge.

If you had serious interest for developing other paint tools, you would develop them in the core. There you find a complete and simple framework for developing your ideas. The fact that you don't use it or not even ask about how it can be done, clearly shows that your interest isn't serious. Why should we go through the hassle of adding the framework for pluggable tools then?

Sven

Sven wrote:

You obviously didn't understand me. Adding such an API would be a major undertaking and we are not going to add such a framework for anyone unless that someone has at least built a prototype in the core. I do simply not believe that there is serious interest for developing other paint tools. People toss these ideas (see above) back and forth. If you look at them closely, you notice that they are vague and that the changes that are needed to make them possible are huge.

A few months ago I had the idea of trying to develop a paint tool that would work like the ink tool but would use modules to generate the paint patterns -- this would be a sort of compromise version of a pluggable paint tool. As a step toward this goal, I thought I would try to modify the ink tool so that it would spray paint blobs in a semi-random pattern. This seems like it ought to be pretty straightforward, and in principle I believe it probably is, but a few hours of code study left me completely bewildered. The root problem is that I don't understand the basic philosophy of code organization in GIMP, and without such a framework it is very difficult to understand the function of any given code fragment. And unfortunately these sorts of high-level abstractions are the most difficult things to figure out by reading the source code.

Let me give a specific example. I know by this time, having worked with GIMP for months, that "drawing tools" are tools that make temporary marks on the image display (as opposed to the image itself), and that all such drawing is done in XOR mode so that it can be erased by redrawing. But these very basic facts are not written down anywhere, to the best of my knowledge. And how could anybody unfamiliar with the GIMP code, even being a brilliant programmer knowing everything about C, Glib, Gtk+, etc, make any progress on tool development without understanding them? To derive them from the GimpDrawTool code is by no means straightforward.

And I can tell, just by the feel of the code, that there are many more such basic facts that I haven't yet been able to figure out. If you don't understand the basic principles, all of the code just looks like obfuscated gibberish, no matter how clear and simple the code is in reality.

I might be interested, once 2.2 is out, in taking another shot at this, since you are Mitch are showing so much willingness to be helpful. But it will certainly involve asking a lot of stupid questions.

If you had serious interest for developing other paint tools, you would develop them in the core. There you find a complete and simple framework for developing your ideas. The fact that you don't use it or not even ask about how it can be done, clearly shows that your interest isn't serious. Why should we go through the hassle of adding the framework for pluggable tools then?

There are two rather obvious difficulties in working in the core. First, (and less importantly), each change requires recompiling the main GIMP app, which takes a lot longer than recompiling a plug-in. Second, it means either putting highly speculative code into CVS head or else creating a branch and then facing the challenge of keeping it consistent with head.

Also, it is my impression that coders are often reluctant to ask what seems like very basic questions, because they know how much effort you and Mitch are already putting into GIMP devlopment, and know that basic questions are often the kind that take the most effort to answer.

In my opinion, anyway, the most useful thing you (and Mitch) could do, in terms of encouraging this type of development, would be to write a tutorial showing the steps involved in creating a new painting tool, and explaining the reason for each step.

Best,
-- Bill

______________ ______________ ______________ ______________ Sent via the KillerWebMail system at primate.ucdavis.edu

Hi,

"William Skaggs" writes:

Let me give a specific example. I know by this time, having worked with GIMP for months, that "drawing tools" are tools that make temporary marks on the image display (as opposed to the image itself), and that all such drawing is done in XOR mode so that it can be erased by redrawing. But these very basic facts are not written down anywhere, to the best of my knowledge. And how could anybody unfamiliar with the GIMP code, even being a brilliant programmer knowing everything about C, Glib, Gtk+, etc, make any progress on tool development without understanding them? To derive them from the GimpDrawTool code is by no means straightforward.

If you had a look at the Ink tool you would have noticed that all paint tools are extraordinarily simple. I agree that other tools (those that draw to the display) are a lot more complex but all paint tools are identical except that they register different GimpPaintCore objects. So you don't even need to deal with tools at all (which is admittedly one of the most complex and least cleaned up parts of the Gimp code).

All you need to do is to derive a new GimpPaintCore, either directly from GimpPaintCore or (in case you want to make use of brushes) from GimpBrushCore. This is all nicely abstracted in the app/paint folder and you basically don't need to worry about anything outside this directory. All you need to do is to implement a couple of methods. Just take an existing paint core as an example to copy from.

There are two rather obvious difficulties in working in the core. First, (and less importantly), each change requires recompiling the main GIMP app, which takes a lot longer than recompiling a plug-in.

Huh? You don't need to recompile the whole thing. Of course that would take a lot of time but if you are working on a single C file, that argument is void.

Second, it means either putting highly speculative code into CVS head or else creating a branch and then facing the challenge of keeping it consistent with head.

That is void as well. A paint core is easy enough to be understood quite easily and since the code is in a single file, there is no risk at all that such problems could arise.

Also, it is my impression that coders are often reluctant to ask what seems like very basic questions, because they know how much effort you and Mitch are already putting into GIMP devlopment, and know that basic questions are often the kind that take the most effort to answer.

Well, that is, please excuse me, very stupid. We aren't putting our free time into cleaning up the code for ourselves only. We would love to see more people working on the core and I would very much appreciate if you could stop spreading this FUD that hacking the core would be something that only experts could consider to do.

In my opinion, anyway, the most useful thing you (and Mitch) could do, in terms of encouraging this type of development, would be to write a tutorial showing the steps involved in creating a new painting tool, and explaining the reason for each step.

There are a couple of paint tools in the core. I don't see how we could document this any better than by example. I've offered a helping hand for anyone who wants to work on new paint tools but I am certainly not going to waste the very few free time that I have by writing tutorials.

Sven

Sven Neumann wrote:

[...]

Also, it is my impression that coders are often reluctant to ask what seems like very basic questions, because they know how much effort you and Mitch are already putting into GIMP devlopment, and know that basic questions are often the kind that take the most effort to answer.

Well, that is, please excuse me, very stupid. We aren't putting our free time into cleaning up the code for ourselves only. We would love to see more people working on the core and I would very much appreciate if you could stop spreading this FUD that hacking the core would be something that only experts could consider to do.

I have to back up Sven here.

I am currently trying to get my nose in the code by submitting patches to easy-fix bugs. I asked him and other developers very stupid questions and they always have answered nicely and helpfully. It is quite obvious that they will help people trying to hack the core, as these very people can become Gimp developers later, and giving them some answers when they are stuck is far more productive than doing it for them. It took them between 15 seconds and 3 minutes to answer each of my stupid questions, which is far less than the time required to build a tutorial. And above all, trying to make my way into the code before giving up and shamefully asking those questions, made me understand the Gimp code a bit more each time, which you cannot achieve if you only follow a tutorial written for you.

The Gimp developers took the time to add 'easy-fix' keyword to some bugs. This can be seen as a waste of time as they could fix these themselves in short time, but it would be harder for beginners to help them and they may lose some help offers. What I am trying to tell is : if Sven says it's easy, then it is. Maybe you'll struggle with some parts of the code, but if you try it and ask precise questions when you're lost I am positive you'll get an answer to help you go on.

Granted, this takes some time, but it is no duty and you can do it at your pace (mine is very slow!)

I hope you will give it another try.

Sven wrote:

If you had a look at the Ink tool you would have noticed that all paint tools are extraordinarily simple. I agree that other tools (those that draw to the display) are a lot more complex but all paint tools are identical except that they register different GimpPaintCore objects. So you don't even need to deal with tools at all (which is admittedly one of the most complex and least cleaned up parts of the Gimp code).

All you need to do is to derive a new GimpPaintCore, either directly from GimpPaintCore or (in case you want to make use of brushes) from GimpBrushCore. This is all nicely abstracted in the app/paint folder and you basically don't need to worry about anything outside this directory. All you need to do is to implement a couple of methods. Just take an existing paint core as an example to copy from.

Thank you. This is already very helpful. So in the spirit of trying to figure things out for myself, let me try to figure out how to make a tool register a different GimpPaintCore object.

Let's see -- nothing useful in tools/gimpinktool.c, which as you say is very simple.

So let's look at the code for the parent class, tools/gimppainttool.c. Yes, here it is, line 230:

paint_tool->core = g_object_new (tool->tool_info->paint_info->paint_type, NULL);

A bit daunting, but obviously what I need to do is set the paint_type. So let's figure out where that is done. Grepping for paint_type in the tools directory gives nothing. Grepping in the entire code base gives about a dozen hits -- core/gimppaintinfo.c looks most promising.

Okay, here it is, I think, line 145:

paint_info->paint_type = paint_type;

This is in the code for gimp_paint_info_new(), and paint_type is one of the arguments to the function. So the next step is to figure out where gimp_paint_info_new() is called.

Grepping gives only one hit, fortunately, in paint/gimp-paint.c, line 109:

paint_info = gimp_paint_info_new (gimp, paint_type, paint_options_type, blurb);

This occurs in the code for the function gimp_paint_register(), which is declared static void, so it must be used in gimp-paint.c; let's find it.

Okay, here it is, line 77:

for (i = 0; i < G_N_ELEMENTS (register_funcs); i++) {
register_funcs[i] (gimp, gimp_paint_register); }

This is kind of scary looking, but fortunately the array register_funcs[] is created directly above, and I see that one of its entries is gimp_ink_register. I make a mental note that I will at some point need to add my new tool to this array, and then go on to look for gimp_ink_register().

Okay, here it is, in paint/gimpink.c:

void gimp_ink_register (Gimp *gimp, GimpPaintRegisterCallback callback) {
(* callback) (gimp,
GIMP_TYPE_INK,
GIMP_TYPE_INK_OPTIONS, _("Ink"));
}

So finally I see that paint_type is GIMP_TYPE_INK, which is defined in paint/gimpink.h as:

paint/gimpink.h:#define GIMP_TYPE_INK (gimp_ink_get_type ())

And now I see that to create my new "spew" tool, I need to do the following things:

1) In app/paint, "cp gimpink.c gimpspew.c" and then edit gimpspew.c to s/ink/spew/g (don't take this literally).

2) Handle gimpink.h similarly.

3) in paint/gimp-paint.c, add an include for "gimpspew.h" and add gimp_spew_register to the register_funcs array.

4) in app/tools, copy gimpinktool.c and gimpinktool.h to gimpspewtool.c and gimpspewtool.h, then change "ink" to "spew" everywhere in the new files.

5) in app/tools, handle gimpinkoptions-gui.c and gimpinkoptions-gui.h the same way.

6) Add the new files to Makefile.am in the appropriate places.

7) In tools/gimp-tools.c, add "gimpspewtool.h" as an include, and add gimp_spew_tool_register to the register_funcs array. (I found this by sheer luck.)

8) (The hard part) Edit paint/gimpspew.[ch] and tools/gimpspewoptions-gui.c to give the desired new functionality. The code from gimpink.c is rather complex and will no doubt give rise to more questions.

Does that look right?

No, I see that I haven't created an icon yet. Fortunately I think I more or less know how to do this:

9) Create stock-tool-spew-16.png and stock-tool-spew-22.png and place them in themes/Default/images/tools. As I understand it, the appropriate line in libgimpwidgets/gimpstock.h will be autogenerated if in the themes directory I then do "make -C clean; make".

How about that?

That is void as well. A paint core is easy enough to be understood quite easily and since the code is in a single file, there is no risk at all that such problems could arise.

Well, I think I have demonstrated that I need to create or modify at least 10 files to produce a new paint tool, and I have probably missed something along the way. But I will admit that the danger of code collision does not seem all that large.

There are a couple of paint tools in the core. I don't see how we could document this any better than by example. I've offered a helping hand for anyone who wants to work on new paint tools but I am certainly not going to waste the very few free time that I have by writing tutorials.

That's fine. I think I have more or less assembled one in this email, if it is correct. Once I understand more clearly what needs to be done to alter a file such as gimpink.c, I'll be happy to flesh it out. (And I hope that the first half of this email makes clear the difficulties of working from examples in code where there is a lot of indirection.)

I'll respond to the other points separately; this is already very long.

Best, -- Bill

______________ ______________ ______________ ______________ Sent via the KillerWebMail system at primate.ucdavis.edu

Ok, for those who are wondering,
this is discussion is tied with what I've requested in [Bug 140165] A Paint Tool that allows stroke events to callback plug-in procedures

My initial wriitng in there was:

"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)."

On the latest post in there, Sven wrote: "
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. "
What I want here is to build such a reasonable request - bugzilla doesn't serve as a scratch.

Willian had shown us that:

On Tuesday 23 November 2004 21:15, William Skaggs wrote:

(...)
And now I see that to create my new "spew" tool, I need to do the following things:

1) In app/paint, "cp gimpink.c gimpspew.c" and then edit gimpspew.c to s/ink/spew/g (don't take this literally).

2) Handle gimpink.h similarly.

3) in paint/gimp-paint.c, add an include for "gimpspew.h" and add gimp_spew_register to the register_funcs array.

4) in app/tools, copy gimpinktool.c and gimpinktool.h to gimpspewtool.c and gimpspewtool.h, then change "ink" to "spew" everywhere in the new files.

5) in app/tools, handle gimpinkoptions-gui.c and gimpinkoptions-gui.h the same way.

6) Add the new files to Makefile.am in the appropriate places.

7) In tools/gimp-tools.c, add "gimpspewtool.h" as an include, and add gimp_spew_tool_register to the register_funcs array. (I found this by sheer luck.)

8) (The hard part) Edit paint/gimpspew.[ch] and tools/gimpspewoptions-gui.c to give the desired new functionality. The code from gimpink.c is rather complex and will no doubt give rise to more questions.

Does that look right?

No, I see that I haven't created an icon yet. Fortunately I think I more or less know how to do this:

9) Create stock-tool-spew-16.png and stock-tool-spew-22.png and place them in themes/Default/images/tools. As I understand it, the appropriate line in libgimpwidgets/gimpstock.h will be autogenerated if in the themes directory I then do "make -C clean; make".

What I do want is that one doesn't need to recompile the GIMP for playing with paint variations.

When I first reported I was thinking of being able to write such callbacks in Python language, so that changes on the paint behavior would not require any compiling at all. Moreover, parameters for a painting tool would be added at will - since python plug-ins can combine the ease of script-fu with the power of C plug-ins.

I was pointed that it is technically difficult to write such a callback, since the plug-in runs in a separate process.

So the suggestion taht arised is to have a paint tool that reads what it will do from plain text files. These plain text files will be stored in a collection in their own directory, just like script-fus have one, brushes have one. curves have another.

Each of these plain text files, which I've called "procedural brush" should provide a way to calculate parameters of painting based on other painting variables. Existing variables I can think of right now are: Image coordinates - relative and absolute, painting speed, stroke angle, pressure, tilt, time of stroke event, stroke length, and paint color - and more date to work is available on the pixels that are already on the drawable. (The smudge tool makes use of them, for example).

Such a procedural brush could be able to specify something as trivial as: "the radius of the stroke should vary linearly in the Y direction, being wider at image botton, and 0 at image top." So, a "procedural brush" file describing this could just be something like:

out_radius = in_radius * (in_y / in_height);

So - it would be something fun to try, and skecth. If one would like to make it wider to the left, instead of to the botton, all taht would be needed would be to change taht line to: out_radius = in_radius * (in_x / in_width);

Something obviously with to few serious uses to go into the core as a new tool.
But just the other day one guy was asking for somthing just like that in GUG (hewanted the stroke radius to vary with stroke length).

The same file could specify more parameters, that would be made available for the user to config, just like script fu - The procedural brush could ask for a color gradient, a fixed radius, an starting angle, a pattern or drawable from were to clone data, and so on.

A more complex brush behavior I can think of right now, would be one that'd draw a cycloid curve (a coil) around the cursor position while stroking. The syntax might be something of the type:

#required parameters: (user_spacing, numeric, 1, 100);
(user_radius, numeric, 0, 1000);

out_x = in_x + user_radius + sin (user_spacing * stroke_lenght ); out_y = in_y + user_radius + cos (user_spacing * stroke_lenght ); out_connect_strokes = true;

-------- Please note that this syntax is loose for now - but I think this is a better way of expressing what I have thought of.

I prefer to get more feedback from the list before going on bugzilla. Also, as I stated earlier, I am in no way urging anyone to implement this for me - I intend to work on it with help of whoever wants to, when the idea matures.

Regards, JS
->

Hi,

"William Skaggs" writes:

Well, I think I have demonstrated that I need to create or modify at least 10 files to produce a new paint tool, and I have probably missed something along the way. But I will admit that the danger of code collision does not seem all that large.

Thanks for setting up that list. I am afraid though that you missed the point I was trying to make. There is always about this amount of hazzle to integrate things into GIMP, whether you need to do a couple of registration calls in a plug-in or module or touch a couple of files to register it with GIMP.

It is however very easy for us to help a newbie with this 10 steps you listed than to sit down and design and implement a plug-in API for it. Such an API would have to be flexible enough to deal with all sorts of ideas that people might come up with and so far we have no clue what that could be. So instead of discussing this API, I want people to realize that the code in app/paint already offers an API that should fit their needs. So all they need to do is to ask for a little help with integrating the new paint-core. It is easy for me or Mitch to set up the framework you need to start experimenting. Now that you have explained it in your mail, people would probably not even need this help any longer.

Sven

Sven wrote:

Well, that is, please excuse me, very stupid. We aren't putting our free time into cleaning up the code for ourselves only. We would love to see more people working on the core and I would very much appreciate if you could stop spreading this FUD that hacking the core would be something that only experts could consider to do.

That isn't quite what I have been saying. Some types of hacking on the core are relatively easy, others are very difficult. Rearranging tool options, for example, or changing the anti-aliasing of the ellipse-select tool, are quite straightforward. And some of the difficult things are difficult because they involve fancy mathematics or need to be extremely efficient; there is nothing to complain about in that. The problem is that, in my experience, nearly anything involving the object hierarchy is very difficult because the object interfaces have never been explicitly defined: there is no way to tell what each object class is supposed to be doing except by reading its code and the code of the things that use it -- or by constantly badgering people with questions.

I'm not just making this up, I'm reporting my own repeated experiences. I feel ten times as productive working on plug-ins as working on the core. This isn't because plug-ins are intrinsically easier, it's because the api docs are so wonderful. When I'm doing plug-in hacking, I constantly have the api docs open (for GIMP and Gtk), and spend probably half of my time navigating around in them. When I run into libgimp features that are not documented, I'm nearly as helpless as when working with the core. (For example, the Pixel Fetcher. If I ever needed to use one, I would be screwed.)

Let me again be concrete. Consider the problem of making item displays (brushes, patterns, etc) hierarchical instead of flat -- something that is extremely desirable. In principle it shouldn't be so hard if you understand how to use tree view widgets (which I do, although I don't like them particularly). And in principle the GIMP hierarchical organization should be very helpful, because it means that most of the work can be done in a few places. But in reality it means that only Mitch has any hope of doing it, because it involves making changes in (if I remember correctly) GimpDataFactory, GimpContainerTreeView, and/or GimpContainerEditor, all of whose roles and interactions are undefined, and all of which are inherited by many different things, with no explicit rules for the ways they are used. The result is that any change is a shot in the dark, which will probably break things all over the place.

Now I completely understand how huge a task it is to produce such documentation, and I am not at all trying to cast blame. It's especially burdensome because the most important parts can't be done entirely by volunteers -- an explanation of the purpose of an object class has to come at some point from the person who created it. Instead a more proper attitude is that the excellent documentation for the GIMP libraries is amazingly great -- there is no other open source application with anything comparable. (Libraries and toolkits, yes, but not applications.) But I am annoyed to be told that I am spreading FUD when I am simply saying things that in my experience are true.

Karine Proot wrote:

I have to back up Sven here.

I am currently trying to get my nose in the code by submitting patches to easy-fix bugs. I asked him and other developers very stupid questions and they always have answered nicely and helpfully. It is quite obvious that they will help people trying to hack the core, as these very people can become Gimp developers later, and giving them some answers when they are stuck is far more productive than doing it for them. It took them between 15 seconds and 3 minutes to answer each of my stupid questions, which is far less than the time required to build a tutorial. And above all, trying to make my way into the code before giving up and shamefully asking those questions, made me understand the Gimp code a bit more each time, which you cannot achieve if you only follow a tutorial written for you.

The Gimp developers took the time to add 'easy-fix' keyword to some bugs. This can be seen as a waste of time as they could fix these themselves in short time, but it would be harder for beginners to help them and they may lose some help offers. What I am trying to tell is : if Sven says it's easy, then it is. Maybe you'll struggle with some parts of the code, but if you try it and ask precise questions when you're lost I am positive you'll get an answer to help you go on.

Granted, this takes some time, but it is no duty and you can do it at your pace (mine is very slow!)

I hope you will give it another try.

I understand why you wrote this, because if you haven't followed GIMP development for very long, my email could easily be read as coming from a newbie who took one look at the core and fled in horror, but the fact is that I have written half a dozen plugins, worked on quite a number more, and made a substantial number of contributions to the GIMP core and libraries (mostly pretty minor). Around July I switched from code writing to writing help docs because I thought that was the place of greatest need, and currently I'm too bogged down in other things to do much GIMP-related (other than write way-too-long emails, damn it!), but I'm not going away. Anyway, thanks for your kind response.

Best,
-- Bill

______________ ______________ ______________ ______________ Sent via the KillerWebMail system at primate.ucdavis.edu

Hi,

"Joao S. O. Bueno Calligaris" writes:

When I first reported I was thinking of being able to write such callbacks in Python language, so that changes on the paint behavior would not require any compiling at all. Moreover, parameters for a painting tool would be added at will - since python plug-ins can combine the ease of script-fu with the power of C plug-ins.

I was pointed that it is technically difficult to write such a callback, since the plug-in runs in a separate process.

The different process could become a problem but it isn't necessarily one. The problem is that such a framework needs to be well-defined and needs a lot of effort to setup. A whole lot of more effort than it would be to help a dozen newbies to understand how to do such things in the core. After that has happened, after a few more paint methods have been established in the core, we should have gathered enough experience to get paint-core nodes done right in GEGL. At that point (when GEGL nodes are being used for drawing) one could also consider to allow such nodes to be written in other languages such as Python.

So the suggestion taht arised is to have a paint tool that reads what it will do from plain text files. These plain text files will be stored in a collection in their own directory, just like script-fus have one, brushes have one. curves have another.

Let's see. If I argue that it would be too much hazzle to add a plug-in framework, the alternative solution you come up with is to integrate a text file parser that compiles a procedural brush on the fly? Are you joking or can't you see yourself that this is an order of magnitude more complex and still a lot less flexible than the initial proposal?

Sven

Hi,

"William Skaggs" writes:

I'm not just making this up, I'm reporting my own repeated experiences. I feel ten times as productive working on plug-ins as working on the core. This isn't because plug-ins are intrinsically easier, it's because the api docs are so wonderful. When I'm doing plug-in hacking, I constantly have the api docs open (for GIMP and Gtk), and spend probably half of my time navigating around in them. When I run into libgimp features that are not documented, I'm nearly as helpless as when working with the core. (For example, the Pixel Fetcher. If I ever needed to use one, I would be screwed.)

Perhaps you should start using the code instead of the API docs. I almost never use the API docs, not when working with GIMP, nor with GTK+ or other libraries. I find it a lot easier to read the code than having to rely on API docs that are often incomplete, not detailed enough, sometimes even wrong. Of course I see the usefullness of API docs. We wouldn't have started to generate the API docs for the core if that wasn't the case. But you shouldn't overestimate them. It can take you a lot of trial and error to figure out how an API really works when instead you could have looked at the implementation or some code using the API.

Let me again be concrete. Consider the problem of making item displays (brushes, patterns, etc) hierarchical instead of flat -- something that is extremely desirable. In principle it shouldn't be so hard if you understand how to use tree view widgets (which I do, although I don't like them particularly). And in principle the GIMP hierarchical organization should be very helpful, because it means that most of the work can be done in a few places. But in reality it means that only Mitch has any hope of doing it, because it involves making changes in (if I remember correctly) GimpDataFactory, GimpContainerTreeView, and/or GimpContainerEditor, all of whose roles and interactions are undefined, and all of which are inherited by many different things, with no explicit rules for the ways they are used. The result is that any change is a shot in the dark, which will probably break things all over the place.

Well, let me assure you that it used to be a lot worse. With the current framework it is at least possible to do it (and I hope we can get something like this done for 2.4) while before it has been basically impossible. Only a few changes would be needed to allow nested containers and a lot of the existing can continue to be used w/o any changes. That's the advantage of an object oriented design. On first sight it might add some complexity. For the size of GIMP our object hierarchy is actually pretty flat and in large parts straight-forward. We only use a handful of design patterns.

Sven

On Tuesday 23 November 2004 23:44, Sven Neumann wrote:

Hi,

"Joao S. O. Bueno Calligaris" writes:

So the suggestion taht arised is to have a paint tool that reads what it will do from plain text files. These plain text files will be stored in a collection in their own directory, just like script-fus have one, brushes have one. curves have another.

Let's see. If I argue that it would be too much hazzle to add a plug-in framework, the alternative solution you come up with is to integrate a text file parser that compiles a procedural brush on the fly? Are you joking or can't you see yourself that this is an order of magnitude more complex and still a lot less flexible than the initial proposal?

I was not joking and I can see it is both more complex, and less flexible than the callback suggested.

What made me suggest this is that: 1) It will be all 'enclosed' in the new tool- and require new code that I can at least imagine how could be done. 2) In this way creating a new paint 'effect' will be a lot easier than writting a plugin.

--
Anyway, I think this discussion can rest for a while now. Since you are so willing to help some more people to be able to hack on the core, let's move to a more simple issue - bug #158666. I will write about it on another e-mail.

Regards, JS
->

Sven