Today the issue of the path to take to begin gegl- talks for the gimp arised again on #gimp.

As irc is so transient, I was asked to save the talk in a more permanent way. Given there are just Q&A with ideas and nothing concrete, the list seems me to be permanent enough for this.

Yuck - Just noted that I was without time stamps. It took place 12/22/2004, at about 17h00 UTC =========

pippin: So - I saw your mail listing the order in which you thought the tools should move to gegl pippin: Do you have any idea how that might happen (I mean, what gegl interfaces you use, how you make paintstrokes be ops, that kind of thing)
A design sketch for gegl tools, I mean... bolsh: yes, but I have not had time to hack it into oxide/bauxite yet,.
pippin: I'd be interested in reading your ideas, if you've written them down somewhere...
I'm trying to get my head around what kind of interface gegl needs, and how much work needs doing to provide it bolsh: I have a lot of ideas,. and as well as hunches,. bolsh: I am starting to internally conceptualise how gimp image model fits with gegl,. and the place with least intrusion would be the tools,. new gegl based tools could even coexist with the current ones,. thus I think it would be the ideal proving ground,. (granted we wouldn't get high bitdepth whilst doing it,. since we'd still be using gimp drawables)
toady (~toady-AJMAXjo1rwcacnK+F/IuxqxOck334EZe@public.gmane.org) has joined #gimp bolsh: the compositing requires somewhat deeper restructuring to be really useful,. I think it is wise to start working to get the tools done,. before deciding on a design there,. the design I am using in oxide seems to work fairly well,. but I think it needs more review,. a sane form of a such review won't be possible until after some people have started building things with gegl pippin: What would you say about moving the brush and paint-tools compositing to Gegl first, so that brushes can have more parameters?
bolsh: I am also,. kind of suggesting,. to allow blessing any image source with the 'drawable' properties,. this would mean that the source op gets a hidden internal chain of operations that are to be executed (the associated stroke history),. caching should eventually happend on the GEGL level,. but that kind of changes,. might have to wait until gimpdrawables are replaced by source ops from gegl,.
joao: I don't quite follow
pippin: how hard would it be to replace gimpdrawables by source ops?
pippin: would this means we'll have to rewrite all the code that use GimpDrawable ?
pippin: And what do you think about the plan that Daniel outlined some months back? It appears consistent with your idea pippin: IIRC, he was saying that we wouldn't need to migrate to the compositing model before we had started using GeglImage rather than (or contained in) GimpDrawable
we were talking about this yesterday. Currently, a brush in gimp is a tempbuff - it can't do much by itself. We were talking about adding a UI for scaling, and implement rotation on the brushes. That could be done adding/bettering the transforms in tempbuff, or moving it to a gdkpixbuf, or using gegl to handle the brush. --> toyowheelin (~greg-G75OPyG223OFrNtFBFM8L/owLGgwLWYhwhDWTKBK8rY@public.gmane.org) has joined #gimp
bolsh: starting with the tools,. and keeping the exiting infrastructure for support,. means earlier integration into gimp,. and the ability to start doing integration without breaking everything first,.
pippin: Like I said, it sounds like your idea is consisitent with what Dan proposed - it's a step before everything else And it would mean depending on gegl, which is good pippin: the sooner we start the better. sooner == as soon as we branch

http://www.mail-archive.com/gimp-developer%40lists.xcf.berkeley.edu/msg06446.html dindinx: It might be possible to wrap a GeglImage in a GimpDrawable and keep all the code there bolsh: this would be a wonderful first step, then But everything that uses data buffers directly (TimeManager, TempBuf) would need re-writing to use equivalent gegl structures bolsh: _might_
bolsh: it does dictate the future capabilities possible,. Which would ideally abstract away details like the tiles, and make the API simpler, perhaps even reducing code size pippin: Sure
bolsh: aI see it,. mapping the whole internal data structure ofof gimp to a tree,. similar to what I have in oxide, woudl be a good thing
s/aI/as/
pippin: That would mean, in short, replacing GimpImage by a graph, plus some auxilary stuff that doesn't have to do with data (like guides and undo) - does that sound right? bolsh: any thing touching a pixel doesn't belong above gegl bolsh: yes,. it means extending for instance my xcf2 draft with guides,. comments,. and other perasites that belong,. how it is modelled in a ui is a different aspect the other way of integrating it,. is reusing the exact same concepts used in gimp at the moment,. and use gegl for the processing this would make it harder to add layer effects,. layer groups,. clone layers,. etc.. which dan calls "6. The big ones" in his roadmap,..
I think those actually means a rewrite,.. maybe the rewrite to a DOM (tree),. would be the right thing to do there,. since it gives a few of the items almost for free,.. pippin: Sure - you go "GeglPixel gp = img.getPixel(x, y)" (I'm javaising)
bolsh: you shouldn't ever need to do that,.. bolsh: perhaps for something like an eyedropper tool,. but even such a tool can actually be a gegl op,. setting a property on itself containing the sampled color,. pippin: You would need to do it in plug-ins Which would become GeglOps
bolsh: plug-ins are geglops
two different apis,.
--> ros (~chatzilla-7YQvAk6+eSE1YdlzKyyIQg@public.gmane.org) has joined #gimp gimp gegl op
gegl is the middleware,. and has a op-api and an app-api mucking with pixels and such things should be forbidden on the left side of gegl,. the number of needed api entry points from the gimp into gegl < 32 methods
and it should stay that way,. to make changes easier,. when gegl goes through app-api freeze,. it should be a long term freeze pippin: Do you have a rough idea of what those 32 methods will be?
Away for a while (and maybe for the night) a graph management, and property setting api on top of that, I have built a tree model myself,. essentially what gegl/gggl does is to define an image processing language,. using a graph for it's syntax only that language should be spoken when cosntructing 'sentences' in that language
(that's my polite way of asking if you wouldn't mind writing some stuff down & sending it to gegl-dev or gimp-dev) :)
pippin: I just don't want to see good ideas lost because they didn't get archived - irc is transient by nature http://pippin.gimp.org/cvs/gggl/gggl/gggl.h.html s would be a little bit different,. but that is the scope of the api level api