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?
Usecase 3: do you mean to let multiple programs work with the same GEGL
graph at the same time?
One usecase is 'Base for undo/redo stacks':
A tree-like GEGL graph offers more than a simple history _stack_. 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. I think a GEGL tree is a
very good data structure for this and if an application decided not to
use it, the possibility to use a stack based history is still included.
This is kind-of a hot feature which can enable a lot of cool things,
Which cool things do you think of?
Best regards,
grafxuser
||
_______________________________________________
gegl-developer-list mailing list
gegl-developer-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gegl-developer-list
