On 21/01/04, Daniel Rogers wrote: > > I don't see what this gets us. What features does it enable us to add > to the gimp? The most highly requested "big features" like high bit > depth support, CMYK and color management require us to change all the > pixel access stuff first. The only thing I can see this as getting us > is a simplification of procedural layers. Its just a way of doing things that is more gradual, its just the difference between refactoring towards something and re-writing it completely. Both are candidates you might choose. Seems both approaches have drawbacks and advantages. > OTOH, I am pretty sure that the graph machinery will have to change to > acomidate the new gegl image and all the requirements of acutally > passing image data around. Thats okay. Tell us what the changes are and we will make them. Some changes are expected to visit the ops in the order you may want to do things for images. It may be more appropriate for some image ops to pull things themselves rather than using external visitors as well. We'll fix that up when we have some image ops to traverse. > my point is the gimp gets ported to GeglImage while gegl gets its ops > working and then, when gimp is finished is ready, move in GeglOps. > Moving the other way means that while Gegl is tuning its op stuff for > its new image model, gimp is grafting the ops into its old image model. > These cross-purposes sound like they are oging to cause collisiosns. So just to be clear, are you saying first fork a developer branch on gimp, introduce a GeglImage into gimp and make it so that it can first display these kinds of images, and then port all the ops to GeglOps, meanwhile merging back and forth changes from a main branch where any UI or other work is being done. So a ground up re-write, yes? > > > >Introducing a property or pad object that holds the connection across > >from inputs to outputs solves at least a couple of tricky little graph > >manipulation issues: > > "pad" object? If we are introducing a new object to describe the > connnection they we are not using gobject properties, and I am happy. Yes you will be happy. At any rate it doesnt need airing out anymore here too much. These are mostly small (but still annoying) technical details for keeping track of connections. > >1) Issues with temporary ops and inserting these into the graph at > >a convenient spot. One place where this tends to come up is where > >you are passing images along and need to convert data types or > >color models in order to continue to the next step. > > I don't see how this is tricky or needs any special machinery to do. > Inserting into a graph is easy. Of course it is easy basically. Like I said this is not a big enough issue to even worry about much here. Its just some technical solutions to details. > >2) Issues with container nodes (ie Graphs), The > >various children want to have their properties directly > >connected to each other, while the node connections want to > >stay at the level of graphs. Here is an example where the > >innermost op on the left may be connected to the innermost > >op on the right, and that is a property connection of > >some kind. But the node connection sort of wants to stay > >at the level of the outermost container graphs on each side. > > Again I do'nt see how this is tricky, nor do I see what your "pad" > objects do besides represent connections between graphs. Recursively > traversing the graph to find the unconnected portions is not hard. > >Now one solution is to "flatten" the graph before you > >do any kind of traversal, but then you have to go and > >unflatten after a traversal. > > > >By using a property object that holds the connection, you > >let the properties stay directly connected and the node > >connection stay at the level it wants to at all times > >too. > > I do not see your point. Tranversing the graph should not be hard. Just forget I brought it up. Its not important. Its just easier now and these problems have gone away anyway. > > Yes, but I don't see how these properties simplify things. Why can't > these graph connections be represented more simply? What do we gain my > using g_object properties, as you suggest? Well, in general the more we use g_object properties for everything the easier it is for language bindings overall, and such. But we arent going to use gobject properties for the image connections anyway it seems...so ignore the next paragraph... But if we did, you would have a high level data pulling machine that is similar to something like what drives maya or houdini. (Houdini uses it throughout its entire product suite too, every single thing is connectable to everything else, and its really programmable and powerful I think) and you dont have to even specify your data passing format other than just what is already provided by writing g_object property wrappers. That means that someone writes data so that it is passed as a glib property and it is automatically now passed by the data passing machine we have written as well. It could just leverage the glib data types directly across the connection lines. > > > I don't mind writing up my approach (though it eats into actual coding > time). I don't think I am ready to propose a GeglImage header quite > yet, but I am close. > Whenever you have it just put it into image directory and we'll and start looking it over. Im still trying to get to playing more with all the other stuff in image, hopefully soon. Oh while I am thinking about it, try to use the parent_class static variable idiom for finding parent class and since that is what all the other gtk/gimp code uses... and use the same arguments for instance_init and class_init that the other gimp/gtk code uses too. Dont follow the lacage style so much use gimp style instead. I know its minor details...sorry. Calvin
