Sorry to come in late here folks, but is this still being actively pursued?
Jon On Mon, 2006-04-24 at 16:00 +0200, Øyvind Kolås wrote: > On 4/24/06, Alexandre Prokoudine <[EMAIL PROTECTED]> wrote: > > On 4/24/06, BERGER Cyrille wrote: > > > > 1. How exactly many developers like the idea of having uniform API for > > > > plug-ins? > > > me :) > > > > That's a good start :) > > The problem with any such approach is that it caters to the lowest > common denominator. This makes such a filter/plug-in/effect framework > only suitable for the common subset and is likely to suffer either in > quality and performance compared to native plug-ins. GEGL will demand > reference implemententations of >=32bit floating point accuracy, > mechanisms for minimizing temporary buffers to reduce computational > overhead when rendering subregions, and hopefully even scale > invariant/tolerant parameters. > > Other efforts to achieve cross application image/video processing > plug-ins already exist, various applications have different needs. > Dataflow(/graph) based designs like GEGL have the advantage that > supporting new types of plug-ins are relativly easy. GEGL will aim to > support legacy 8bit only GIMP plug-ins through an adapter. Such > adapters could also be made for freeframe[1], Frei0r[2], livido[3] and > foobar[4]. > > 1: http://freeframe.sourceforge.net/ > 2: http://www.piksel.org/Frei0r > 3: http://livido.dyne.org/ > 4: http://pippin.gimp.org/gggl/ops.html > 5: insert missing standard effect/filter plug-in architecture here. > > > > But, anyway, it's the heart of the problem, plugins often require a > > > configuration widget, and GTK apps will want a GTK widget and Qt apps > > > a Qt widget (and don't forget about wx and fltk ;) ), and we cannot > > > ask all plugins devs to provide a widget for all toolkit. (one > > > solution would be to provide a xml description of widgets (like Qt's > > > ui files) and let the host application transform it to its favorite > > > toolkit widget). > > > > I'm not sure what you mean with a configuration widget. Do you mean > > custom widgets? > > For plug-ins to be easily shareable in such a scenario it is important > that parameters and their ranges are discoverable through > introspection. This will be done in GEGL thorugh the use of > gparamspecs. This allows some guaranteed support. Bauxite[6] for > instance the default way is to use simple entries/slider for > strings/doubles. But also allow the host application to recognize the > plug-in and provide a specialized vector widget that controls those > same parameters. > > 6: http://pippin.gimp.org/bauxite/ > > > > > 4. Is it possible at all to create a uniform API for plug-ins that > > > > could work e.g. in both Krita and GIMP (and with GIMP I mean upcoming > > > > GEGL-based GIMP) with regard to color management, bit depth (8/16/32 > > > > floating point per channel), color spaces etc? > > > > > > And I think you forgot at least one question: > > > 5] what plugins are to be common ? tools ? filters/effects ? > > > colorspaces ? file import/export ? "batch" processing (like > > > kipi-plugins) ? > > My answer to question #4 is, yes and no, and it might not even be > neccesary if one of the existing ones could already be adapted to some > of the needs. > > /Øyvind Kolås > > -- > «The future is already here. It's just not very evenly distributed» > -- William Gibson > http://pippin.gimp.org/ http://ffii.org/ > _______________________________________________ > CREATE mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/create > -- Jon Phillips San Francisco, CA USA PH 510.499.0894 [EMAIL PROTECTED] http://www.rejon.org MSN, AIM, Yahoo Chat: kidproto Jabber Chat: [EMAIL PROTECTED] IRC: [EMAIL PROTECTED] Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org) Creative Commons (www.creativecommons.org) San Francisco Art Institute (www.sfai.edu) _______________________________________________ CREATE mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/create
