Re: [Gimp-developer] nonlinear revision control system for GIMP

2011-05-03 Thread Tim Chen

On May 3, 2011, at 12:49 AM, Martin Nordholts wrote:
 
 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.
 

Hi Martin,

It sounds like that there are other thoughts about how to implement the macro 
system? During my GIMP hack last year, my impression was that macro recording 
should be done in PDB. And I did not do so because not every functions went 
through PDB, e.g. those stroke functions (please correct me if my memory did 
not serve me right). 

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

Yes, this is non-trivial and I am certainly not the best one to do such heavy 
duty stuff. And I still don't feel too comfortable seeing all those GObject and 
Glib stuffs...I guess I will first release my hacked and messy GIMP version for 
researchers first...

In any case, the GIMP community helps me a lot and I do like to contribute 
something back, i.e. integrate my system into GIMP core.

Regards,
-Tim




___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] nonlinear revision control system for GIMP

2011-05-03 Thread Martin Nordholts
2011/5/3 Tim Chen ht.timc...@gmail.com:
 Hi Martin,

 It sounds like that there are other thoughts about how to implement the macro 
 system? During my GIMP hack last year, my impression was that macro recording 
 should be done in PDB. And I did not do so because not every functions went 
 through PDB, e.g. those stroke functions (please correct me if my memory did 
 not serve me right).

There have been discussions of other approaches than the Command
design pattern. Making use of the PDB somehow probably is a good idea,
although that won't work for things that a use can do but that w don't
have PDB calls for yet.

 In any case, the GIMP community helps me a lot and I do like to contribute 
 something back, i.e. integrate my system into GIMP core.

That sounds great. The best way to take in a large thing like this is
by doing it step by step. Divide your work into small commits that we
can take in upstream piece by piece without introducing any bugs or
regressions. Eventually you'll have the platform you need to land the
final parts that enables your work for users.

 / Martin

-- 

My GIMP Blog:
http://www.chromecode.com/
GIMP 2.8 schedule on tasktaste.com
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] nonlinear revision control system for GIMP

2011-05-02 Thread Martin Nordholts
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
http://wiki.gimp.org/index.php/Roadmap.

 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 (...);
else
  // 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,
Martin


-- 
My GIMP Blog:
http://www.chromecode.com/
GIMP 2.8 schedule on tasktaste.com
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer