* Calvin Williamson <calvinw@xxxxxxxxxxxxxx> [040115 19:24]: > I like this way of thinking about the graph as > a set of connected properties or attributes of nodes, > as it meshes well with gobject style properties. > > In fact if we want a very minimal gobject style system, we > can get rid of the "apply" call on the node altogether > and make the pull happen when someone does a regular > gobject get on an output property of a node. > > g_object_get(combine3, "dest", &dest, NULL); > > Thats it! No separate apply call even needed. > > So when anyone makes a gobject_get call to an output > property on a node, it triggers the pull of data. > Of course if everyone is up to date and not dirty > along the set of connected properties it doesnt go > anywhere and just returns the current value of the > output property. > > We need the graph editing UI like you have on > gggl/bauxite It is the next part of the code that is going to be gtk+'ified,. still using cairo, but behaving like a proper gtk+ widget. It'll mostly be repackaging of the current code. http://schweden.mine.nu/bauxite/screenshots/starting_gtk.png > Perhaps we can build some autogenerated gobject > style property editors for ops that > we can hook up to them like you have for your > system. I know there is some versions of this in > gtk/tests and probably in glade somewhere too... > and other places probably now as well. > > Also we need some attention to saving properties > of ops, and this should be similar to some of gimps > serialization code from app/config. These issues are related to fileformat issues,. and I probably won't do radical changes to my current model until I can merge more of gggl and gegl, one might also consider the possibility that third party gegl op's might provide a custom UI. Providing a widget or composite widget to be integrated with the property editor. > > I am going to start making libgggl dependant on libgegl pretty soon,. > > and eventually libgggl will disappear from bauxite. At least that is my > > migration plan. > > > > One thing I would really like about images, is that they are unbounded,. > > that is,. they are an infinite plane, that samples can be requested from > > and placed into,. it would of course have bounding box etc,. and it > > would need attributes about how the parameters are passed,. > > Agreed. They should be unbounded, so you can request any > regions on the image, and it still works. Not only request, but also setting the pixels/tiles of any region. I discussed this on irc with dsrogers,. by adding a padding value, you can invalidate tiles that are entirely composed of that value,. since those are the values that will be returned for nonexistant tiles anyway. If this is implemented there also must be some way to set grow/shrink policy for an image. -- .^. /V\ Øyvind Kolås, Gjøvik University College, Norway /(_)\ <oeyvindk@xxxxxx>,<pippin@xxxxxxxxxxxxxxxxxxxxx> ^ ^
