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
<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
<pippin> joao: I don't quite follow
<dindinx> pippin: how hard would it be to replace gimpdrawables by
<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
<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
<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
<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)
<bolsh> pippin: I just don't want to see good ideas lost because they
didn't get archived - irc is transient by nature
<pippin> http://pippin.gimp.org/cvs/gggl/gggl/gggl.h.html <- 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