Raphaël Quinet wrote:
On Thu, 18 Mar 2004 16:38:55 -0800, Daniel Rogers <[EMAIL PROTECTED]> wrote:

More details have come forward about the Mark Shuttleworth offer. Mark Shuttleworth made up his mind and decided to fund myself and Calvin to work on GEGL and GIMP/GEGL integration. Until today, I didn't have any specific details on the offer.


You are bringing very good news here. Congratulations!


The final thing I want to do here is to seek out what people think about putting a "sponsors" section on the new webpage, and devoting some space to thank Mark Shuttleworth for this (and hell, our past sponsers too).


Do you think that it should be on developers.gimp.org, or www.gimp.org?
Maybe both?  Anyway, I think that it would be nice to mention our sponsors
somewhere.  Maybe this should be discussed on the gimp-web list?

Probably on the gimp-web list yes. I think it should be on www.gimp.org. Sponsers are important and affect everyone.


[...] The ones I really need to run past everyone are 3, 4, 5, and 6 as those involve core gimp and I need to make sure that I am not going to be working on anything that would be outright rejected by the gimp developers. 1 and 2 are gegl territory, and I know I'll accept that work :-)


Most of the milestones seem reasonable, but I have some questions about
how the GIMP integration would take place, especially regarding the
plug-ins.  Many of the current plug-ins are making more or less the
same assuptions as the core regarding the bit depth of the images, etc.
There is a lot of code to be re-written in the plug-ins and I expect them
to be broken as soon as the format of the tiles is changed.  I also
expect that it would be difficult to fix them before some parts of the
core become more stable.

Well, my plan is to port the plugins to gegl first, then change the tile format. This would mean that, for a time, both old style and new style plugins would work. I also mean a complete review of the plugins, with refactoring of the plugins into a gegl-node + gimp-gui, with a standard set of classes that each plugin is a sub-class of.

I suppose that you did not include the plug-ins in your activity planning
because that would be too much work for a single programmer (but maybe I
am underestimating you? ;-))  So I am wondering how we will be able to
coordinate the work and update the plug-ins.  Will there be a phase
during which there would be a call for volunteers for updating all of the
plug-ins once the new interfaces to the core become more mature?  Or
would it be possible to provide some kind of backwards compatibility so
that the transition could be spread over a longer period, with some
plug-ins using the new API while some others would still use the old one
through a compatibility layer?

A transition period is certainly possible. I don't think I will be able to port all the plugins quickly (though I could probably nail 80% of them in a short time, some of them are quite complicated and/or broken). There is also no reason why volunteers can't work on any of this stuff. I am not claiming every piece of this as my territory, only saying I will work on it. That doesn't mean other people can't. And backwards compatability should be possible. There is no reason to make the old plugins stop working (at least for 8 bits per channel, RGB). However the plugins will be more or less broken in that, unless they are ported, they won't work with high bit depths, or different color spaces. What I really meant to say on #4 anyway is that I expect to port most, if not all of the plugins. There is really no other way to do it. I don't believe deep paint will be a useful feature unless at least 95% of our core plugins support it. Let me put a revised #4

4. add deep paint
  () Goal: to start allowing The GIMP to handle high bit depths.  The
initial integration should not take long, but I foresee unforeseen
problems, so I am setting this estimate high.
  () time for completion: about 4-6 months
  -- a. modify GimpImage and GimpLayer to use a set of GeglOps (this is
equivlent to adding high bit depth to the core and paint).
  -- b. design a new file format (this has already begun)
  -- c. convert all the plug ins to have a class structure and use
gegl-ops.


-- Dan

_______________________________________________
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Reply via email to