Re: [Gimp-developer] nonlinear revision control system for GIMP
2011/5/3 Tim Chen : > 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
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/5/2 Tim Chen :
> 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
