Re: [Gegl-developer] Journal for changes to a GEGL graph

[Jon Nordby <jononor gmail com>]

On 8 June 2012 22:22, gfxuser <gfx user online de> wrote:
> Am 08.06.12 15:00, schrieb Jon Nordby:
>
> > Also at LGRU (http://www.piksel.no/pulse/lgru), Øyvind allowed me to
> > pick his brain about recording, storing and replaying changes done to
> > a GEGL graph.
> >
> > == Usecases ==
> > * Base for undo/redo stacks in GEGL based applications
> > * Automated testing of GEGL graph manipulation API and interactive view
> > widgets
> > * Sharing and manipulation of a GEGL graph between multiple programs
> >
> > The brain picking was quite fruitful and together we came up with an
> > initial specification for this feature, including the file format and
> > API:http://git.gnome.org/browse/gegl/tree/docs/journal.txt
> >
> > This is kind-of a hot feature which can enable a lot of cool things,
> > so I am hoping that someone may be interested in helping to implement
> > it!
> Hi,
>
> I read it, but I'm not sure to have understood the goal behind. I don't see
> yet the necessity to have transactions for the usecases 1 and 2, but maybe
> I'm blocked. What's the purpose of transactions here?
The purpose of transactions is to allow to grouping a set of changes
to the GEGL graph, and that the applications using GEGL can decide
what a meaningful grouping is.

For instance adding a layer in GIMP may result in 5, 10 or even more
changes to the GEGL graph. Grouping these into one transaction then
allows GIMP to treat them as one logical change.

> Usecase 3: do you mean to let multiple programs work with the same GEGL
> graph at the same time?
Yes.

> One usecase is 'Base for undo/redo stacks':
> A tree-like GEGL graph offers more than a simple history _stack_.
A GEGL graph on its own does not provide any form of history, it only
knows about the current state.

> Why not
> provide a undo/redo tree like K-3D? GIMP artists could ' jump back-and-forth
> among multiple "branches" of modifications to their scene' (see
> http://www.k-3d.org/wiki/FAQ#How_does_K-3D_compare_to_Blender.3F). This
> would give them more creative possibilities.
No history is ever discarded in the file format. So it is always
possible to go reach all versions you have been on before, including
the ones that are not part of the current "branch".

> > This is kind-of a hot feature which can enable a lot of cool things,
>
> Which cool things do you think of?

- Sharing the undo/redo history across applications using GEGL
- Allowing the undo/redo history to be saved together with a document.
When you open an old file, you have all the history of it, since it
started existing.
- Working on the same document from two different applications at the same time.
- Preserving non-linear histories
- Browsing through the entire timeline of a document

-- 
Jon Nordby - www.jonnor.com