Hey Marek,

On Mon, Jul 22, 2013 at 3:19 AM, Marek Dvoroznak wrote:

Hello,

I'd like to ask you for an advice. I tried to ask once on IRC but had no luck. But since this is a longer question, mail list is more suitable anyway.

Don't you have a specific point of communication too (a "mentor")? Not that you should not ask here. It's nice to have news, and you can get other point of views too. :-)

I remind that I'm a GSOC student and I work on n-point image deformation GEGL operation and GIMP tool.

I have a static library which can do n-point deformation - it has functions which create mesh, allow to add points on mesh, perform the deformation algorithm etc. The library is bundled with GEGL (in my branch - inside libs/npd). I also have a GEGL operation which use that library and implements necessary graphics functions.

I would like to use that operation in GIMP tool. To be able to effectively communicate with GEGL operation from GIMP I need to share some (especially mesh) data based on structures defined in the library. Is there a good way how to achieve that?

I have looked into the sources of Cage tool and found out that it's defining its GEGL operation inside its sources in GIMP. I could do it similarly, but this way has a drawback - e.g. other graphics programs based on GEGL couldn't use the deformation.

Another way would be to duplicate needed code, but duplication isn't nice. The solution could be to make shared library (bundled with GEGL) instead of static library. What do you think?

I agree that when the operation is generic enough to be useful in various programs, it is better to distribute it along with GEGL. And if Cage tool is not indeed, I guess it should have too. In any case, code duplication should not happen.

Now about your npd library do you plan on distributing it separately from GEGL? Why do you implement it as a separate library instead of including the code directly into the GEGL operation? Basically do you think people would link only your library, or would they always go through GEGL if they want to use your transformation operation? Because if the former, then I would suggest not going through a library layer.

Also as a general thing, if there is a library, the UNIX logics is to prefer it shared than static. But I don't really understand what it changes to your problem here. Actually I am not sure I understand your problem. But I am not the most versed into GEGL either.

Jehan

I'm currently stuck due to this problem. Thanks in advance for helping me.

Marek

_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

On Sun, Jul 21, 2013 at 7:19 PM, Marek Dvoroznak wrote:

I have a static library which can do n-point deformation - it has functions which create mesh, allow to add points on mesh, perform the deformation algorithm etc. The library is bundled with GEGL (in my branch - inside libs/npd). I also have a GEGL operation which use that library and implements necessary graphics functions.

A slightly different approach would fit better with the GEGL architecture, make the mesh object a valid property type with paramspec and all and add it among the others in gegl/property-types/. and use it as part of the input/configuration of an op that contains the actual deformation logic.

Though I believe adding a mesh manipulation API,. and finding an API that would be useful also for other ops would be a challenge,.

/yvind K.

The future is already here. It's just not very evenly distributed
                                                 -- William Gibson
http://pippin.gimp.org/                            http://ffii.org/