Fwd: [Gimp-developer] Re: whishes for Gimp
-- Forwarded message -- From: Laxminarayan Kamath [EMAIL PROTECTED] Date: Mon, 22 Nov 2004 23:41:01 -0800 Subject: Re: [Gimp-developer] Re: whishes for Gimp To: Sven Neumann [EMAIL PROTECTED] On Tue, 23 Nov 2004 00:32:23 +0100, Sven Neumann [EMAIL PROTECTED] 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 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] www.geocities.com/kamathln -- Laxminarayan Kamath Ammembal MithraKoota, Bhoja Rao Lane, Mangalore 575003 (+91) 9845 061385 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] www.geocities.com/kamathln ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: whishes for Gimp
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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: whishes for Gimp
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
Re: [Gimp-developer] Re: whishes for Gimp
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
Re: [Gimp-developer] Re: whishes for Gimp
Hi, William Skaggs [EMAIL PROTECTED] 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: whishes for Gimp
On Sunday 21 November 2004 09:29, Juhana Sadeharju wrote: From:Alan Horkan [EMAIL PROTECTED] 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: whishes for Gimp
From: Sven Neumann [EMAIL PROTECTED] 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. Solution 2: toolbox (and menues) could be built with a simple builder application. User could build the toolbox, name it, and save to file. Depending of the project, user could choose a suitable toolbox. The second solution would be better because no toolbox nor menues would be cluttered. The builder could be a tree list (perhaps later following the tool plugin directory hierarchy when the tool plugin system has been implemented). Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: whishes for Gimp
On Thu, 18 Nov 2004, Juhana Sadeharju wrote: Date: Thu, 18 Nov 2004 13:21:49 +0200 From: Juhana Sadeharju [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Gimp-developer] Re: whishes for Gimp From: Sven Neumann [EMAIL PROTECTED] 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: whishes for Gimp
Hi, Juhana Sadeharju [EMAIL PROTECTED] writes: It would be a good idea to have specialized crop tools. Alternatives are always good. Doing the thing with separate tools is just a waste of time and is not ergonomic at all. Adding more tools has the disadvantage of cluttering the toolbox. Is there such a plugin system which could be used to implement alternative crop, path, etc. tools? No, there's no infrastructure for pluggable tools. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
