Talkings about the road ahead.
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
Talkings about the road ahead. | Joao S. O. Bueno Calligaris | 23 Dec 00:02 |
Talkings about the road ahead.
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