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



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]