BEVERLY HILLS, CA (cinepaint.blogspot.com) 11/02/2008 – Gabrielle and I had a fantastic trip to Copenhagen to speak October 3rd and 4th at Open Source Days. For slides and photos follow links at www.linuxmovies.org
. Gabrielle and I presented “Tux with Shades” about Linux in the film industry (it’s everywhere) and on the second day I presented “CinePaint Deep Paint”.
Some interesting points were revealed during the CinePaint session discussion. I heard the typical request that the CinePaint team rejoin GIMP. Of course, “rejoining” sounds crazy since we never belonged to GIMP and never had any interest in their mission. CinePaint is a tool for deep paint of image sequences. GIMP is a paint and photo-retouching program. Krita, another paint/retouching program, shares a more similar mission. Maybe Krita should “rejoin” GIMP? Just kidding.
So why did a GIMP user in a CinePaint session ask me to work on GIMP instead? Certainly the GIMP hackers don’t want me. Had an interesting answer. He’s frustrated by the delays in GIMP’s implementation of 32-bit deep paint. GEGL was announced as vaporware by GIMP in 2000. GEGL was their rationalization for moving away from Film Gimp (now CinePaint) instead of making that GIMP 2.0. Years later, I discovered forgotten Film Gimp, which had never been released, and made it available on SourceForge to anyone who wanted it. A closed source program would have been permanently orphaned, but not CinePaint. Isn’t open source great?
Outside the session, another GIMP user offered a different rationale why I should abandon CinePaint in favor of GIMP. He said that GEGL is finally nearing usefulness, that CinePaint will no longer matter after GIMP supports 32-bit. The problem with that logic is that Krita already supports 32-bit. If deep paint is all that matters, everyone should abandon GIMP for CinePaint or Krita! Just kidding. People using or working on open source choose whatever interests them most.
So, since CinePaint isn’t “rejoining” GIMP or Krita, what are we doing? Why does it take so long to make a new release?
In Copenhagen at Open Source Days I met Debian packager Jonas Smedegaard. Jonas is already overloaded with Debian packages to maintain and gamely volunteered to take on CinePaint, too.
Michel Lesoinne has been working on creating a CMake build system for CinePaint and that’s now mostly working. One of the things I want in the 0.25.0 version release is CMake support. That should be especially helpful for the Mac build, where autoconf never seems to do the same thing twice. The Mac build is much more involved because we build every dependency from scratch and use GTK+OSX instead of GTK2 (the new default in 0.25.0 CinePaint for Linux is GTK2, not GTK1). CinePaint runs on Mac natively. No X11. No Fink.
Kai-Uwe Behrmann has been fantastic about updating our autoconf system, but he’s the only person who understands it. Having an alternative build system gives us choices, avoids bringing the whole project to a stop while debugging an autoconf problem. Problems there can be very time-consuming because autoconf outputs intermediate make files, doesn’t build directly.
More build systems are coming… H. S. Teoh is providing a build system based on Python SCons. Teoh is also a Debian packager and helping there.
Official Fedora packager Nicolas Chauvet is starting to test 0.25.0. His first question...do I use autoconf or CMake? Good question.
Henne Vogelsang at OpenSUSE is advising me on their packaging requirements. We need someone to volunteer to master using the OBS build farm. That will test building CinePaint from rpm and deb and put CinePaint on the road to being an official OpenSUSE package. When we have that going, OpenSUSE will recruit an official packager.
Alexis Ballier at Gentoo is working on 0.25.0, too.
Professional photographer Paul Indigo is testing 0.25.0 on Ubuntu. Paul, a non-programmer, has been testing my new CVS build scripts available on the CinePaint download page. By running a bash script, any user can download and build CinePaint from CVS. No programmer knowledge required. I think this is a better way to test than with release candidate tarballs that rapidly become outdated as pre-release bugs are fixed. All a user has to do is cvs update, build changes, then start testing the fixes.
Anyone who wants to help with CinePaint can contact me at robin.rowe at cinepaint.org.
Love you guys!