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

<bolsh> pippin: So - I saw your mail listing the order in which you 
thought the tools should move to gegl
<bolsh> 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)
<bolsh> A design sketch for gegl tools, I mean...
<pippin> bolsh: yes, but I have not had time to hack it into 
oxide/bauxite yet,.
<bolsh> pippin: I'd be interested in reading your ideas, if you've 
written them down somewhere...
<bolsh> I'm trying to get my head around what kind of interface gegl 
needs, and how much work needs doing to provide it
<pippin> bolsh: I have a lot of ideas,. and as well as hunches,.
<pippin> 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 has quit (Leaving)
--> toady ([EMAIL PROTECTED]) has joined #gimp
<pippin> 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
<joao> pippin: What would you say about moving the brush and 
paint-tools compositing to Gegl first, so that brushes can have more 
<pippin> 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,.
<pippin> joao: I don't quite follow
<dindinx> pippin: how hard would it be to replace gimpdrawables by 
source ops?
<dindinx> pippin: would this means we'll have to rewrite all the code 
that use GimpDrawable ?
<bolsh> pippin: And what do you think about the plan that Daniel 
outlined some months back? It appears consistent with your idea
<bolsh> 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
<joao> 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 ([EMAIL PROTECTED]) has joined 
<pippin> 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,.
<bolsh> pippin: Like I said, it sounds like your idea is consisitent 
with what Dan proposed - it's a step before everything else
<bolsh> And it would mean depending on gegl, which is good
<dindinx> pippin: the sooner we start the better.
<dindinx> sooner == as soon as we branch
<- dans roadmap
<bolsh> dindinx: It might be possible to wrap a GeglImage in a 
GimpDrawable and keep all the code there
<dindinx> bolsh: this would be a wonderful first step, then
<bolsh> But everything that uses data buffers directly (TimeManager, 
TempBuf) would need re-writing to use equivalent gegl structures
<pippin> bolsh: _might_
<pippin> bolsh: it does dictate the future capabilities possible,.
<-- toyowheelin has quit (Leaving)
<bolsh> Which would ideally abstract away details like the tiles, and 
make the API simpler, perhaps even reducing code size
<bolsh> pippin: Sure
<pippin> 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
<pippin> s/aI/as/
<bolsh> 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?
<pippin> bolsh: any thing touching a pixel doesn't belong above gegl
<pippin> bolsh: yes,. it means extending for instance my xcf2 draft 
with guides,. comments,. and other perasites that belong,.
<pippin> how it is modelled in a ui is a different aspect
<pippin> the other way of integrating it,. is reusing the exact same 
concepts used in gimp at the moment,. and use gegl for the processing
<pippin> this would make it harder to add layer effects,. layer 
groups,. clone layers,. etc.. which dan calls "6. The big ones" in 
his roadmap,..
<pippin> 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,..
<bolsh> pippin: Sure - you go "GeglPixel gp = img.getPixel(x, y)" (I'm 
<pippin> bolsh: you shouldn't ever need to do that,..
<-- rambokid has quit (Ping timeout: 600 seconds)
<pippin> 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,.
<bolsh> pippin: You would need to do it in plug-ins
<bolsh> Which would become GeglOps
<pippin> bolsh: plug-ins are geglops
<pippin> two different apis,.
--> ros ([EMAIL PROTECTED]) has joined #gimp
<pippin>   gimp <-> gegl <-> op
<pippin> gegl is the middleware,. and has a op-api and an app-api
<pippin> 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
<pippin> and it should stay that way,. to make changes easier,. when 
gegl goes through app-api freeze,. it should be a long term freeze
<bolsh> pippin: Do you have a rough idea of what those 32 methods will 
<bolsh> Away for a while (and maybe for the night)
<pippin> a graph management, and property setting api
<pippin> on top of that, I have built a tree model myself,.
<pippin> essentially what gegl/gggl does is to define an image 
processing language,. using a graph for it's syntax
<pippin> only that language should be spoken when cosntructing 
'sentences' in that language
<bolsh> (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> :)
<bolsh> pippin: I just don't want to see good ideas lost because they 
didn't get archived - irc is transient by nature
<pippin> <- that is 
the entry points used in gggl,. gegl's would be a little bit 
different,. but that is the scope of the api level api
Gimp-developer mailing list

Reply via email to