On 10/27/07, Valerie VK <valerie_vk@xxxxxxxxx> wrote: > So... Gimp currently has 4 major goals? > - Cairo > - GEGL > - Add named parameters and default values to the PDB > - 6 months development cycle. > > Wouldn't it be easier to treat them as Separate goals for separate > releases? Once Cairo and GEGL (I have no idea for the Parameters feature, > so apologies for not being able to say more about it) have been properly > implemented, Gimp should have the foundations for rolling out features > more quickly. Wanting two at the same time though seems to be asking too > much, and proper implementation of GEGL in my opinion justifies one final > long development cycle. > > Maybe something like this can be considered: > > Gimp 2.6: > - implementation of Cairo (get this out of the way) > - start background work on GEGL, by dedicating more developer resources > (if possible) to actually coding GEGL without necessarily implementing it > yet Okay I want to clear this up: GEGL *is* coded (see www.gegl.org), and already in use by a few different applications. It works. Getting it working fast and bugfree, though (for instance, good caching behaviour), will be driven by use in GIMP, which will help to locate slow and buggy areas of GEGL. Initial integration will probably be a fussy business, rather than a particularly large one -- making sure that a) it's used right and b) the parts that should use it, do use it. The only major point for GEGL that is currently known that would make integration with GIMP difficult, is 8bit-specific code; GEGL Ops that accept and output 8bit integral RGBA instead of 32bit float RGBA. I believe many of these can be created automatically by modifying the current code, which already handles generating float versions of porter-duff ops and blending ops. In the mean time, a single conversion op (float -> 8bit int) could be made. > - bunch of other easier features to keep people happy > - development cycle: 6 months to a year. > > Gimp 2.8: > - GEGL integration > - the background GEGL work that started with Gimp 2.6 should have paved > the foundations for slightly faster integration > - the development cycle will probably still be long, but this will be the > last "long" release cycle. > > Gimp 3.0+: > - with GEGL properly implemented, from now on, development cycles will be > 6 months. > > Once GEGL has been implemented, the following features seem to be the most > demanded ones: > - CMYK > - 16 bit > - layer effects > - layer groups It's worth a minute to point out the notable, and deserved, absence of adjustment layers from this list. People have had a few discussions (here? certainly on bugzilla.) about this topic, and it arose that: a) Adjustment layers are generally an ugly, complicated idea b) They are also an unnecessary idea -- the combination of layer effects and layer grouping can produce the same effects in a much more sensible way. (for the reference of anyone who was considering bringing this topic up ;) > > Any one of the above could justify a minor release. Having the first > GEGL-version of Gimp ship with one of the above features would justify the > time spent on it, especially if the developers explain that the other > features will follow fast. Having said first GEGL-version of Gimp ship > with Two of the above would be fantastic. > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > Gimp-developer mailing list > Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx > https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer > _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
