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
On Tuesday 23 November 2004 05:41, Laxminarayan Kamath wrote: > -- 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. 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 > [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] autogen.sh on msys
On Mon, Nov 22, 2004 at 08:59:59PM +0100, Michael Natterer wrote: > Hi, > > What version of GIMP is this? > > (assuming this is CVS HEAD, it looks like there is something wrong > with "expr" and the test fails because of that, rather than because of > too old automake). > > What does /bin/sh point to? And also, do you run it as ./autogen.sh or someshell ./autogen.sh I got burnt in similar way (in another project) by using sh instead of bash, for example Edheldil -- GCM/IT d- s:+ a- C++(+++) ULOI$ P++ L+++> E+ W++ N w--- PS+ PE++ Y+ PGP R+ tv- b+++ D+ e+++ y+ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: whishes for Gimp
Hi, "Joao S. O. Bueno Calligaris" <[EMAIL PROTECTED]> 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 ___ 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
Hi, "William Skaggs" <[EMAIL PROTECTED]> 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] autogen.sh on msys
To answer all the questions about my environment, etc. (I tried to post this yesterday, but never saw it, so maybe Juno dropped it or something) Here's what I did: Get and install in this order: from http://gimp-win.sourceforge.net/stable.html GIMP GTK+ from http://mingw.org/download.shtml MINGW MSYS msysDTK Start Msys and create ~/.profile file with the following contents: export DEVELOPMENT_DIR="$HOME/src" export CVSROOT=':pserver:[EMAIL PROTECTED]:/cvs/gnome' export PATH="$DEVELOPMENT_DIR/bin:$DEVELOPMENT_DIR/lib:$PATH" export CFLAGS="$CFLAGS -I$DEVELOPMENT_DIR/include" export CPPFLAGS="$CPPFLAGS -I$DEVELOPMENT_DIR/include" export LDFLAGS="$LDFLAGS -L$DEVELOPMENT_DIR/lib" export ALOCAL_FLAGS="$ALOCAL_FLAGS -I $DEVELOPMENT_DIR/share/alocal" echo Ready to build! Make a folder called ~/src for development and unzip into the ~/src folder so that the contents fall into the same bin, etc, include, share, contrib, lib,... folders: from http://mingw.org/download.shtml msys-libtool-1.5.tar.bz2 msys-automake-1.8.2.tar.bz2 from http://www.gimp.org/~tml/gimp/win32/downloads.html glib-2.4.7.zip glib-dev-2.4.7.zip pkgconfig-0.15.zip [GNU libiconv] libiconv-1.9.1.bin.woe32.zip gettext-runtime-0.13.1.zip gtk+-2.4.13.zip gtk+-dev-2.4.13.zip pango-1.4.1.zip pango-dev-1.4.1.zip atk-1.6.0.zip atk-dev-1.6.0.zip from http://gimp-win.sourceforge.net/stable.html [here] ftp://ftp.arnes.si/software/gimp-win/gimp-dev-2.0.1-20040415.zip from ftp://ftp.zlatkovic.com/pub/libxml/ libxslt-1.1.12.win32.zip libxml2-2.6.15.win32.zip Do the following commands (There is no cvs password) cd src cvs login = 0.17 ... You must have intltool installed to compile The GIMP. Get the latest version from ftp://ftp.gnome.org/pub/GNOME/sources/intltool/ checking for intltool < 0.28 or > 0.31 ... not found checking for xsltproc ... You must have xsltproc installed to compile The GIMP. Get the latest version from ftp://ftp.gnome.org/pub/GNOME/sources/libxslt/ Trying to make xsltproc from the latest sources at ftp://ftp.gnome.org/pub/GNOME/sources/libxslt/libxslt-1.1.12.win32.zip results in the following error message: checking for libxml libraries >= 2.6.15... configure: error: Could not find libxml2 anywhere, check ftp://xmlsoft.org/. The xmlsoft.org site directs you to Igor Zlatkovic's page at http://www.zlatkovic.com/libxml.en.html which in turn directs you to ftp://ftp.zlatkovic.com/pub/libxml/ where you can get libxslt-1.1.12.win32.zip Attempting to run xsltproc.exe, reveals that it needs dll libxml2.dll Get it from the same place. Trying to make intltool from the latest sources at results in the following error message: checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool This seems to be available at http://search.cpan.org/src/COOPERCL/XML-Parser-2.31/Parser.pm but that seems to require another package: http://sourceforge.net/projects/expat/ Instead, get and build version 1.5 of intltool. Trying to run ./autogen.sh results in the following message checking for automake >= 1.6 ... expr: syntax error Too old (found version 1.8.3)! Instead, maybe expr needs to be updated to version __? $ automake --version Can't locate Automake/Struct.pm in @INC (@INC contains: /usr/share/automake-1.8 /usr/lib/perl5/5.6.1/msys /usr/lib/perl5/5.6.1 /usr/lib/perl5/site_perl/5.6.1/msys /usr/lib/perl5/site_perl/5.6.1 /usr/lib/perl5/site_perl .) at /home/ted/src/bin/automake line 47. BEGIN failed--compilation aborted at /home/ted/src/bin/automake line 47. Maybe I need to install something called Struct to perl? I'm keeping a careful record so I can simplify the instructions as much as possible and post them for others to use. I hope that after I finish this, someone should be able to walk up to a new Windows machine, and get things working right away without any surprises. _-T Juno Platinum $9.95. Juno SpeedBand $14.95. Sign up for Juno Today at http://www.juno.com! Look for special offers at Best Buy stores. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: whishes for Gimp
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. ___ 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 t
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 mo
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
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 newbi
Re: [Gimp-developer] Re: whishes for Gimp
Hi, "Joao S. O. Bueno Calligaris" <[EMAIL PROTECTED]> 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: whishes for Gimp
Hi, "William Skaggs" <[EMAIL PROTECTED]> 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: whishes for Gimp
On Tuesday 23 November 2004 23:44, Sven Neumann wrote: > Hi, > > "Joao S. O. Bueno Calligaris" <[EMAIL PROTECTED]> 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Help needed with implementation of up and down arrows on the tools dialog.
Hi,
So, I felt familiar when Will wrote:
> 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.
Because those classes were the ones I became entangled in over the
last weekend, when I tried to do something as simple as put an up and
down arrow on the Tools dialog. (Bug #158666)
I can get to put the buttons, and to pass the ContainerEditor to the
click callback. As I've written on the bug report, I could not find
out, given the editor, what is selected, and it's index. Sven showed
me a function call - gimp_container_get_child_index - to get to the
index once I get what is selected, them a call to
gimp_container_reorder could do the job of going up or down one
place. (I will also need to get the container list's lenght to know
when the selected item is at the bottom).
As far as I was able to see, one have to go through the embeded
GtkTree descendant embeded in the GimpContainerEditor in order to
retireve what is selected.
Will does understand that widget. I do not. When I googled for it, I
got a 100 page pdf just explaining the GtkTreeView.
I tried to get to the selected object by doing:
static void
_gimp_tool_view_editor_move (GtkWidget *widget,
GimpContainerEditor *editor,
gint direction)
{
GimpContainerTreeView *tree_view = editor->view;
GimpContainer *container =
gimp_container_view_get_container (tree_view);
GtkTreeSelection *selection = gtk_tree_view_get_selection
(tree_view);
GList *rows =
gtk_tree_selection_get_selected_rows (
selection,
NULL
);
GimpObject*selected = g_list_nth_data (rows, 0);
I can be on the right track, orway off it - but I need to know if this
is teh way to go.
And...if this is the way to go, might I suggest a method for
retrieving the selection straight from a GimpContainerEditor, without
having to mess with the GimpContainerTreeView?
Thank you everybody.
JS
-><-
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] autogen.sh on msys
Still trying to bring up a development environment on mingw. The problem seems to be automake depending upon Struct.pm but trying to install perl modules fails because it expects ftp to behave, which it doesn't on Windows. Here was the original problem: $ automake --version Can't locate Automake/Struct.pm in @INC (@INC contains: /usr/share/automake-1.8 /usr/lib/perl5/5.6.1/msys /usr/lib/perl5/5.6.1 /usr/lib/perl5/site_perl/5.6.1/msys /usr/lib/perl5/site_perl/5.6.1 /usr/lib/perl5/site_perl .) at /home/ted/src/bin/automake line 47. BEGIN failed--compilation aborted at /home/ted/src/bin/automake line 47. I figure that I need to install something called Struct to perl? I assume it's Class::Struct that I need and not one of Inline::Struct, DynaLib::Struct, Win32::API::Struct, Inline::SLang::Struct, SOAP::Struct, Class::MakeMethods::Template::Struct WDDX::Struct, or some other Struct. trying: perl -MCPAN -e 'install Struct' tries to run ftp, but Windows ftp pops up ftp in another console window, making it obvious that windows ftp doesn't integrate well with msys. What's the simplest workaround? Juno Platinum $9.95. Juno SpeedBand $14.95. Sign up for Juno Today at http://www.juno.com! Look for special offers at Best Buy stores. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] autogen.sh on msys
$ automake --version Can't locate Automake/Struct.pm in @INC (@INC contains: /usr/share/automake-1.8 /usr/lib/perl5/5.6.1/msys /usr/lib/perl5/5.6.1 /usr/lib/perl5/site_perl/5.6.1/msys /usr/lib/perl5/site_perl/5.6.1 /usr/lib/perl5/site_perl .) at /home/ted/src/bin/automake line 47. BEGIN failed--compilation aborted at /home/ted/src/bin/automake line 47. Maybe I need to install something called Struct to perl. I assume it's Class::Struct that I need and not one of Inline::Struct, DynaLib::Struct, Win32::API::Struct, Inline::SLang::Struct, SOAP::Struct, Class::MakeMethods::Template::Struct WDDX::Struct, or some other Struct. trying: perl -MCPAN -e 'install Struct' tries to run ftp, but Windows ftp pops up ftp in another console window where it's obvious that stdio is not being used. There are two ftp programs in /bin, one called /bin/ftp and the other /bin/ftp.exe mv /bin/ftp /bin/ftp.bak solves that problem, but trying perl -MCPAN produces the following message, Please, install Net::FTP as soon as possible. CPAN.pm installs it for you if you just type install Bundle::libnet so the following commands seem appropriate: perl -MCPAN -e 'install Bundle::libnet' perl -MCPAN -e 'install Class::Struct' This gives the following error: The most recent version "0.63" of the module "Class::Struct" comes with the current version of perl (5.8.5). I'll build that only if you ask for something like force install Class::Struct Trying perl -MCPAN -e 'force install Class::Struct' gives the same message. Stuck for the moment. Any ideas? Maybe I don't need this version of automake to build GIMP on mingw? Maybe I should back up and try Cygwin instead? Juno Platinum $9.95. Juno SpeedBand $14.95. Sign up for Juno Today at http://www.juno.com! Look for special offers at Best Buy stores. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
