Re: [Gimp-developer] GIMP Roadmap - wiki page
On Tue, Mar 01, 2011 at 04:24:18PM -0600, Chris Mohler wrote: On Tue, Mar 1, 2011 at 3:46 PM, Kevin Cozens ke...@ve3syb.ca wrote: It would be nice (IMO) to have a dockable that displays the numbers of the transform tool's current selection and transform, and also applies numerical input to the transform tool. i asked them to do this for the move tool in gimp-1.2. i don't think that this is such a difficult task as to pay a person to work on it for the summer. GIMP got those stupid expanding tabs with their names for free because (i guess) icons aren't so good for using gui applications after all or was a reason provided for this? carol ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP won't quit
jcup...@gmail.com wrote: As a result of this strange design, it's impossible on Windows to write a .exe that can be used smoothly both from the command-line and from the desktop. I've written a couple of applications that run from the command line and happily throw up windows and interact with the desktop on MSWin (and OS X and Linux). There's nothing special about it - any normal command line main() program with stdin/out/err can create windows by calling CreateWindow(). Graeme Gill. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP won't quit
On 2 March 2011 12:52, Graeme Gill grae...@argyllcms.com wrote: jcup...@gmail.com wrote: As a result of this strange design, it's impossible on Windows to write a .exe that can be used smoothly both from the command-line and from the desktop. I've written a couple of applications that run from the command line and happily throw up windows and interact with the desktop on MSWin (and OS X and Linux). There's nothing special about it - any normal command line main() program with stdin/out/err can create windows by calling CreateWindow(). Yes, but if they are tagged as CLI .exes (which they will be if you can run them from the command-line and the CLI blocks until they exit) when you run them from the Windows shell by double-clicking an icon you will get an annoying extra console window linked to stdin/stdout. John ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Roadmap - wiki page
Martin Nordholts enselic at gmail.com writes: On 03/02/2011 04:33 AM, GSR - FR wrote: Hi, enselic at gmail.com (2011-03-01 at 2214.48 +0100): Thanks, I've added your items as well as mapped features into GIMP releases up to GIMP 3.8. (I implicitly include both 'color adjustment layers' and 'filter layers' under Adjustment layers.): http://gimp-wiki.who.ee/index.php/GIMP_Roadmap Please pick a different name that trully combines both things then, assuming they are combinable. Adjustment layers is already a standard term (de facto from another app, yeah, impossible to change that now) for a layer that only has a mask and applies per pixels changes like hue or level changes. Not only confusing, but hard to see the relation between adjusment and render grid, for example, which is probably what you mean with filter. Thanks. I've changed Adjustment layers to 'Layer filters' for now, and added Layer effects. Ideas for better names are welcomed. That is also an already-used term. Adjustment layers = per-pixel value change (hue, levels, etc - stuff from the colors menu) Such layers have a mask and adjustment properties but no actual color content. Filter layers = real-time application of filters (sharpen, blur, distort) that changes whenever the layers *beneath* it are changed. These are not per-pixel but rely on the entire image. Such layers have a mask and filter properties but no actual color content. These are updated whenever the content odf any of the layers below it is changed. Layer effects - effects that operate on raster layers and affect the content of that layer only, usually around the perimeter of the actual pixel content. Examples - drop shadow, glow, bevel, stroke. These should be updated in real time as the user is drawing on that layer. While all of these are desired, I would say adjustment layers are the easiest to implement and the most important. Layer effects are important for web designers mostly, but less so for casual users, and they seem to be difficult to implement properly (just a guess from seeing adobe's successful implementation and other's less succesful attempts). Filter layers have a low importance. ___ 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 3/2/11, Alexander Rabtchevich wrote: I can remember there was an intention to rewrite iwarp plug-in as a tool... It's doable on top of the gegl op that powers Cage transform tool. That op only :) has to be tought working outside of the cage. Sounds like a good GSoC project to me. Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Roadmap - wiki page
On 3/2/11, Michael Grosberg wrote: Adjustment layers = per-pixel value change (hue, levels, etc - stuff from the colors menu) Such layers have a mask and adjustment properties but no actual color content. Filter layers = real-time application of filters (sharpen, blur, distort) that changes whenever the layers *beneath* it are changed. These are not per-pixel but rely on the entire image. Such layers have a mask and filter properties but no actual color content. These are updated whenever the content odf any of the layers below it is changed. Don't you find this separation between adj layers and filter layers a bit over the top? :) Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Roadmap - wiki page
Martin Nordholts wrote: I've changed Adjustment layers to 'Layer filters' for now, and added Layer effects. Ideas for better names are welcomed. Most of the effect plug-ins are under a Filters menu so using Layer filters makes a certain amount of sense. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Roadmap - wiki page
The term layer effects should be used carefully. PhotoShop uses it for a set of modifications that can be applied nondestructively to a layer, including blurring, color adjustments, and a limited number of other specific things. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Roadmap - wiki page
On Wed, 2011-03-02 at 07:14 +, Michael Grosberg wrote: Chris Mohler cr33dog at gmail.com writes: When you start messing around with perspective transform and you drag corner points every which way, scale and rotate numbers become meaningless. So, Precise numbers are not that useful for a free transform tool anyway. For painting and general creative work you're probably right, but gimp is also used for other things. For example, I often rotate a scanned image, carefully writing down the exact number, and then if it was too little or too much, repeat with a slightly different number. It might work if the transform tools have an option (sorry) to remember the last value, or a list like curves and levels do today. You've got a similar solution in Inkscape, Where the select tool also does Transformations by default with no numerical input, but there is also a dock for transforming objects numerically (there are tabs for separate actions, so each transform command is separate). Or displaying the numbers in tool options in gimp might work. (I worked on a patch to change the numbers shown in Perspective to spin boxes just as in the other transform tools, but (1) lost it in a battle with git recently, and (2) never submitted it as it obviously didn't fit in with The Grand Vision. I wish I could drag guides around while the perspective grid was active!) Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ ___ 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 Tue, Mar 1, 2011 at 1:52 PM, LightningIsMyName lightningismyn...@gmail.com wrote: Hello, The nearly finalised project list for GSoC 2011 is available at the wiki: http://gimp-wiki.who.ee/index.php/Hacking:GSoC_2011/Ideas Users who have a comment on the list should raise it now. The ideas list was divided in to two parts, as discussed on IRC. Developers who wish to make small corrections should feel free to do so, but please do not move projects between the lists / add/remove projects or do any other major change without a discussion first. GIMP on! ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ 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
For some reason my text disappeared when I hit send for the previous message -- sorry! Here is what I wrote: It is very important to make sure that each project in the list has a developer who is prepared to sign up to mentor it. There are two reasons for this. First, because it is a waste of time and effort for students to apply for a project that nobody is prepared to mentor. Second, because I am afraid that some of the proposals are actually ill-conceived, and that will become apparent because no developer will be willing to mentor them in the form as written. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Porting GIMP plugins to GEGL operations
Hello all, 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. Though I'm not a student, I've been meaning to give something back to the Gimp Project for sometime now. The idea above strikes me as a good place to start, though I might be wrong ... am I? :-) If not, I'd need a few pointers to get going: 1) Looking in the GIMP and GEGL dev sites, I found a list of library dependencies for GEGL but not one for GIMP. I haven't downloaded the source yet, so perhaps there's such a list in there. If not, where can I find it? My computer runs a vanilla Ubuntu 10.04 install, should I expect any problems? 2) Are there any special guidelines for writing plugins using GEGL operations? Are they listed anywhere? (Looking at the GIMP dev site I haven't found any). Is there an already ported plugin to use as an example? Or a template? 3) Which plugins should be ported first? Is there a priority list? Is it possible to port all plugins given the current list of GEGL operations? If not, which are possible? 4) Is this a simple porting job or are there any documented desired improvements to be made on the plugins? 5) Where should I go for help when I need it? :-) Though I've worked as a C programmer for several years, I'm a bit rusty after six years of spreadsheets and Gantt charts ... :-) On top of that, I've never done any serious graphics programming (except for a couple of classes back in college, over 15 years ago). So I'll need some time to get up to speed. Hope that's alright. I usually learn faster by working on something concrete, so I'd apreciate if someone could point me to a couple of relevant but not too dificult plugins to start on. Thanks for any help! Andreas Plath ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Porting GIMP plugins to GEGL operations
On Wed, Mar 2, 2011 at 20:03, Andreas Plath apl...@gmail.com wrote: Though I'm not a student, I've been meaning to give something back to the Gimp Project for sometime now. The idea above strikes me as a good place to start, though I might be wrong ... am I? :-) If not, I'd need a few pointers to get going: Nice to see more interested developers. I'm not a developer, but I try to anser your questions as good as possible. Here are some useful informations for Gimp beginner: http://gimp-wiki.who.ee/index.php/Users:Beginner_Developer%27s_FAQ 1) Looking in the GIMP and GEGL dev sites, I found a list of library dependencies for GEGL but not one for GIMP. I haven't downloaded the source yet, so perhaps there's such a list in there. If not, where can I find it? My computer runs a vanilla Ubuntu 10.04 install, should I expect any problems? You should get all needed libs with apt-get build-dep gimp. I'm not sure if 10.04 is recent enough because I'm using 10.10. 2) Are there any special guidelines for writing plugins using GEGL operations? Are they listed anywhere? (Looking at the GIMP dev site I haven't found any). Is there an already ported plugin to use as an example? Or a template? 3) Which plugins should be ported first? Is there a priority list? Is it possible to port all plugins given the current list of GEGL operations? If not, which are possible? 4) Is this a simple porting job or are there any documented desired improvements to be made on the plugins? This should be a good starting page for you: http://gegl.org/contribute.html 5) Where should I go for help when I need it? :-) Go into the IRC channel to get direct feedback from the developers. Or use the GEGL or Gimp mailing lists, but that is slower. Regards, Tobias ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Porting GIMP plugins to GEGL operations
On 3/2/11, Andreas Plath wrote: 1) Looking in the GIMP and GEGL dev sites, I found a list of library dependencies for GEGL but not one for GIMP. I haven't downloaded the source yet, so perhaps there's such a list in there. If not, where can I find it? My computer runs a vanilla Ubuntu 10.04 install, should I expect any problems? 'sudo apt-get build-dep gimp' will get you all dependencies except gtk-doc-tools package 2) Are there any special guidelines for writing plugins using GEGL operations? Are they listed anywhere? (Looking at the GIMP dev site I haven't found any). Is there an already ported plugin to use as an example? Or a template? http://git.gnome.org/browse/gegl/tree/operations/common/motion-blur.c http://git.gnome.org/browse/gegl/tree/operations/common/pixelise.c Not verbatim, but close to original ports: http://git.gnome.org/browse/gegl/tree/operations/common/mirrors.c http://git.gnome.org/browse/gegl/tree/operations/common/grid.c Also note that some filters should become meta-operations which means an operation that simply reuses other operations as building blocks. A good example of one is unsharp mask: http://git.gnome.org/browse/gegl/tree/operations/common/unsharp-mask.c 3) Which plugins should be ported first? Is there a priority list? Is it possible to port all plugins given the current list of GEGL operations? If not, which are possible? There are no priorities set. You will find it most encouraging porting filters you care about most :) 5) Where should I go for help when I need it? :-) On IRC: #gegl at irc.gimp.net Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP won't quit
jcup...@gmail.com wrote: Yes, but if they are tagged as CLI .exes (which they will be if you can run them from the command-line and the CLI blocks until they exit) when you run them from the Windows shell by double-clicking an icon you will get an annoying extra console window linked to stdin/stdout. You can use stdio from a WinMain application if you: AttachConsole(ATTACH_PARENT_PROCESS); freopen(CONOUT$,wb,stdout); etc. so that it runs without a console normally, but uses one if launched from the command line. Graeme Gill. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Porting GIMP plugins to GEGL operations
On Wed, Mar 02, 2011 at 04:03:42PM -0300, Andreas Plath wrote: Hello all, 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. 1) Looking in the GIMP and GEGL dev sites, I found a list of library dependencies for GEGL but not one for GIMP. I haven't downloaded the source yet, so perhaps there's such a list in there. If not, where can I find it? My computer runs a vanilla Ubuntu 10.04 install, should I expect any problems? after opening the downloaded archive, type ./configure and see if this runs successfully and then look at the nicely formated output to see if you need to have other things installed. when configure fails to run, it always tells exactly what it needs to complete its task and you can decide if you want your distribution to install that for you or if you would like to build that for yourself. 2) Are there any special guidelines for writing plugins using GEGL operations? Are they listed anywhere? (Looking at the GIMP dev site I haven't found any). Is there an already ported plugin to use as an example? Or a template? look at the gegl ops. and there is a template available, although, i have not heard of any one other than me mentioning this in a long while -- so consider making your own template. perhaps use a mindset like that you are on new ground and that you would like your contribution to be looked back on with respect. that is just a suggestion, but i think that you are on relatively new ground and it is the safest approach, perhaps. 3) Which plugins should be ported first? Is there a priority list? Is it possible to port all plugins given the current list of GEGL operations? If not, which are possible? a priority list will be made of the priorities of the people who write that list. that seems like a very stupid thing to write, but a bunch of photo- graphers would think that the useful to photographers plugins will make those the greatest priority, for example. the first plugin i tried to use with gimp-3 was pagecurl; is that my priority? it is only the first plugin i tried to use and i tried to use it because of a few qualities it had. some additional gtk+ stuff and oh, the length of time it has been with gimp. it was a priority to me at that moment and because i was trying a new major version for the first time and had become familar with its history. i strongly recommend that you choose your plugin based on your abilities and not on the recommendation of whatever people are making lists right now -- including me. you should like it and you should know what the results are supposed to be. i recommend avoiding blurs and noise, i make this suggestion having read the blurred and noisy history of these plugins and if pressed to provide further explanation for this, i would not be able to provide any so ignore this advice if it suits you to do so. 4) Is this a simple porting job or are there any documented desired improvements to be made on the plugins? is this question redundant? 5) Where should I go for help when I need it? :-) where ever you actually get answers to your questions. Though I've worked as a C programmer for several years, I'm a bit rusty after six years of spreadsheets and Gantt charts ... :-) On top of that, I've never done any serious graphics programming (except for a couple of classes back in college, over 15 years ago). So I'll need some time to get up to speed. Hope that's alright. does this work include any familiarity with gnu build tools? does your C experience require more than just gcc to produce the software that you write? i suspect that this question is worded wrongly. when gimp was being written, the developers then did not even allow c++ comments. but the auto- matic installing of software from the distributions has somewhat diluted this like-minded goal that used to exist. at least i think it is the automatic installing of distribution binaries which did this; consider that to be a theory. for Linux, when a whole group of software (perhaps even up to ten or more dependencies for the more complex softwares like music players/editors, and graphics displayers/editors) when there is just one dependency that requires that another compiler be installed -- it feels like a purpose has been defeated. gimp-1.2 only had a wrong requirement for g++ in its build scripts and that was removed for gimp-2.0. I usually learn faster by working on something concrete, so I'd apreciate if someone could point me to a couple of relevant but not too dificult plugins to start on. the concrete is in your mind. pick something that you will enjoy. if it turns out to be not concrete, then you have learned. my math teacher once told me about the calculus classes (my college split them into 3 semesters). she said that the content of the last class wasn't
[Gimp-developer] Adding a layer mode
Hi, I would like to implement the following layer mode in the GIMP: 1) Transform destination and source pixels to HSL space. 2) Note original destination pixel saturation. 3) Set luminance component of destination pixel to luminance component of source pixel. 4) Transform destination to HSV color space. 5) Set saturation of destination pixel to original saturation of destination pixel. I'm assuming destination is also the result of the operation. Not sure how GIMP handles this, though. The purpose of the mode is to colorize a greyscale image while keeping both the saturation and hue data of the color layer and the luminance data of the greyscale image. Existing modes (as far as I see) unfortunately either mess up the color information or the luminance information. So, the question is, what changes would I need to make to add this layer mode? I would be very grateful for any hints. :) Cheers, Jörn ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Roadmap - wiki page
On Wed, Mar 2, 2011 at 1:14 AM, Michael Grosberg grosberg.mich...@gmail.com wrote: I'm a little uneasy at the moment about the ban working with numbers for transformations comment. It would be nice (IMO) to have a dockable that displays the numbers of the transform tool's current selection and transform, and also applies numerical input to the transform tool. I have a somewhat different solution for this. When you start messing around with perspective transform and you drag corner points every which way, scale and rotate numbers become meaningless. So, Precise numbers are not that useful for a free transform tool anyway. GIMP could simply keep the existing separate transform tools, but instead of displaying them as icons in the toolbox, keep them in their own sub-menu under edit--transform or something. That would cover the uses I was worried about. The dockable I was imagining had the following items: Origin X,Y in pixels Width in pixels Height in pixels Rotation in degrees X shear in pixels or degrees Y shear in pixels or degrees And then some items that would become active only after performing a perspective transform or clicking on them directly: Top-Left X,Y in pixels Top-Right X,Y in pixels Bottom-Left X,Y in pixels Bottom-Right X,Y in pixels I *think* that would cover all of the transformations of the proposed tool. And I assume all or most of those values are going to be in play (and in the undo stack) during use of the transform tool. But yeah, just having the one-off dialogs for transforms would work as well. I have no real preference either way, but the dockable (or placing those items in tool options) seems cleaner to me for some reason. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Adding a layer mode
On Wed, Mar 2, 2011 at 10:00 PM, Jörn P. Meier li...@netgods.de wrote: Hi, I would like to implement the following layer mode in the GIMP: 1) Transform destination and source pixels to HSL space. 2) Note original destination pixel saturation. 3) Set luminance component of destination pixel to luminance component of source pixel. 4) Transform destination to HSV color space. 5) Set saturation of destination pixel to original saturation of destination pixel. I'm assuming destination is also the result of the operation. Not sure how GIMP handles this, though. The purpose of the mode is to colorize a greyscale image while keeping both the saturation and hue data of the color layer and the luminance data of the greyscale image. Existing modes (as far as I see) unfortunately either mess up the color information or the luminance information. Hi John --- regardless of the desired operation, it would be very difficult to stick a new layer operation in GIMP - due to file compatibilities, and everything else. When I first started hacking around the GIMP source code, some years ago, new layer operations also where something that I messed with. But see..even if one doe shave a great idea, and a nice pacth taht wuld be included in the GIMP's source, there would be a problem of compatibility of new XCF images using the new layer mode, and older GIMP versions around. So, while, yes, you could create a new layer mode just to poke around, it would be of little use other than for yourself. (Regardless, it is fun enough, I suggest you try it). If you get a usefull enough result, maybe yu could make a plug-in that would combine two normal layers using the algorithm you describe. You loose all real time niceness, but at least you can achieve your result. (and this plug-in can be passed around to others). As for where to create a layer mode-- there are some files - -I don remember which now -- part of the fun is locating them -- you get to know yoru way around GIMP. You will even find out that there are different code paths to render layers on the source tree. There are all the files on the app/composite directory -- or one can enable GEGL compositing, for which the files are under app/gegl This article can have some usefull hints on how to poke around GIMP' s source: http://www.ibm.com/developerworks/linux/library/os-gimp Regards, js -- So, the question is, what changes would I need to make to add this layer mode? I would be very grateful for any hints. :) Cheers, Jörn ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Adding a layer mode
On 03/03/2011 02:00 AM, Jörn P. Meier wrote: Hi, I would like to implement the following layer mode in the GIMP: 1) Transform destination and source pixels to HSL space. 2) Note original destination pixel saturation. 3) Set luminance component of destination pixel to luminance component of source pixel. 4) Transform destination to HSV color space. 5) Set saturation of destination pixel to original saturation of destination pixel. I'm assuming destination is also the result of the operation. Not sure how GIMP handles this, though. The purpose of the mode is to colorize a greyscale image while keeping both the saturation and hue data of the color layer and the luminance data of the greyscale image. Existing modes (as far as I see) unfortunately either mess up the color information or the luminance information. So, the question is, what changes would I need to make to add this layer mode? I would be very grateful for any hints. :) There is already a patch for that (using the CIELCH space instead), see the most recent patch in https://bugzilla.gnome.org/show_bug.cgi?id=325564 / Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Porting GIMP plugins to GEGL operations
Let me start by noting that although I was once pretty familiar with the Gimp code, I haven't looked at it in a couple of years. That being said, this discussion is not making sense to me. Plug-ins do not access Gimp core functionality directly, they use an interface library known as libgimp. When a plug-in uses libgimp, it sends messages to the core telling the core to execute specified commands. To the best of my knowledge, libgimp does not yet contain an api that would allow plug-ins to directly invoke Gegl operations. What this all means, unless I have missed something, is that there are basically three ways to make plug-ins use Gegl: (1) Reimplement the core functions that libgimp invokes so that they use Gegl operations. (2) Reimplement libgimp so that it invokes Gegl operations. (3) Add a Gegl api to libgimp and rewrite plug-ins so that they use the Gegl api. These are very different approaches from a coding point of view. Approach 1 requires no changes in libgimp or in plug-ins. Approach 2 requires changes in libgimp but not in plug-ins. Only approach 3 requires that plug-ins be rewritten, and before that can be done it requires adding the needed api. I frankly find it hard to believe that approach 3 is the correct way to handle this, but one way or another, it ought to be clarified. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Porting GIMP plugins to GEGL operations
On 03/03/2011 07:21 AM, Bill Skaggs wrote: Let me start by noting that although I was once pretty familiar with the Gimp code, I haven't looked at it in a couple of years. That being said, this discussion is not making sense to me. Plug-ins do not access Gimp core functionality directly, they use an interface library known as libgimp. Hi Bill You got it all wrong: porting GIMP plug-ins to GEGL operations is about exactly that: replacing GIMP plug-ins with GEGL operations. It is not about making libgimp GEGL-aware. Instead of http://git.gnome.org/browse/gimp/tree/plug-ins/common/pixelize.c we want http://git.gnome.org/browse/gegl/tree/operations/common/pixelise.c Best regards, Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
