1. GEGL filters cannot make new layers or interact with multiple layers.

2. Only white listed GEGL Filters can use Gimp's on canvas options. This applies to transformations and gradients. In example SuperNova is a Gradient with an canvas axis tool, and Recursive Transform uses unified transform. These filters are white listed by Gimp and the only way to white list new filters is to rebuild Gimp from source.

3. GEGL cannot yet do adjustment layers (but it comes remarkably close) GEGL cannot interact with layers below the current layer but Gimps aux selection option can call other layers, compositions and layer group compositions. This in theory one day can lead to a system that does adjustment layers.

4. GEGL cannot read xcf files like a smart object. But it still comes remarkably close because Gimps aux selection option can.

5. GEGL loads everything into memory at once. Once I did an operation that used 30 filters at once and it took 15 minutes to apply. It would have better much faster if GEGL applied each operation step by step. GEGL cannot do this.

6. GEGL does not yet have vector layer support. Gimp Devs are working on allowing GEGL to handle vectors with GEGL:Fill and GEGL:path but as of yet GEGL cannot do this.

7. GEGL has poor documentation. Go to GEGL.org, learn GEGL syntax, practice in GEGL Graph and read the .c files of GEGL filters in the source code. From there I can't help you anymore.

Also GEGL transform tools cannot do that
viewtopic.php?f=8&t=19437

I would start with item #7... And my question to the GEGL developer mailing list is still waiting for an answer.

1) Yes, but then GEGL isn't Gimp. What could be required is an esasy integration of GEGL and scripts.

3) Adjustment layers are a way to do non-destructive editing, GEGL graphs are another. We don't necessarily need Gimp to mimic PS, if it can achieve the same result differently.

4) I personally loathe applications that have links to outside files. This typically means that the project cannot be shared (or sometimes even moved on the local system).

5) I don't agree. If you look at how GEGL works, there are ways to optimize the whole graph. There is a class of GEGL transforms that covers transforms where the only source for a pixel is a pixel at the same coordinates. This hints that in such cases GEGL can apply several operations together to the pixel. Otherwise, see 1)

7) Well, there is a doc, but since most of the doc is generated from the source, and the source has very little comments, there isn't much added value, you have to go back to the source anyway.

While compiling a new Gimp version, I stumbled upon GEGL graph definitions in JSON format (you can see them on the GEGL tools list, "json:dropshadow2" and "json:grey2". This would solve my main problem with GEGL being only in C (and so any small and trivial graph requiring compilation for Linux/Windows/OSX). You can indeed add graphs to the list this way, but this seems rather limited.

Personally, I'm looking for a way to:

1) fan out the same input to several pads, for instance apply the same input values to the X and Y offset in "translate" (you can do that with gegl:nop for layers)

2) possibly combine some of these values numerically (use the same value for a translate and a blur, with some blur/translation ratio

3) Use input "metadata" (for instance height/width) as value for nodes.

4) apply any of the Gimp blend modes

GEGL can use Gimp blend modes.

I forgot to mention that GEGL already can do something like smart filters (reeditable filters) but Gimp can't store their information.

How? I cannot see operations that bear the name of these modes (except "over").

id=1
gimp:layer-mode layer-mode=softlight opacity=1.00 aux=[ ref=1 ]

id=3
gimp:layer-mode layer-mode=softlight opacity=0.30 aux=[ ref=3 ]

Can have tabs as well, when a long list of options start to show the scroll bar