At the LGM 2009 BOF, I remember Oyvind discussing his vision of something kind of like this.

Since GEGL structures its operations in tree form, what you may want to think about is that you want to display a tree in a form understandable by a user.

My personal take is that there probably is a topological sort algorithm which "effortlessly" leads to an easy to understand description of the tree in list form. (This list could then be broken up in "sublists."

No doubt, Oyvind and others (including you) have better ideas.

Good luck,

Nicolas Robidoux

On Sat, Apr 2, 2011 at 12:00 AM, Nicolas Robidoux wrote:

Since GEGL structures its operations in tree form, what you may want to think about is that you want to display a tree in a form understandable by a user.

GEGL does not structure operations in a tree form but as a graph, the XML file format of GEGL uses a tree with clones. Both are valid options, though there are some types of graphs that might be desirable that are not possible to express as graphs. For an editor for meta-operations (like unsharp mask, dropshadow etc. a proper graph editor could be mose suited.)

My personal take is that there probably is a topological sort algorithm which "effortlessly" leads to an easy to understand description of the tree in list form. (This list could then be broken up in "sublists."

GEGL already does this topological sort when saving the in memory graph structure out to the tree in XML. But that does not have to impinge on how a UI is done.

/Øyvind K.

«The future is already here. It's just not very evenly distributed»
                                                 -- William Gibson
http://pippin.gimp.org/                            http://ffii.org/
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Apologies:

I meant acyclic digraph, not tree.

Nicolas Robidoux

On Fri, Apr 1, 2011 at 9:55 PM, Marek Rogalski wrote:

Hello, everybody.
I have a quite simple proposal for this year GSoC: make a nice editor for GEGL pipelines.

Why do we need it: because the GEGL eats XML files. GIMP could eat them too. It would introduce much greater reusability in the work of designers.

Who will use it: graphic designers (who else? :p). The concept of GEGL operations is sufficiently simple to be used even by casual users.

How it could be used: GIMP could show a list of GEGL XML files that can be applied to current layer. Very similar to how the filters are exposed right now. The editor itself could be located in GIMP (I would like that :) ) or as a separate program.

The meta-operations should be loaded from XML definitions and not defined in C, allowing such an editor to program composite filters, that effectively will replace many of the current uses of script-fu in GIMP. For instance the logo scripts and quite a few other such scripts should be possible to easily reimplement as meta-ops visually with such an editor in place.

See https://bugzilla.gnome.org/show_bug.cgi?id=465743 for a bug tracking the long standing desire to load these ops from XML instead of hard-coding them in C.

Request for comment:
- what do you think of the whole idea? Would it be useful or not?

It would defintely be useful.

- should it be merged with GIMP or work standalone (or both :) )?

Making it work stand-alone first is probably best, a stand alone tool would also allow easier testing of GEGL operations (GEGL used to ship with a tree based editor UI sandbox
(http://pippin.gimp.org/tmp/gegl-foo/) that I removed since the code was scraped from somewhere else and rather ad-hoc.) If a good graph editor surfaces, GIMP might be interested in incorporating portions of it in some way, but it would defintely be useful on its own as well.

- what gui toolkit would be appropiate? GTK or Clutter?  (I fell in love with clutter, but there may be reasons not to use it for such program)

If the program is stand-alone, the choice would be up to the implementor ;)

Other ideas:
- shebang at the beginning of the GEGL XML - drop files on the script and get them processed
- automatically generate GtkBuilder XML for marked parameters of GEGL operations - could
be used to display filter-like dialogs of arbitrary GEGL pipelines.

Generting XML is not neccesary, both the GEGL tool in GIMP and the sandbox I linked to were generating their property editors on the fly based on inspecting the GParamSpecs. Going through GtkBuilder XML might not neccesarily be easier than building the UIs only in code.

/Øyvind K.

«The future is already here. It's just not very evenly distributed»
                                                 -- William Gibson
http://pippin.gimp.org/                            http://ffii.org/
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

W dniu 11-04-01 23:55, Marek Rogalski pisze:

Hello, everybody.
I have a quite simple proposal for this year GSoC: make a nice editor for GEGL pipelines.

Why do we need it: because the GEGL eats XML files. GIMP could eat them too. It would introduce much greater reusability in the work of designers.

Who will use it: graphic designers (who else? :p). The concept of GEGL operations is sufficiently simple to be used even by casual users.

How it could be used: GIMP could show a list of GEGL XML files that can be applied to current layer. Very similar to how the filters are exposed right now. The editor itself could be located in GIMP (I would like that :) ) or as a separate program.

I have been generating various content on this topic for around a year and made a few concepts. Their code is packed at stud.ics.p.lodz.pl/~mafik/prototypes.tar.bz2 (contains a few interface ideas) (bother to look only if
you want to deal with lots of unfinished code). I have made a sample here: http://www.youtube.com/watch?v=sEm9M2O6xC0 (second part shows much better, what I am thinking about).

There are many areas where the idea could be clarified, but the concept should be clear.

Request for comment: - what do you think of the whole idea? Would it be useful or not? - should it be merged with GIMP or work standalone (or both :) )? - is Vala mature enough to use it as the main language? (I'm asking because I saw some discussions about it recently on this list) - what gui toolkit would be appropiate? GTK or Clutter? (I fell in love with clutter, but there may be reasons not to use it for such program)

Other ideas: - shebang at the beginning of the GEGL XML - drop files on the script and get them processed
- automatically generate GtkBuilder XML for marked parameters of GEGL operations - could
be used to display filter-like dialogs of arbitrary GEGL pipelines.

PS. (note to GSoC mentors) I would like to take part in this year GSoC. If you encounter my submission, take it under considerations only under this idea (if it passes, of course).

Blender's Composite Nodes anyone? ;>

http://www.blender.org/development/release-logs/blender-242/blender-composite-nodes/

Personally I love the idea. What is more, I think that such editor could be developed as an external project, independent of GIMP, yet "pluggable" to the latter.