2011/5/2 Tim Chen <ht.timc...@gmail.com>:
> Hi all,
> Recently we have published a paper on SIGGRAPH 2011 about nonlinear revision 
> control system for images. You can find the abstract and videos at
> https://sites.google.com/site/httimchen/2011_imagesvn

Hi Tim

That's great stuff.

> 1) is there anyone implementing the macro/script system

Nope there isn't, so you are more than welcomed to start doing that.
FYI, macro recording is on our roadmap found at

> 2) can anyone give me a head start on how should I modify my hack so that it 
> is more readable to others? Spreading the log function into tens of files 
> certainly breaks most guideline one should follow when writing 
> object-oriented program :D

I'm convinced (others are not) we should use the proven
http://en.wikipedia.org/wiki/Command_pattern and
http://en.wikipedia.org/wiki/Composite_pattern for macro recording and
wrote some patches a while ago that introduced a GimpCommand and a
GimpGroupCommand class. I didn't have time to even turn it into a
working prototype however.

It will be necessary to make some extensions to the above patterns.
For example, you may have noticed that GIMP is quite quick to Undo and
Redo, in particular for time consuming pixel processing operations.
That's because the undo stack contains the tiles with the resulting
pixels, not only parameters used to get that result. When Redoing, the
tiles with the result can quickly be applied.

I'm imagining that we'd have code that would look something like this:

  gimp_expensive_command_execute (...)
    if (gimp_expensive_command_result_cached (...))
      gimp_expensive_command_apply_cached_result (...);
      // Do time-consuming stuff

We don't want to start each GimpCommand with that if case though, so
an abstraction will be needed.

This is not a trivial refactoring, but we need to do it eventually.

Best regards,

My GIMP Blog:
"GIMP 2.8 schedule on tasktaste.com"
Gimp-developer mailing list

Reply via email to