Re: [Gimp-developer] gimp_image_parasite_find, GimpImage, and metadata
Also I should have pointed you to the documentation at: http://developer.gimp.org/api/2.0/libgimp/libgimp-gimpimage.html#gimp-image-parasite-find -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp_image_parasite_find, GimpImage, and metadata
On Sat, Feb 12, 2011 at 12:01 AM, Ulysses Levy wrote: > I'm poking around plug-ins/metadata/metadata.c and I want to get > gimp_image_parasite_find (image_ID, METADATA_PARASITE) to work. > > I'm pretty sure gimp_image_parasite_find expects a parameter of type > GimpImage, so I guess what I'm really asking for is the correct API to get > the current GimpImage from a plug-in. > > No, image_ID is simply an integer. Core structures such as GimpImage do not get passed to plug-ins, so plug-ins can't make use of them. Instead things like images, layers, etc are represented by integer labels. (Formally, by values of type GIMP_PDB_IMAGE, GIMP_PDB_LAYER, etc, but in fact those are just integers.) The value of the image_ID is actually available as one of the params of the "run" function -- you should be able to figure out the standard way to access it by glancing at a couple of existing plug-ins. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
On Sat, 2011-02-12 at 18:31 -0500, Liam R E Quin wrote: > On Sun, 2011-02-13 at 01:04 +0200, LightningIsMyName wrote: > > a couple of comments > > > Make menus searchable > > > > ... i.e. have a textbox, in te menu for example, and anything typed > > will be matched against all menu items and their blurbs and maybe > > something more (like procedures not registered in menus). > > I still think the right way to do this is to have all the menus > constructed through scripting, or at least to have ways to override and > inspect all the menus from scripting. The menus are defined in XML files which bind code-defined actions to menu items. This stuff if fully introspectable and an experienced GIMP coder can hack up a usable menu search in one day. Hardly a GSoC project that would keep a new GIMP hacker busy for longer than two weeks. Tumbs down from here. As to creating menus by scripting, I really don't see what would be the purpose of that. The way we construct menus is completely to GTK+ standards, with some GIMP specific additions. Overriding menus from scripts feels like over-configurability to me and hardly like a way to foster usability. ciao, --mitch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
On Sun, 2011-02-13 at 01:04 +0200, LightningIsMyName wrote: a couple of comments > Make menus searchable > > ... i.e. have a textbox, in te menu for example, and anything typed > will be matched against all menu items and their blurbs and maybe > something more (like procedures not registered in menus). I still think the right way to do this is to have all the menus constructed through scripting, or at least to have ways to override and inspect all the menus from scripting. > Implement the free transform tool > > For exact specifications, see: > http://gui.gimp.org/index.php/Transformation_tool_specification > > (may be offline at the moment) It had better not be :-) Let me know if there are problems with it. [...] > -- > Porting GIMP plugins to GEGL operations Implementing a compatibility framework to run older plugins and scripts once gegl is in place might be the best way to go here. Think of all those scripts on the gimp.org Web site... > Adaptive Image Cloning (aka Semaless Cloning) Sounds interesting. I'd add maybe Macro recording (actions), possibly with pop-up dialogue boxes to ask for values; Font selection using tags (preferably compatibly with fontmatrix and inkscape at least) Undo/redo/"again" Integrate vector layers with gegl Better HDR support - e.g. aligning layers, (I think there may be patents on the various hugin algorithms for combining images though) Fractal image upscaling (required by many stock agencies these days) PhotoShop CS6 :-) import/export But right now, some of the most important areas are (1) single window mode design and implementation and subsequent redesign :-) (2) ability to do at least basic > 8bit-per-channel processing, preferably using gegl (3) user interface design for everything else -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
I'm starting this thread to list ideas for Google Summer of Code 2011, for the GIMP project. Since in the last year collecting ideas was done partially by the mailing list, let's try it again this year and keep most ideas here. One should aslo take a look at GEGL's page about contributing (too bad GIMP doesn't have something like that): http://gegl.org/contribute.html Here is a list of ideas from 2010, that are still not implemented, and *may* be relevant. -- -- JavaScript scripting in the core and/or plug-ins - using GNOME Java Script infrastructure (GJS) GIMP scripts and plug-ins can be written in Scheme, Perl, Python and C. Scheme is always available, but limited in its application in regard on image manipulation. Additionally, as a list-processing language, it may appear as weird to most users. Its main purpose is scripting workflows for repetitive work. The Perl binding is currently the least supported one and not available on platforms other than Unix. The Python binding and the C libraries are current the most powerful ones. Javascript could take over Scheme's role as the genreral purpose scripting language for GIMP. [Note]: At least for scheme, there are no debuggers for scripting in GIMP, and only tracing is supported. It would be neat if as a part of this project, a javascript debugger will be integrated so scripts could be debugged in a sane way. Again, this is not a part of the original project suggestion (as suggested last year), but this is something that could be helpful. -- -- Make menus searchable ... i.e. have a textbox, in te menu for example, and anything typed will be matched against all menu items and their blurbs and maybe something more (like procedures not registered in menus). -- -- Implement the free transform tool For exact specifications, see: http://gui.gimp.org/index.php/Transformation_tool_specification (may be offline at the moment) -- -- Replace the GimpSizeEntry widget Right now both the code and the UI is a mess. The unit should for example be in the text entry itself instead of in a combo box -- -- Brush selector wigdet More precisely one that is also capable for brush transform input (size/angle/aspect ratio). -- -- Slicing tool One of the most requested features by web designers and/or interface designers, is the addition of a slice tool. Currently slicing images inside GIMP can only be done in grids (using guides and the guillotine action) and you can't split just one rectangle in the middle. For example, the following slice can not be achieved: --- ||| ||| ||| ||| -|| ||| --- -- -- Porting GIMP plugins to GEGL operations There are many many GIMP plugins that would need eventually to be converted to GEGL operations, if we want to use them in future versions of GIMP. Now, I'll throw in a first idea myself: -- -- Adaptive Image Cloning (aka Semaless Cloning) Direct cloning of parts from one image to another, usually ends in bad results because of different lighting conditions and other settings (such as white-balance) which causes the color of the cloned part not to match the source image and look out of place. There are some techniques to solve this, by using poisson equations and some other methods. It differes from the existing heal tool, since it is meant for taking one area from an image, and paste it smoothly in some other area. The current algorithm implemented by the healing tool allows to remove local irregularities (such as dots, hairs, etc.) very well, but experiments of using it to do "adaptive cloning" of areas (for example copying a person from one image to the other) do not produce good results. (It should be said that I'm a bit biased torwards this idea, because I want to work on it as a student in GSoC and I already collected papers about it. Still, I'd like a lot to see somthing like this in GIMP, no matter who implements it) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] gimp_image_parasite_find, GimpImage, and metadata
I'm poking around plug-ins/metadata/metadata.c and I want to get gimp_image_parasite_find (image_ID, METADATA_PARASITE) to work. I'm pretty sure gimp_image_parasite_find expects a parameter of type GimpImage, so I guess what I'm really asking for is the correct API to get the current GimpImage from a plug-in. ps - sorry for the newbie question Thanks, -uly ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
