Re: [Gimp-developer] Force gimp reload plugins?
On Sun, 2009-10-25 at 03:53 +0100, Louise Hoffman wrote: > Is there a quick way to test (my) plugin when I just have compiled it? Once Gimp has been started with the plugin present, you can just replace the executable (make install) and call up the plugin again - Gimp will run the new version. You only need to restart Gimp the first time that you add a new plugin. (As long as the name of the executable and the name of the plugin don't change.) -- David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP plugin for windows
On Mon, 2009-08-17 at 11:48 +0200, Matthias Röttger wrote: > I know, but my colleague told me that this version in incompatible > with the latest GIMP release... I was sent a windows binary for 1.1.9 some time ago, but I haven't been working on DBP lately so I hadn't put it on my site. It is now downloadable at: http://members.ozemail.com.au/~hodsond/dbp-1.1.9-i686.zip Apparently it is compiled against 2.6.4. I cannot vouch for its safety, but I have no reason to suspect that there is anything wrong with it. -- David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Drawing a line in a GIMP plugin
On Sat, 2009-05-30 at 20:47 -0400, Adam C Powell IV wrote:
> I'm sorry, I'm developing a C plugin (tried Scheme first and it was DOG
> slow). Is there a C equivalent? All I'm seeing is
> gimp-paintbrush-register.
Open Gimp
Select Help > Procedure Browser
In the search box, type "brush"
Click on "gimp-context-set-brush"
Read the documentation
In your plugin, add the line:
gboolean result = gimp_context_set_brush("Circle (01)");
Rinse, lather, repeat.
(The hardest part is changing the dashes in the name to underscores.)
--David
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Procedural call to undo?
On Tue, 2009-05-12 at 07:27 -0700, Bill Skaggs wrote: > On Tue, May 12, 2009 at 6:55 AM, peter sikking wrote: > > > > I have big apprehensions that a machine script need to touch the > > users' undo history. I would like to know from David Hodson what > > he is trying to achieve manipulating the undo stack. > > I have some doubts myself about the value of undo in scripts. The case is > much > stronger for plug-ins -- there are lots of them where you could get a cleaner > usage path by allowing users to try something and then undo it within the > plug-in, instead of having to undo in gimp and then run the plug-in over again > for every variation. Bingo. I'm the author of David's Batch Processor, and I use Gimp as an image processing engine for that and various other projects that don't behave the way most plugins do. For something that I'm working on, it would be handy to be able to unwind back to a saved state. A preview window won't help, I want to work on the real image. -- David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Procedural call to undo?
On Mon, 2009-05-11 at 12:57 -0700, Stuart Axon wrote: > Even if you don't have undo as such, it would be useful from a > scripting point of view to save checkpoints, which you could > revert to within the script. Exactly. A more accurate description of what I was looking for would be "mark this point in the undo stack" and "revert to the marked undo point". (With an error code if the undo point no longer exists.) -- David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Procedural call to undo?
Hi David, (OK, that's going to get confusing very fast!) On Sun, 2009-05-10 at 23:39 +0930, David Gowers wrote: > > While it *could* be connected to the API, that would introduce > various logical inconsistencies (for example, plugins could not rely > on having a sensible image state because other plugins (running > concurrently, or called by the plugin itself) might roll back the > image state. Then the user can still make sense of the image state, > but the plugin has no idea what it is, it could be anything. This is > particularly bad if a crash is happening, as it also reduces your > ability to correctly deduce the cause of the crash.) That's true, but how does that make undo different from many other functions? If I have a plugin that attaches to an image and randomly adds or deletes layers, it will also disrupt the worldview of other plugins. I'm not sure that making undo available would change anything. -- David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Procedural call to undo?
On Sun, 2009-05-10 at 22:03 +0930, David Gowers wrote: > On Sun, May 10, 2009 at 9:37 PM, David Hodson wrote: > > I can find the functions in the pdb to manipulate the undo stack - is > > there a function call that just does an "undo"? > > No. > Although this might conceivably change in the future as GIMP integrates GEGL. What does it have to do with GEGL? There's already an undo button there, it just needs to be connected to the API. -- David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Procedural call to undo?
I can find the functions in the pdb to manipulate the undo stack - is there a function call that just does an "undo"? -- David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Brushes/input controllers changes idea
Joern P. Meier wrote: > Maybe adding a new brush type wouldn't be difficult, but actually > implementing a component based "brush synthesizer" (to use David > Hodson's ARP 2500 analogy ;)) might be. > [...] > The real power of such a system would come from combining the predefined > components in ways the developers had never thought of, which means not > just twisting knobs on predefined brushes, but also pushing the > components around on a filter stack and being able to configure which > parameters are affected by the filter (much like in David's proposal). > > But I do understand that this would be quite a huge task (especially > with a GUI to match). That's right, and that's pretty much where I got stalled and ran out of free time to work on it. The first step would be to demonstrate the power of the approach by duplicating (then replacing) all the existing brush types, using fixed filter stacks and fixed control attachments. Then add code to read and write the stack configuration, and it would be easy to add a whole set of fancy brush types just by thinking up new arrangements of filter stacks - you would want these anyway (in libraries, like patterns or gradients), for artists who didn't want to go behind the scenes. You could write a lot of useful code before needing to tackle the editing GUI. -- David Hodson -- this night wounds time ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Brushes/input controllers changes idea
I wrote a proposal to enhance the gimp brush code quite a few years ago, which can still be found here: http://members.ozemail.com.au/~hodsond/gimpbrush.html You might want to see if it contains any useful ideas. -- David Hodson -- this night wounds time ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
Amit Kumar Saha wrote: > The others were about the commercial > products that uses that concept of "glyphs". Though i got a vague idea > of what it was, but more information is desired. Most systems used for creating visual effects for movies are node-based, and have been for over a decade. Look at Nuke (http://www.thefoundry.co.uk/promo/nuke.html) or Shake (http://www.apple.com/shake/) for current examples. -- David Hodson -- this night wounds time ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Problem with perspective transform matrix
Hi Willem, > However, when I use this transformation matrix in my own code, I get > strange results, even using the function gimp_matrix3_transform_point > from gimpmatrix.c. It looks like you are applying the transform in the wrong direction... > To compute a transformed coordinate (x', y') I simply multiply > (x, y, 1) by the transformation matrix that GIMP shows In that case, I think that the transformation converts the destination coordinate to the corresponding source coordinate. -- David Hodson -- this night wounds time ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plugin compilation problems on 64 bit system
Sven Neumann wrote: > Most probably a confusion with the development version. Is he/she trying > to compile against gimp-2.2 or gimp-2.3? Should be all gimp-2.2, AFAIK. I'll ask him to check that everything matches. -- David Hodson -- this night wounds time ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Plugin compilation problems on 64 bit system
I've just received an email from someone who's getting link errors while trying to compile my DBP plugin on the following setup: system Fedora FC6 2.6.20-1.2944.fc6 x86_64 GNU/Linux running gimp 2.2.14 gimp devel is installed The DBP makefile uses "gimptool-2.0 --cflags --libs" to get the compile and link options. His compile line looks plausible: g++ -o dbp -Wall -O2 -I. *.cc -I/usr/include/gimp-2.0 -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12 -L/usr/lib64 -lgimpui-2.0 -lgimpwidgets-2.0 -lgimp-2.0 -lgimpcolor-2.0 -lgimpmath-2.0 -lgimpbase-2.0 -L/lib64 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -DGIMP_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED But gives this error: /usr/lib64/libgimpui-2.0.a(gimpui.o): In function `gimp_ensure_modules': (.text+0x18f): undefined reference to `gimp_module_db_new' /usr/lib64/libgimpui-2.0.a(gimpui.o): In function `gimp_ensure_modules': (.text+0x1a1): undefined reference to `gimp_module_db_set_load_inhibit' /usr/lib64/libgimpui-2.0.a(gimpui.o): In function `gimp_ensure_modules': (.text+0x1b0): undefined reference to `gimp_module_db_load' collect2: ld returned 1 exit status I haven't seen this before, and Google is unhelpful - any thoughts? -- David Hodson -- this night wounds time ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Three point layer distortion mapping feature?
Mark Lowry wrote: > [...] But the stretching function that is > required to help account for variations in lens > distortion due to slightly different image centers > (from hand-holding) is not possible. You might also find this useful: http://members.ozemail.com.au/~hodsond/wideangle.html -- David Hodson -- this night wounds time ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Copy layer betwen images
[EMAIL PROTECTED] wrote: > Quoting David Hodson <[EMAIL PROTECTED]>: >>What is the correct way to copy a layer from one image to another, using >>the API? > (define new-layer (car (gimp-layer-new-from-drawable source-layer > destination-image))) > > (gimp-image-add-layer destination-image new-layer position) Great, that seems to do the trick. Thanks. -- David Hodson -- this night wounds time ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Copy layer betwen images
What is the correct way to copy a layer from one image to another, using the API? -- David Hodson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] how to call gimp procedure from text terminal ?
Joao S. O. Bueno Calligaris wrote: > On Monday 23 April 2007 21:02, stu seven wrote: > >> I know that, using a function name, and parameters, this can >>be done in batch mode, for instance... however, all Im looking for >>is to "remotely" open the function dialog, via the text terminal. > The easiest way I can think of doingthis is writing a python plug-in > that will listen to a socket and execute what you type in there once > you connect to that socket. Also, you can call a gimp function from a plugin, but (AFAIK) you cannot open the function dialog. Your plugin needs to build its own user interface. (There's probably a feature request somewhere for this.) -- David Hodson -- this night wounds time ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] using OpenCV in Gimp?
solotim wrote: > My problem is, is it possible to let Gimp work with a plug-in wrotten by > OpenCV? A Gimp plugin is basically a standalone program, with some standard initialisation code so that Gimp can communicate with it. As long as your program doesn't do anything unusual when it starts up (for example, start an event loop), it can use any libraries that you want. -- David Hodson -- this night wounds time ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preview update problems
Sven Neumann wrote: > You need to move the call to gimp_drawable_preview_draw_region() into > the pixel region processing loop. This is because > gimp_pixel_rgns_process() modifies the pixel regions it works on. The > processed data is also already sent to the core when you are done with > processing. You can't update the preview with that data at this point. That makes sense. I guessed something like that was going on, but it's not obvious exactly where. > If you are using gimp_pixel_rgns_process() you should also remove the > call to gimp_tile_cache_ntiles(). It isn't needed because the data is > processed tile-by-tile. It's OK, I don't have that in my plugin, it's just a remnant from the sample code. Thanks for the help! -- David Hodson -- this night wounds time ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preview update problems
Sven Neumann wrote: > The code snippet you have posted doesn't include the part where you > initialize the pixel regions. It would help if you could post a complete > test case that we can compile and run. OK, I've put it at http://members.ozemail.com.au/~hodsond/myblur5.c It's basically Dave Neary's code with his blur code replaced by something much simpler. At the top of the file, #define WORKING_VERSION as 1 to get his old code, 0 to get mine. (Obviously, search for WORKING_VERSION to see where the difference is.) -- David Hodson -- this night wounds time ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preview update problems
Sven Neumann wrote:
> Have you looked at the code of the many plug-ins that use a preview
> already? The idea of a preview is to preview the effect. So you aren't
> going to manipulate the pixel regions at all. Instead you draw on the
> preview.
I'm looking at Dave Neary's sample code on the developer.gimp.org
website, which uses two pixel regions, calling gimp_pixel_rgn_get_row()
on one and gimp_pixel_rgn_set_row() on the other, and calls
gimp_drawable_preview_draw_region() to update the preview. If I use
gimp_pixel_rgns_process() to access the regions instead, the preview is
not updated with the new data.
> If you have specific question, it's probably best to make up a small
> test case and show us the code together with your question.
Replace the processing loops in Dave's blur() function:
for (ii = -bvals.radius; ii <= bvals.radius; ii++)
{
[...]
gimp_progress_update ((gdouble) i / (gdouble) height);
}
with:
guchar* pr = gimp_pixel_rgns_register(2, &rgn_in, &rgn_out);
for ( ; pr != 0; pr = gimp_pixel_rgns_process(pr)) {
guchar* src = rgn_in.data;
guchar* dst = rgn_out.data;
for (i = 0; i < rgn_in.h; ++i) {
guchar* s = src;
guchar* d = dst;
for (ii = 0; ii < rgn_in.w; ++ii) {
d[0] = 255 - s[0];
s += rgn_in.bpp;
d += rgn_out.bpp;
}
src += rgn_in.rowstride;
dst += rgn_out.rowstride;
}
}
--
David Hodson -- this night wounds time
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] preview update problems
I'm having problems adding a preview (gimp_drawable_preview_new) to an existing plugin. Some experimentation with the sample code shows that using gimp_pixel_rgn_get_row() and gimp_pixel_rgn_set_row() to iterate through the image region, the preview updates correctly, but replacing them with gimp_pixel_rgns_register() and gimp_pixel_rgns_process() stops the preview updating. Why is this, and how do I cause a preview update? -- David Hodson -- this night wounds time ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Idea for data flow in gimp and or plug-ins
Dov Grobgeld wrote: [...] I believe that creating a canvas containing effect boxes and connecting wires through which images and parameters would flow, would be an easier interface to comprehend. Most movie visual effects (compositing) programs work in exactly that way. It's very effective for working with image sequences - you can keep adjusting the parameters (and adding new nodes) until the result is perfect. -- David Hodson -- this night wounds time ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] lense distortion plugin
Alexandre Prokoudine wrote: wideangle.c: In function 'readPresetFile': wideangle.c:953: warning: pointer targets in assignment differ in signedness wideangle.c:954: warning: pointer targets in passing argument 1 of 'fopen' differ in signedness [...] etc. I haven't seen those before - what version of gcc are you running? In any case, they're just warnings, so it should still compile and install. -- David Hodson -- this night wounds time ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] C++ wrapper?
Jay Cox wrote: If anyone was interested I would be happy to share what I have. I'd like to see it, although I won't promise to do anything with it. Can you put it up somewhere? -- David Hodson -- this night wounds time ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] C++ wrapper?
An idle query: Has anyone written a C++ wrapper for the Gimp API? -- David Hodson -- this night wounds time ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Integrated Scripting
Sven Neumann wrote: Good idea, but please move the two new menus out of the toolbox. I'd like the toolbox menu to go away completely. If we can get rid of Xtns, we are almost there. FWIW, I have two plugins that plonk themselves in the Xtns menu, so if it goes, they'll need somewhere to live. Both of them create dialogs that are not attached to any particular image. * DBP (David's Batch Processor) - loads its own list of files, and processes them all. * File Sequencer - allows the user to select any loaded image, and if the filename contains a number, save the current image and load the next (or previously) numbered image into the same window with a single button press. -- David Hodson -- this night wounds time ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] artistic GIMP
Carol Spears wrote: Leon Brooks wrote: [...] http://members.ozemail.com.au/~hodsond/gimpbrush.html i am curious if this could do the work: http://pippin.gimp.org/image_processing/index.html No. If you read the link, you'll see that it's talking about processing the brush parameters, not the image pixels. -- David Hodson -- this night wounds time ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] artistic GIMP
Leon Brooks wrote: It also acknowledges The GIMP for inspiration (yay!) and points to this: http://members.ozemail.com.au/~hodsond/gimpbrush.html Sadly, I've lost the prototype code that I wrote (although it shouldn't be too hard to rewrite). The tricky part is building a user interface that makes the whole thing usable. -- David Hodson -- this night wounds time ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] optional scaling in the save dialog?
Sven Neumann wrote: Gerhard GauÃling <[EMAIL PROTECTED]> writes: In batch processing one can select an action (i.e. gimp-script), a folder for loading the files for processing and one for saving them, and in which kind the naming is to be managed, and so on. [...] I think this is something that can be developed completely independently as a GIMP plug-in. And sure, I am waiting for someone to write this for several years already. That's pretty much what David's Batch Processor does, except that is uses a fixed gui to control a number of common ops, instead of requiring a script to perform general ops. http://members.ozemail.com.au/~hodsond/dbp.html -- David Hodson -- this night wounds time ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] winners movie
William Skaggs wrote: Well, there you go. Those movies were created at a time when movie projectors ran slower, so they weren't designed to play as quickly as they are usually shown nowadays. Totally off-topic, but one of the strangest things I ever read was an early technical discussion in the SMPTE Journal about what speed movies should be projected at. Note that they had already decided what speed to film at - the question was how much faster the playback should be. For some reason, making them the same didn't seem to be an option. -- David Hodson -- this night wounds time ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Image reference count problem in plugin
Michael Natterer wrote: Sven Neumann <[EMAIL PROTECTED]> writes: Here's the example you gave: gint newImage = gimp_file_load (...); gimp_displays_reconnect (oldImage, newImage); gimp_image_delete (oldImage); That last line is wrong since you never owned a reference on that image and it is already gone at that point. It should read instead: gint newImage = gimp_file_load (...); gimp_displays_reconnect (oldImage, newImage); gimp_image_delete (newImage); It's impossible to call gimp_image_delete() on an image which has a display, so both above pieces of code won't work. and in fact this is impossible to get right with the current implementation of gimp_displays_reconnect(). (Note: I haven't updated to 2.2pre yet, I'm still running 2.0.3.) In fact, if I remove the gimp_image_delete(oldImage), then the old image does not get removed when the display is reconnected. If anyone wants to investigate further, the code is at: http://members.ozemail.com.au/~hodsond/fileSeq.html -- David Hodson -- this night wounds time ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Image reference count problem in plugin
I've got a plugin that attaches to an existing (displayed) image, and replaces it with a different image: gint newImage = gimp_file_load(...); gimp_displays_reconnect(oldImage, newImage); gimp_image_delete(oldImage); Problem is that (I think) the new image now has two references, so when the user closes the image display the image is not deleted. If that's right, is there any way to remove the extra reference? If not, what's going on? -- David Hodson -- this night wounds time ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preparing GIMP 2.2
Joseph Heled wrote: I would argue that non interactive plugins (or interactive plugin run in non interactive mode, which I presume to be the same thing), should not bring up any progress bars. In my case, I have a batch processing plugin that sets up a sequence of operations interactively, then performs them on a collection of images. So my plugin UI is available to display the progress from each operation, as long as I can grab the progress callbacks from the gimp functions that I'm calling. -- David Hodson -- this night wounds time ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preparing GIMP 2.2
Sven Neumann wrote: The progress bar should then be part of the plug-in dialog that calls these functions. OK, of course, should have seen that. Gotcha. (I'm sick today, so my brain isn't working properly.) -- David Hodson -- this night wounds time ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preparing GIMP 2.2
Sven, Something that I'd like to see (if it hasn't been done yet) is to make the popup progress dialog dockable. How feasible is that? Well, we don't want to make it dockable, it should be embedded in the associated dialog. Yes, that should definitely be on the list for 2.2. What if there's no associated dialog? I have some plugins that call (lots of) Gimp functions non-interactively, with no image display. The result is that the progress dialog is constantly being created and destroyed. Things would be much neater if it was (optionally?) just part of the main toolbox window. -- David Hodson -- this night wounds time ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preparing GIMP 2.2
Sven Neumann wrote: I think it's about time to start to discuss what features we still want to get into GIMP 2.2. Something that I'd like to see (if it hasn't been done yet) is to make the popup progress dialog dockable. How feasible is that? -- David Hodson -- this night wounds time ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
This is going back a bit... Sven Neumann wrote: I suggested that we make a list of changes for 2.2, so I sat down and tried to come up with such a list. [...] - option to edit files from cmd line sequentially http://bugzilla.gnome.org/show_bug.cgi?id=110242 I've thrown together a plugin which might satisfy the original feature request. It probably needs some refinement, but it's interesting that this can be done as a plugin rather than needing any core code changes. It's at: http://members.ozemail.com.au/~hodsond/fileSeq.html Comments are welcome. I haven't actually done much testing, but it seems to work OK. There's also a small bug in that the plugin keeps a stray reference to the last image used - how do I get rid of that? -- David Hodson -- this night wounds time ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP preview widget (was tentative 2.2 feature list)
Sven Neumann wrote: > So you are seeing the GimpPreview as just a widget that plug-ins can > draw on. However our goal is to provide a way to add a preview to > plug-ins basically w/o changing their code. The change should be > limited to the plug-in dialog and a few hooks here and there. I thought I'd repeat this, because it's a major design constraint. (Also, a very good idea.) I think it's clear that some plugins (e.g. sharpen, noise removal) will require a small, unzoomed region of the image to judge the effect, while others (e.g. whirl, colourise) require a small version of the entire image. For the first group: if the plugin uses gimp_drawable_mask_bounds correctly, then it should work correctly if the preview reports only a small masked area. For the second group: if the plugin is scale-independent, then it should work correctly if the preview reports a small image. -- David Hodson -- this night wounds time ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Updated roadmap (so people don't laugh at the old one)
Sven Neumann wrote: Comments off-list don't count. If people want to comment on this subject, they should do it on the list. Everything else is just noise. Maybe they should, but that doesn't mean that they will. It's a lot easier to drop an email to the person that you agree with, than to jump into a heated discussion. And maybe a simple agreement doesn't need to be read by the whole list. For the record, I think that there's a middle ground. I understand that people don't want an explicit timetable, and that the Gimp development shouldn't be driven by deadlines. On the other hand, if there was indeed a general agreement about the timing of the next release, the original email very effectively pointed out the implications of that choice. (And I don't think that this added much to the discussion.) -- David Hodson -- this night wounds time ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Possible 2.0 pre bug
Dave Neary wrote: > David Hodson wrote: >> I don't have pre2, but in my (1.3.23, I think) version, the >> general Convolution Matrix filter seems broken. > I just checked here on Windows, and it seems that way. Sorry about the vague report, my brain must have been on holiday. What I should have written was: on Linux 1.3.23, pressing OK or Cancel on the Convolution Matrix filter does nothing, and the dialog does not disappear. However, I just checked on Linux 2.0pre1, and it seems to be fixed there. Which Windows version are you looking at? -- David Hodson -- this night wounds time ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Possible 2.0 pre bug
Hi, I don't have pre2, but in my (1.3.23, I think) version, the general Convolution Matrix filter seems broken. Is this still broken in the latest? (If so, I'll try to fix it - seems simple.) I couldn't find anything in Bugzilla. -- David Hodson -- this night wounds time ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] David's Batch Processor release for Gimp 1.3
I wrote: I finally got around to installing Gimp 1.3 and making the necessary changes to DBP, a batch processing plugin for Gimp. The 1.3-compatible version is now available from: http://members.ozemail.com.au/~hodsond/dbp.html It should now work with Gimp 1.3.23 (oops). -- David Hodson -- this night wounds time ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] David's Batch Processor release for Gimp 1.3
Hi, I finally got around to installing Gimp 1.3 and making the necessary changes to DBP, a batch processing plugin for Gimp. The 1.3-compatible version is now available from: http://members.ozemail.com.au/~hodsond/dbp.html Let me know if there are any problems. -- David Hodson -- this night wounds time ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] How do I get a plugin into the offical release?
Carol Spears wrote: http://wiki.gimp.org/ is a nice holding place until the other > stuff gets ironed out, imo. OK, I've put DBP up there because I think it's the most useful. I might add some others later. Let me know (or, I guess, just edit it) if I've done something horribly wrong. -- David Hodson -- this night wounds time ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] How do I get a plugin into the offical release?
David Neary wrote: I'm not sure the plug-in registry likes anyone :) Who *is* responsible for maintaining it? Ingo is listed as the contact, and his email address is there. I did get a reply from him when I was having problems (in May this year), but we couldn't solve them. (Or maybe I lost interest.) (BTW, sorry I replied to you instead of the list.) -- David Hodson -- this night wounds time ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] How do I get a plugin into the offical release?
I've got a bunch of plugins on my website, a couple of which are reasonably stable and mature. (OK, so they're built against 1.2 at the moment.) Who decides on the offical plugin list? For the interested, check out wideangle, degrain, and DBP (and maybe Cineon/DPX, although that's fairly specialised) at: http://members.ozemail.com.au/~hodsond/ -- David Hodson -- this night wounds time ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Plugin registry working?
Is the plugin registry at registry.gimp.org working? I'm trying to register as an author and list some plugins, but I just keep getting asked for name and password info. -- David Hodson -- this night wounds time ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A Free Software project of interest.
Adam D. Moss wrote: unfortunately the back-end is GPL which scuppers any realistic plans of GIMP's own back-end being able to move to it, I think. Eh? This doesn't appear to make sense. -- David Hodson -- this night wounds time ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] layer groups (was: Film Gimp and GIMP)
[EMAIL PROTECTED] wrote: I've been toying with the idea to create a small program that is built entirely of plug-ins and allows you to build graphs of dataflow between inputs and outputs of the plug-ins (nodes in the graph). This is exactly what Gimpeon does. It's a Gimp plugin, lets you build a graph (well, actually a line, since I don't have any multi-input nodes yet) of processing nodes, animate parameters over time, display multiple points in the graph, update them as you adjust parameters, and apply the processing graph (line) to a sequence of images. http://www.ozemail.com.au/~hodsond/gimpeon.html It's crashable, but you should be able to get the idea. -- David Hodson -- this night wounds time ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Film Gimp and GIMP
Wow. Sure is hot in here. Some comments, from a gimp _and_ filmgimp developer: I also regret any duplication of effort between the two. However, I'm not personally convinced that merging them is a good idea. My feeling is that Filmgimp should be a tool specifically (or at least, primarily) for the film industry. It is very likely to develop along lines that are (at best) not useful to, or (quite possibly) totally unwanted by, the more general Gimp community. Remember, a tool that can do everything is seldom the perfect tool for one specific job. I don't think merging Gimp and Filmgimp will necessarily make either set of users happy. Of course, it would be great to build both tools on a single code base. But that's a bigger job than just merging the code, requires a wider range of skills, and (like everything else) is only going to happen if someone wants it badly enough to either do it, or pay someone else to do it. -- David Hodson -- this night wounds time ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] urgent help?
manjunath s wrote: > 1. I've to enable a plugin only when 2 images are > already opened by GIMP, how do i do it? I don't think this is possible. If the plugin is a filter, the filters menu is available from any one image. Extension plugins are available at any time from the main tool menu. > 2. The output of my plugin is another image, Will i > be able to display it together with those 2 already > open images. Yes, the PDB allows you to open image displays. > 3. Finally, how can i get the image path from the > drawable ID(or for that matter, the image opened in > GIMP), that is obtained after opening the image. I think you can do this somehow, but remember that not every image has a file path. (You can create a new image without giving it a location.) > 4. Last but not the least, is the image > representation in GIMP and that of the libarary > IMAGEMAGICK compatible. Is there any way i can get > gimp's representation of the image from the other and > vice versa. Gimp images are tiled arrays of bytes; I'm not sure what ImageMagick uses, but I know that it can use byte or 16 bit pixel channel values. I'm fairly sure you will have to write your own conversion code. Maybe if you told us what you're doing... -- David Hodson -- this night wounds time ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] LSystem plugin, M.Gomulinski
Hi, Someone on c.g.apps.gimp was asking about this old 1.0 plugin, so I quickly patched it to work under 1.2. (The new source is at http://members.ozemail.com.au/~hodsond/lsystem.html). I'm having some trouble contacting the author. Does anybody know anything about him? What's the situation with abandoned plugins, anyway? -- David Hodson -- this night wounds time ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Planned breakage in plug-in API and PDB for 1.3.x or 2.x
Raphael Quinet wrote: > [...] Here is a summary of the changes [...] I may have missed some of the discussion on these, but here are some comments. > - Use the PDB for all interactive tools. All actions that can be >performed by clicking somewhere in the image window (painting, >selecting, picking a color, moving guides, panning, zooming, ...) >must be able to trigger a PDB call. To avoid horrible amounts of overhead, I'm guessing that it should be enough (in most cases) to trigger on button up, and send a vector of cursor positions. >From the other side, can users define their own interactive tools? (How do they get added to the toolbox?) > - Use named parameters for the PDB. Instead of using positional >parameters, all PDB calls could take a list of name=value pairs, in >which each name is a string. Would it be too much work to provide a separate call interface for this style, and keep the old interface? > Did I forget anything that will or may have an impact on the plug-ins? I've built a few plugins that call back into the Gimp, which leads to some (maybe) unusual requests: - Allow plugins to intercept the progress callback (and replace the progress indicator). - Allow (force?) plugins to provide default values and valid ranges for parameters. (And for floats, precision / number of decimals). - I'm thinking about some applications in which I would like to be able to open a display and restrict what users can do on that display, but at this stage I'm still a little vague on this. Maybe if they couldn't change tools on that display ... I'll have to think about this. -- David Hodson -- this night wounds time ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Module or plug-in for embedded control of GIMP?
Michael Terry wrote: > If I could access the image manipulation functions through a plug-in that > remained resident, that would work, but a plug-in is unloaded once its > method (whether query or run) is finished (if I understand correctly). I've done a couple of things like this. The simpler is a system for doing some common batch processing of images. Try looking at http://members.ozemail.com.au/~hodsond/dbp.html for the code. It requests lots of operations from the Gimp. Note that it processes the images and returns once the OK button is pressed - if you don't call gtk_main_quit() (or whatever it is), your plugin keeps going. -- David Hodson -- this night wounds time ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Simple batch processing
I've just (95%) finished a plugin that does simple batch processing - in particular, it allows you to resize and colour a whole bunch of images. I'm hoping that this will save some people from having to learn ImageMagick for simple batch jobs. If some developers would like to test it before I announce it on the Gimp-Users list, it's at http://members.ozemail.com.au/~hodsond/dbp.html Comments welcome. -- David Hodson -- this night wounds time ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] File extensions from PDB?
Is it possible for a plugin to determine what file extensions can be loaded by Gimp? I can get the file load routines easily enough, but is there any way to determine what extensions they handle? -- David Hodson -- [EMAIL PROTECTED] -- this night wounds time ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
